Kris Kwiatkowski wrote: >My worry is that hybrids invite the attitude "I have battle-tested ECDH, so >ML-KEM quality matters less". That may hold for cryptanalytic risk, but not >for implementation bugs. If that attitude takes hold, it would be disastrous >for the migration to post-quantum crypto.
I very much share this concern. Unfortunately, this is not merely speculative, it is one of the primary design goals of SecP256r1MLKEM768, SecP384r1MLKEM1024, and draft-ietf-lamps-pq-composite-sigs. I think users of cryptography should stay away from these constructions. X25519MLKEM768 is different; its primary design goal is security. Cheers, John Preuß Mattsson From: Kris Kwiatkowski <[email protected]> Date: Tuesday, 7 July 2026 at 14:42 To: [email protected] <[email protected]> Subject: [TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) On 7/7/26 11:57, Henrick Hellström wrote: Firstly, there are at least two ways an implemented mechanism might be disabled at the library level; either by simply not linking it at build time (only shipping source and instructions on how to include it), or by a software switch that would have to be deliberately turned by the library consumer. If a library supports X25519MLKEM768, it necessarily ships a complete ML-KEM-768 implementation, since the hybrid needs it. So the "don't link it" option only applies to the pure code points, not to the ML-KEM code itself; that code runs in every hybrid handshake either way. My worry is that hybrids invite the attitude "I have battle-tested ECDH, so ML-KEM quality matters less". That may hold for cryptanalytic risk, but not for implementation bugs. If that attitude takes hold, it would be disastrous for the migration to post-quantum crypto.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
