Hi all, See the discussion here about removing the hash of the message m.
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/qmVANi7EAwAJ The reason to remove it was that hashing m would be bad, introduce a cost for side-channel security implementations (ask Markku for detail). In addition, we require an approved RBG. If the RBG of a system is broken, or controlled by the attacker, the security of the whole system should be assumed to be broken anyway. I was a main author of the FIPS 203. Top level cryptographers know ML-KEM was not back-doored. Regards, Quynh. From: Thom Wiggers <[email protected]> Sent: Wednesday, July 8, 2026 5:52 AM To: Eliot Lear <[email protected]> Cc: <[email protected]> <[email protected]> Subject: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) Hi, ML-KEM is arguably not backdoorable unless you break the RNG. Bad RNG is something that we can't really protect against anyway. Classic cryptography is also broken if the RNG is busted. Finally, the TLS key schedule still mixes in all messages from both sides rendering the point moot for TLS. On a more instructive point, ETSI's "quantum-safe enterprise transport security" (ETSI TS 104 145<https://www.etsi.org/deliver/etsi_ts/104100_104199/104145/01.01.01_60/ts_104145v010101p.pdf>, paragraph 5.3.2) relies exactly on generating the encapsulation seed deterministically instead of randomly sampling one. This mainly breaks forward secrecy, which is certainly bad. But hybrids or not are not relevant to this. In the classic approach they simply fixed the DH public key of the server, iirc. Friends don't let friends use ETS. Cheers, Thom Op 8 jul 2026, om 11:35 heeft Eliot Lear <[email protected]<mailto:[email protected]>> het volgende geschreven: Hi! ~~~~Disclaimer I'm not a cryptographer. ~~~~ Please see below. On 08.07.2026 08:04, Viktor Dukhovni wrote: On Tue, Jul 07, 2026 at 10:27:56PM -0700, Christian Huitema wrote: I just read Jacob Applebaum's message. Given his description of the late-standardization suspicious change that looks like a backdoor in the ML-KEM specification, I agree with his conclusion. The WG should not ask for publication of the current graph, not until the changes requested by Jacob are made. The removal of whitening of the `m` random input to Encaps is not a plausible backdoor. If all you have is a broken RNG, you're free to apply whitening to obtain a new less bad RNG and use that instead. Nothing stops an ML-KEM implementation from hashing some input (any number of times, mixing in whatever additional inputs, ...) to produce its random values. The abstract algorithm starts from the final output of an adequate RNG that requires no further post-processing. There's nothing suspicious about this simplification. The critique in question makes no sense to me. Don't use a broken RNG. That sounds about right to me, but as someone who is not a cryptographer, perhaps someone who is could explain how this amounts to a back door, and not a requirement for a good PRNG? And if it's not a back door, should we really relitigate NIST's choices here? Eliot * By "back door", I mean an intentionally placed undisclosed weakness that could be exploited by the people who placed it there. <OpenPGP_0x87B66B46D9D27A33.asc>_______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
