Hi Uri, I think it’s good that you point out that the classic component offers no protection against the “record now, decrypt later” threat. However, your conclusion that “The only use case when hybrid adds anything meaningful is if your data’s value is short-lived” is not correct. The classic component in hybrids can provide significant short-term value against theoretical attacks, side-channel attacks, and implementation bugs in the PQC component, regardless of the data’s lifetime.
There are good reasons why using multiple independent layers of protection is standard in high-security systems. For example, the NSA’s CSfC program states that a “solution uses two nested, independent tunnels to protect the confidentiality and integrity of data” [1]. In my view, Bernstein et al. are too focused on the algorithmic aspects of security protocols. When using a security protocol, for example, TLS, there are many potential vulnerabilities in other parts, such as the code or the protocol specification. If you truly want high security, you should follow the NSA’s guidance and use two nested, independent tunnels, preferably employing different protocols, different algorithms, and implementations by different teams. Cheers, John [1] https://www.nsa.gov/resources/commercial-solutions-for-classified-program/customer-handbook/?utm_source=chatgpt.com From: Blumenthal, Uri - 0553 - MITLL <[email protected]> Date: Friday, 20 February 2026 at 06:26 To: Izzy Grosof <[email protected]>, [email protected] <[email protected]> Subject: [TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27) > I would like to register my strong objection to this working group promoting > the use of non-hybrid ML-KEM in any way, or any other non-hybrid > post-quantum cryptosystem. I would like to register my strong disagreement with the above position. And register support for allowing the use of “pure”, aka non-hybrid ML-KEM (and other non-hybrid PQ cryptosystems). Among the reasons — since the goal of PQC is protecting data with long-term value — protection given by the Classic part of the hybrid is meaningless against the threat of “Record Now, Decrypt Later”. Confidentiality of the recorded-now sensitive data relies solely on the PQ part of the hybrid. The only use case when hybrid adds anything meaningful, is if your data value is short-lived, so it is not likely to be exposed to CRQC — so, Classic alone would suffice, and adding PQ KEM doesn’t hurt. The only situation when hybrid could make sense for a "long-term” data is if: 1. Crypto-Relevant Quantum Computer does not materialize; and 2. PQ algorithm falls to a Classic attack; and 3. Classic algorithm remains unbroken. > The correct course of action is to recommend against such an ill-advised > decision, That’s a matter of opinion. I consider your recommendation ill-advised, for reasons stated above. > The performance improvements of a non-hybrid approach are trifling; Correct. Though this depends on the use case — some would welcome the speedup of Lattice-based crypto over ECC. But this is not about the extra computations required for hybrid. > the security risks are immense, Simply not true. See above. The logic above is straightforward enough. Also, this might be instructive: System Proposed Standardized Lag-to-Standardization Math-Studied-For-How-Long RSA 1977 ~1993–1995 ~15–20 years Number theory: 2000+ years ECC 1985 ~1998–2000 ~13–15 years Elliptic curves: ~150 years Lattice crypto 1996 2022–2024 ~25 years Lattices: ~150–200 years McEliece 1978 2024 ~46 years Codes: ~60-75 years > given the breadth of attempted post-quantum cryptosystems that have fallen to > classical attacks; Given the number of standardized successful post-quantum crypto systems that stand strong, we shouldn’t panic needlessly. > I am baffled that so many people are taking a stand in favor of a non-hybrid > system, which is transparently unwise. Well, “wisdom" apparently is a relative term, because to me the position you’re advocating seems unwise. > For context, cryptography is not my area of research Coincidentally, it is mine. Plus, a few decades of experience (and some publications & patents, nothing earth-shattering).
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
