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]> 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]
