Well as a for-instance, going from OQUAKE to CPaceOQUAKE resulted in an additional message and that was because the ECC PAKE had to get ½ way through before the PQC PAKE could start, nothing to do with the size of the additional public
key. The messages are bigger and they’re bigger than simply the size of the public key, although that is the bulk of the additional message size. So we’re getting more messages and bigger messages with hybrid.
And think about TLS. How are certificates going to be provisioned? One for ECDSA and one for ML-DSA? OK, now the bloat is significantly greater than simply the size of the public key. There’s signatures for each certificate and all the
ASN.1 goo that constitutes the certificate—subjectname, issuer, validity period, alternative name, key usage, etc. RFC 9191 was already reporting EAP-TLS failures because of too many (> 50) EAP fragments. Just wait with ML-DSA certificates*! An EE certificate
plus an issuing certificate plus a root of trust? Times 2 (one chain for ECDSA and one chain for ML-DSA)? Whoa! We’ll be well over 100+ fragments and possibly significantly more for a single association!
Dan .
* my experimentation with an ML-DSA CA and my EST implementation gives me 7800+ byte DER-encoded certificates and there’s nothing very fancy about them (i.e. no special key usage or alternative names).
--
“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
On 3/26/26, 4:19 PM, "Nehru Bhandaru" <nehru.bhandaru@xxxxxxxxxxxx> wrote:
I don’t have a strong opinion but the standard should not dictate whether hybrid or pure is mandatory. Granted hybrid adds a classical mechanism, but given you bring up the bloat, I think
the classical mechanisms add a small bloat - for example P521 number uses 66 bytes (correct me if wrong), but ML KEM uses public keys and cipher text from 800-1600 bytes…
- N
On Thu, Mar 26, 2026 at 2:45 PM Harkins, Dan <daniel.harkins@xxxxxxx> wrote:
Hi Nehru,
On 3/26/26, 2:04 PM, "Nehru Bhandaru" <nehru.bhandaru@xxxxxxxxxxxx> wrote:
Thanks Dan. Interesting article.
Looks like it is not a debate just in IEEE 802.11/bt. Still IETF and other folks in the industry are debating and according to the article
“It is true that 0x11EC is not marked as Recommended, mostly because it started out as an experimental combination that then somehow ended up as the thing everybody was doing, and while lots of digital ink was spilled on whether or not it should be recommended, nobody updated the flag before publishing the RFC. (technically the RFC is not published yet, but the rest is pretty much formality, and the flag is unlikely to change) So yes, technically the IETF did not recommend a hybrid algorithm”
In IETF ID, it is not recommended (https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-mlkem-03.txtz) but X25519 + ML KEM 768 (0x11EC) is still provided and it is marked as recommended in cloudefare (https://developers.cloudflare.com/ssl/post-quantum-cryptography/)
That’s the point! Someone who implements this—namely Cloudflare—can recommend anything they want _in their product_ even if it differs from the specification/standard. And anyone in 802.11bt who wants to implement anything we end up specifying can also do what they want. We cannot force a vendor to do anything. We can specify an MTI for interoperability purposes but that’s just to make sure your code works, it means nothing about how this gets deployed.
So the argument of a certain handset vendor that “we do not want to do pure ML-KEM” is fine. Don’t. No one is forcing you to. But when you want to stop anyone else from implementing pure ML-KEM it’s time for the gif—“you’re not my supervisor”.
Deploying a pure ML-KEM implementation, or even doing ML-KEM-512, involves a conscious effort. And both sides have to agree to do it. If this conflicts with what your “security group” says then by all means, don’t do it. But no one in TGbt, and no “security group” at any affiliated company of any participant, is qualified to tell me what I can and cannot do with post quantum 802.11. All they can legitimately say is “we do not want…” which is fine. Then don’t, no one is forcing you. But have the courtesy of not forcing your wants on everyone else.
Not being a cryptographer, logically speaking, if x is the security level provided by pure ML KEM and y is the security level provided by the classical DH, can we say x + y >= y, assuming that classical does not reduce the security of the pure ML KEM… there is nothing to lose with hybrid? Granted, according to the article, NSA uses only pure ML KEM 1024…
I think the guarantee is that the sum of the security is at least as secure as either of them. As far as “nothing to lose”, well there’s payload bloat, more messages to do both exchanges, and more fragments of messages since they’re bigger. Your evaluation of “nothing to lose” may differ from someone else’s.
Regards,
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
- Nehru
On Wed, Mar 25, 2026 at 4:37 PM Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Just ran across an interesting blog post by Sophie Schmieg, a cryptographer at Google. It discusses pure ML-KEM vs hybrid and dispels some of the myths that appeared in TGbt when we started discussing things beyond the simple “allowed” security profile—namely, “It will cause a downgrade attack!” and “it’s not secure enough”. Also, there is a hilarious gif which is the appropriate response to demands for “mandatory to implement” algorithms that you don’t want to support.
Enjoy: https://keymaterial.net/2025/11/27/ml-kem-mythbusting/
Regards,
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
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