[TLS] Re: [EXTERNAL] Re: Re: [EXTERNAL] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

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]