Hello Quynh, Thank you for your reply.
On 7/8/26 15:43, Dang, Quynh H. (Fed) wrote:
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.
This is a surprising statement given the public information about NIST and NSA's relationship.
Public FOIA material [0] appears to show substantial NSA involvement in NIST PQC work, which makes your statement surprising and worth clarifying.
The FOIA highlights [1] say the [email protected] team included more NSA members than NIST members and that NSA had secret input/meetings with NIST on PQC, but that is broader than FIPS 203 authorship:
"NIST's Post Quantum Cryptography Team was mostly NSA. The FOIA results show that what NIST publicly labeled as the "Post Quantum Cryptography Team, National Institute of Standards and Technology (NIST), [email protected]" actually had more NSA members than NIST members. The secret NSA members of the [email protected] team were Bradley C. Lackey, Daniel Kirkwood, David Hubbard, David Tuller, Jerry Solinas, John McVey, Laurie Law, Mark Motley, Nick Gajcowski, Scott Simon, and later Rich Davis." [2] [3] [4]
Some of those names are familiar to me. Are any on this list taking a position on the draft in question? A wonderful moment for government transparency has presented itself. Thank you to the IETF for this opportunity.
Looking at the released documents such as [5] where a well-known NIST (Top) Cryptographer wrote in his email: "I’ve incorporated the revisions and edits we discussed regarding the comments received from Donna and the NSA." Quynh - the email metadata from that FOIA release says that you were in the CC list.
How should the public reconcile your claim with the released email [5] saying that comments from "Donna and the NSA" were incorporated?
Is this a mistake or a misunderstanding? For example are you not counting [5] comments from the NSA... because their feedback was incorporated into the PQC NISTIR version 2 document as part of the larger PQC process? Does that mean NIST's position is that FIPS 203 wasn't influenced by their own PQC NISTIR document? I read `NISTIR` in Section 2.2 Acronyms (on page 4) of FIPS 203 and the NISTIR is cited as reference [23] (on page 43) of FIPS 203 [6]:
"Alagic G, Apon D, Cooper D, Dang Q, Dang T, Kelsey J, Lichtinger J, Liu YK, Miller C, Moody D, Peralta R, Perlner R, Robinson A, Smith-Tone D (2022) Status report on the third round of the NIST post-quantum cryptography standardization process (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8413. https://doi.org/10.6028/NIST.IR.8413-upd1 "
I do not see how to reconcile your statement with the public FOIA record without a more precise definition of "the group authoring FIPS 203," "meeting," and "authorship."
It would be immensely helpful if you or NIST could clarify - who do you include by name in the group authoring FIPS 203 and what exactly do you mean by a meeting?
It sounds pedantic, I realize. Unfortunately it is only because of a proactive lawsuit against NIST that members of the public are able to cite the above emails. NIST could do themselves a big favor here and release significantly more information without being forced through legal process.
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.
Didn't NIST write FIPS 203 _after_ NIST's John Kelsey did the retrospective on NIST's failure in the Dual_EC_DRBG fiasco? Was this history not part of your threat model or included in your (internal or external) analysis in any documented manner?
There's an old joke about the TSA and how it tries to solve yesterday's security threats tomorrow. Is NIST... at least trying to solve its own security catastrophes of a decade ago... today or at least for... tomorrow?
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.
Okay - I understand that we agree that hashing `m` is not harmful to the ML-KEM spec. I also understand that we agree that hashing m even protects the KEM.
But do I understand the rest of your point? I read you as saying that... NIST... left the `m` unhashed so that the KEM would be unprotected because... the rest of the system would also be compromised anyway?
Do you dispute that, if `m` is produced by a Dual_EC_DRBG-shaped RNG, not hashing `m` allows a TLS client to obtain a useful oracle that hashing `m` would close?
Hashing `m` would protect the KEM and close this ML-KEM oracle against a Dual_EC_DRBG-shaped NOBUS advantage for a large-scale adversary. Naturally, if the larger protocol leaks a similar RNG state before or after, we would have more than one problem to resolve. Still, we should try to resolve each of the issues rather than pointing at related problems to justify solving none of them.
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.
What is the standard of evidence that would convince you personally or NIST to the contrary to issue an errata such that `m` is hashed to prevent this issue?
For example, what if someone showed you a construction to make ML-KEM not just secure against this exact issue but also to resolve the hybrid debate without any extra bytes on the wire? I have such a design and I have implemented it.
Relatedly, would NIST ensure that the patent/IPR concerns would not be enforced against such an implementation?
It would help to clarify whether NIST’s patent license agreements apply only to ML-KEM as published by NIST, or also to variants that hash `m` or otherwise transform `m`. If developers are free to hash `m` or to use a non-NIST-approved RBG under NIST's patent license agreements, I am certainly not alone in welcoming clarification on this matter.
I have posed many questions, and I appreciate you taking the time to read them. Thanks in advance, and thank you again for your work authoring FIPS 203.
Kind regards, Jacob Appelbaum [0] https://nist.pqcrypto.org/foia/index.html [1] https://nist.pqcrypto.org/foia/highlights.html[2] https://nist.pqcrypto.org/foia/20230815/Re_%20pqc%20mailing%20list(1)-3.pdf
[3] https://web.archive.org/web/20230910091944/https://csrc.nist.gov/CSRC/media/Events/ISPAB-MARCH-2014-MEETING/documents/a_quantum_world_v1_ispab_march_2014.pdf was authored by "Post Quantum Cryptography Team, National Institute of Standards and Technology (NIST), [email protected]"
[4] https://nist.pqcrypto.org/foia/20230815/Re_%20pqc%20mailing%20list(1)-3.pdf includes the list of [email protected] people
[5] https://nist.pqcrypto.org/foia/20230915/Re_%20PQC%20NISTIR%20version%202(2).pdf
[6] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
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 AppelbaumRegards, 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%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fg%2Fpqc-forum%2Fc%2FWFRDl8DqYQ4%2Fm%2FqmVANi7EAwAJ&data=05%7C02%7Cquynh.dang%40nist.gov%7C27e 432e9a9ac4168aad008dedce325b9%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C 0%7C639191065341348557%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0 %7C%7C%7C&sdata=nrQbwjt%2FNOMJAsb43n8djjf6m1ec%2BeAkEKUJSq1gIXQ%3D& reserved=0The reason to remove it was that hashing m would be bad, introduce a costfor 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 issomething 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 transportsecurity" (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 seeddeterministically 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 produceits random values. The abstract algorithm starts from the final outputof 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 thatcould 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:tls- [email protected]> _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to tls- [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
