Hi Jacob, Everything I wrote in the message at 9:44AM US Eastern time 7/8/2026 is factual regardless of many questions you had for me about things.
Every technical change was publicly discussed at the pqc-forum and there was a publicly known reason for the change. Beside the removal of the hash of m, are there any other technical details concerning you about the security of ML-KEM in TLS 1.3 ? Have a great day. Regards, Quynh. PS: Don't be surprised if I don't answer your questions if I think they are not technically important to ML-KEM's security in TLS 1.3. And, likely I won't answer a question if it has already been discussed at the forum. > -----Original Message----- > From: Jacob Appelbaum <[email protected]> > Sent: Wednesday, July 8, 2026 2:11 PM > To: Dang, Quynh H. (Fed) <[email protected]>; TLS List <[email protected]> > Cc: Markku-Juhani O. Saarinen <[email protected]> > Subject: Re: [EXTERNAL] Re: [TLS] Re: [EXTERNAL] Re: WG Last Call: draft-ietf- > tls-mlkem-08 (Ends 2026-07-08) > > 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.or/ > g%2F10.6028%2FNIST.IR.8413- > upd1&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1 > a1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0% > 7C639191384484652031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld > UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Rlb5zid5iEipm%2F2fzO%2FMsL > GO8tIfr2nPEBwbPA6u4I%3D&reserved=0 " > > 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.p/ > qcrypto.org%2Ffoia%2Findex.html&data=05%7C02%7Cquynh.dang%40nist. > gov%7C8a0445ed945f404f1a1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e > 054655c61dec%7C0%7C0%7C639191384484715842%7CUnknown%7CTW > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KQ > D%2F%2FTl4lLVgd1YCz5WHMVboj9k7mBmT8iAR8Ypwd%2FQ%3D&reserved > =0 > > [1] > https://nist.p/ > qcrypto.org%2Ffoia%2Fhighlights.html&data=05%7C02%7Cquynh.dang%40 > nist.gov%7C8a0445ed945f404f1a1b08dedd2d61b4%7C2ab5d82fd8fa4797 > a93e054655c61dec%7C0%7C0%7C639191384484767533%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi > JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=l > 7f7UaDwXTyaTXOuYwYqn2YceWpcuAxic42VhpgiATE%3D&reserved=0 > > [2] > https://nist.p/ > qcrypto.org%2Ffoia%2F20230815%2FRe_%2520pqc%2520mailing%2520list > &data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1a1b0 > 8dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C63 > 9191384484812340%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=esh2gmMa5l0D9chFkhE%2FgusyQP0 > 9wP0ndToGTyUj4bA%3D&reserved=0(1)-3.pdf > > [3] > https://web/. > archive.org%2Fweb%2F20230910091944%2Fhttps%3A%2F%2Fcsrc.nist.gov > %2FCSRC%2Fmedia%2FEvents%2FISPAB-MARCH-2014- > MEETING%2Fdocuments%2Fa_quantum_world_v1_ispab_march_2014.pdf& > data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1a1b08d > edd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C6391 > 91384484853183%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > %3D%3D%7C0%7C%7C%7C&sdata=7fBkCMQjFUXEEl5M07iBe8Ahnf0gm%2 > BHps5sQ9KRXb2Q%3D&reserved=0 > was authored by "Post Quantum Cryptography Team, National Institute of > Standards and Technology (NIST), [email protected]" > > [4] > https://nist.p/ > qcrypto.org%2Ffoia%2F20230815%2FRe_%2520pqc%2520mailing%2520list > &data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f404f1a1b0 > 8dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C63 > 9191384484884591%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=7qLvBB0Se4BCW5rT2D6Qe4%2FW66 > LwDds5xMDEFF5iNz8%3D&reserved=0(1)-3.pdf > includes the list of [email protected] people > > [5] > https://nist.p/ > qcrypto.org%2Ffoia%2F20230915%2FRe_%2520PQC%2520NISTIR%2520ve > rsion%25202&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed94 > 5f404f1a1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0 > %7C0%7C639191384484909081%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sdhN0Wr05ckhl9vb4Roy > qPnTC86VVzZWkEwAW55GlcY%3D&reserved=0(2).pdf > > [6] > https://nvlpu/ > bs.nist.gov%2Fnistpubs%2FFIPS%2FNIST.FIPS.203.pdf&data=05%7C02%7Cq > uynh.dang%40nist.gov%7C8a0445ed945f404f1a1b08dedd2d61b4%7C2ab > 5d82fd8fa4797a93e054655c61dec%7C0%7C0%7C639191384484927281% > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C > %7C%7C&sdata=6IyafioHpbMx620xq1tn0MgWzftZUcipmB5Zx2qS3Bk%3D&r > eserved=0 > > > > 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 > >> > http://www/. > >> > etsi.org%2F&data=05%7C02%7Cquynh.dang%40nist.gov%7C8a0445ed945f > 404f1a > >> > 1b08dedd2d61b4%7C2ab5d82fd8fa4797a93e054655c61dec%7C0%7C0%7 > C639191384 > >> > 484950857%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjA > >> > uMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7 > C%7C%7 > >> > C&sdata=EhOquPsB1E2uZKRWUnBDEZ3K0dxtG8Gg3smMDcFxIa4%3D&reser > ved=0%2Fd > >> eliver%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: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]
