Hi Jacob, The group authoring FIPS 203 did not have any meeting with the NSA and the NSA had zero authorship of the FIPS 203.
At the time of authoring/writing FIPS 203, we were very confident in the security of the NIST-approved RBGs, we wanted people to use them, so the FIPS had a requirement of using an appropriate security strength NIST-approved RBG. As others have pointed out before, hashing m in the ML-KEM's spec only protects the KEM, the whole system is still considered compromised when other crypto functions rely on the security of the broken or attacker-controlled RBG. We think we made a good judgement call to remove the hash (discussed in my previous email). We also understood the reason that some others wanted to keep the hash. Regards, Quynh. > -----Original Message----- > From: Jacob Appelbaum <[email protected]> > Sent: Wednesday, July 8, 2026 7:21 AM > To: Dang, Quynh H. (Fed) <[email protected]>; TLS List <[email protected]> > Cc: Markku-Juhani O. Saarinen <[email protected]> > Subject: [EXTERNAL] Re: [TLS] Re: [EXTERNAL] Re: WG Last Call: draft-ietf-tls- > mlkem-08 (Ends 2026-07-08) > > Hi Quynh, > > On 7/8/26 12:57, Dang, Quynh H. (Fed) wrote: > > And NSA did not ask us to consider removing the hash. > > For transparency and clarity: Are you making this statement as a participant > in > the confidential NIST/NSA working group meetings as part of authoring FIPS > 203? > > Kind regards, > Jacob Appelbaum > > > > > > Regards, > > Quynh. > > > > From: Dang, Quynh H. (Fed) > > Sent: Wednesday, July 8, 2026 6:42 AM > > To: TLS List <[email protected]> > > Cc: Markku-Juhani O. Saarinen <[email protected]> > > Subject: RE: [EXTERNAL] [TLS] Re: WG Last Call: > > draft-ietf-tls-mlkem-08 (Ends 2026-07-08) > > > > Hi all, > > > > See the discussion here about removing the hash of the message m. > > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou > > ps.google.com%2Fa%2Flist.nist.gov%2Fg%2Fpqc- > forum%2Fc%2FWFRDl8DqYQ4%2F > > > m%2FqmVANi7EAwAJ&data=05%7C02%7Cquynh.dang%40nist.gov%7C27e > 432e9a9ac41 > > > 68aad008dedce325b9%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C > 0%7C639191 > > > 065341348557%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwL > > > jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0 > %7C%7C% > > > 7C&sdata=nrQbwjt%2FNOMJAsb43n8djjf6m1ec%2BeAkEKUJSq1gIXQ%3D& > reserved=0 > > > > 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]<mailto:[email protected]>> > > Sent: Wednesday, July 8, 2026 5:52 AM > > To: Eliot Lear <[email protected]<mailto:[email protected]>> > > Cc: <[email protected]<mailto:[email protected]>> > > <[email protected]<mailto:[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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.etsi.org%2Fdeliver%2Fetsi_ts%2F104100_104199%2F104145%2F01.0 > 1.01_60%2Fts_104145v010101p.pdf&data=05%7C02%7Cquynh.dang%40n > ist.gov%7C27e432e9a9ac4168aad008dedce325b9%7C2ab5d82fd8fa4797a > 93e054655c61dec%7C0%7C0%7C639191065341386930%7CUnknown%7C > TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ > XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=g > gAnSn%2FHdBJ81j13mWw9Z%2FVAH47LG8xEjoNjarVQE0g%3D&reserved=0 > >, 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] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
