| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Dan,
Thanks for your valuable comment and response in time.
If we apply your following comments to CPACEOQUAKE protocol, the same issue will happened in CPACEOQUAKE as well, because the QC can crack ISK derived in CPACE procedure, and then obtain the password, CPACEOQUAKE protocol will game over finally.
That's what I'm thinking you're correct on the OWE case as the QC don't need to guess the password, but there will be some different for DH-based PAKE solution, as QC has nothing to know on the password at the very beginning, it has to use the guessed password and verify it in the later procedure. Actually, ML-KEMss is just one example to stir the PMK derivation in SAE to make it PQC security, we can use any PQC solution to stir the PMK derivation,like PPK defined by RFC8784.
For your following up question, the PMK /KCK is derived from combination of SAEss ||ML-KEMss, can we authenticate both of them based on the last two SAE confirm message exchange, or if you think something missing, I can add based on your suggestion.
Welcome your further comments.
Thanks
Best Regards
Jay Yang (杨志杰)
The quantum computer does Shor’s algorithm and determines a discrete logarithm in polynomial time which compromises the CDH which voids the security of the SAE -derived secret, k. That’s how.
So why don’t you answer this question for me: In your proposal how is ML-KEMss authenticated?
And I’m sorry but your article is from medium.com and behind a paywall so it’s not the most credible of sources and I can’t read it on top of that. I don’t know David Montgomery* but I’d ask him the same question. How is the “post-quantum parts” authenticated?
Unless you can tell me that then it’s not secure, as you allege.
Dan.
--
“the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane.” – Marcus Aurelius
From: "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx>
Date: Monday, January 12, 2026 at 6:20 PM
To: Daniel Harkins <daniel.harkins@xxxxxxx>
Cc: "stds-802-11-tgbt@xxxxxxxxxxxxxxxxx" <stds-802-11-tgbt@xxxxxxxxxxxxxxxxx>
Subject: 2026/4r0 PQC PAKE design in details
Hi Dan,
Thanks for your comments during the call just now.
If I recalled correctly, you said the quantum computer(QC) can crack the SAEss (K), could you elaborate how to make it based on the first two commit message exchange? In my mind, once we concatenate SAEss and ML-KEMss as IETF TLS did before PMK derivation, it's impossible for the QC to only crack the SAEss . Please correct me if I make any mistake.
The ideas in my contribution is quite similar to the following: please see the link as bellow.
The another comment was relevant to transcript, I can add it during PMK derivation. Due to the time constraint, I don't have time to take other comments, we can discuss them in this reflector.
PQC in WPA3/WPA4 Handshakes: WPA3’s SAE is based on finite-field or elliptic curve cryptography (it’s a password-authenticated key exchange using discrete log problems). To be quantum-safe, one idea is to perform a hybrid key exchange: combine the traditional SAE (to ward off classical attackers) with a parallel PQC key exchange (like exchanging Kyber public keys within the handshake). This way, even if a quantum adversary records the exchange, they would need to break both the classical and the post-quantum parts to get the key (which is conjectured to be infeasible). Efforts in other domains, such as TLS 1.3, have already defined hybrid key exchanges (e.g., combining ECDH with Kyber ).
Wireless Network Security in 2025 and Beyond | by David Montgomery | Medium
Thanks
Best Regards
Jay Yang (杨志杰)
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1