Interesting topic! As for a bad NRG, just taking m=NRG () could help attackers. Also, if m is a good randomness, hashing or not hashing does not matter.
So, is it poissble that hashing, m'=H(m) or H(m||nonce), will bring some new attacks or weaknesses that not applicable to no hashing, m=NRG ()? By assuming that H is secure, it seems possible to prove that hashing is more secure or at least secure as not hashing, at the cost of running H and lost of some entropy in m. Guilin 发件人：Jacob Appelbaum <[email protected]<mailto:[email protected]>> 收件人：David Cooper <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>> 时 间：2026-07-11 05:23:17 主 题：[TLS] Re: Generation of 'm' in ML-KEM (was Re: Re: [EXTERNAL] Re: Re: [EXTERNAL] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)) Hello David, On 7/10/26 18:52, David Cooper wrote: > This will be my only email on this subject, as it is completely off- > topic for this mail list. It is not off-topic. The topic is the security of ML-KEM, which is the draft under discussion. The sub-topic is "Generation of `m` in ML-KEM." The consensus period has ended, but there still seems to be confusion about key aspects of ML-KEM, and also about the claim that everything relevant was settled in the NIST process. It is fairly clear that there are matters relevant to TLS that are not settled in favor of protecting users. I appreciate that NIST is continuing to engage with the discussion. The full-court press from NIST is positive, even when it seems incoherent; our tax dollars are being well spent. I assume your email here is not an official NIST statement, but that you are speaking from your experience as a NIST person. > I also have no interest in responding to a potentially endless > stream of questions. I will keep this mostly to facts for the readers at home. They can make up their own minds. Naturally, NIST answering direct questions would make everything go much faster. Even faster would be proactive disclosure without anyone needing to ask. I will take what I can get. > When I look at https://nist.pqcrypto.org/foia/index.html, I only > see a small number of emails sent to [email protected], Please note that NIST could have proactively published all of this and saved us the trouble of wondering if there is still more to be revealed. > and all of them are from 2016 or 2017. That may be true for the subset of visible emails sent to `[email protected]`, but it does not show that NSA involvement stopped in 2017. The same FOIA release includes June 2020 internal material with NSA-originated technical comments on the Round 2 report [0]. Let us examine the editorial track-changes record from a June 2020 NIST document produced in the lawsuit. With apologies to Dustin Moody of NIST, it is important to mention him to present an accurate understanding. The Morgan mentioned here is understood to be Morgan Stern from NSA, the same Morgan Stern subscribed to and posting on this list. I could be mistaken about that, and hopefully Morgan will participate in the discussion. As the joke goes, if you want to talk to NSA, pick up the phone and call your mother. Here I will just post on the list and hope that the calls to my mother do not bring NSA to the discussion. For example, there is a track-changes comment by Dustin Moody on June 16, 2020 on page 5 that says: "from Morgan: Do you have a strong preference for timing versus power? Also, are you calling for more analysis of implementations (many algorithms have implementations, not many have independent verification of claims)?" On page 8: "from Morgan: You may want a summary of lattice-based and a summary of code-based (or a glossary) as certain terms are just repeatedly mentioned which may not make so much sense out of context (Regev's LWE, CoreSieve, information set decoding, Fujisaki-Okamoto)." "Dustin: I don't want a glossary, but curious what others think." "from Morgan: I will just point out here that prior to your competition this was not a well-known transform, so it probably bears citing somewhere (and maybe saying in the summary how much work has occurred tightening the reductions in the quantum case)." "from Morgan: I've always felt very odd about this line of work: On the nonce-reuse work (as opposed to the other fault papers) the attack works because the author went with an easy-to-implement strategy. If they had done something less elegant (which would have been criticized for being sloppy and would be more prone to mis-implementation) there still could have been an attack, but it would have been less likely to be found." "Doesn't appear to suggest a change - rather just an observation" That Dustin was reading for suggestions to change the report sure appears like Dustin was editing for Morgan. Why deny NSA involvement or influence when these documents show NIST people taking technical and editorial suggestions from NSA? On page 9: "from Morgan: First mention of this so you likely want a citation. If you decide to have a lattice overview, you may also want to mention why you are using this metric (call out the "Estimate all the {LWE, NTRU} schemes" paper you had at your first conference, or Darmstadt Lattice Challenge record recently). Also, you are inconsistent with the capitalization of the phrase." "from Morgan: I might comment on the fact that they themselves went into considerable analysis on what the precise strength was (as in, it was what they aimed for)." Dustin responds with: "I added a citation. Is it the right one?" The end of page 9 is interesting primarily because it contains discussions about cryptanalytic attacks: "In NIST's view, FrodoKEM may be suitable for use cases where a low security risk from cryptanalytic attacks is considered much more important than performance. NIST's first priority for standardization is a KEM that would have acceptable performance in widely-used applications overall. As such, possible standardization for FrodoKEM can likely wait until after the third round. FrodoKEM could also serve as a conservative backup, in the case of new cryptanalytic results being discovered in the third round. For these reasons, FrodoKEM was not selected as a finalist, but as one of the alternate candidates advancing." Page 9 includes Morgan highlighting this part of the above paragraph: "low security risk from cryptanalytic attacks" Morgan's comment says: "from Morgan: I would likely not use this phrase" Page 10 includes this: "from Morgan: I would probably try for a "bottom-line" a little earlier here. Start the paragraph with something like: In a technical sense, the security is never better than Kyber." This text ended up in NIST's official rationale for choosing Kyber rather than NewHope. There are other comments such as this gem on page 19: "NIST encourages the DILITHIUM team to add a category 5 parameter set. More study is also needed on understanding the concrete security, as DILITHIUM has relatively lower CoreSVP security strength than other lattice-based round 2 schemes. NIST selected DILITHIUM as a finalist, and expects that either DILITHIUM or FALCON will be standardized as the primary post-quantum signature scheme at the conclusion of the third round." The following text is highlighted: "More study is also needed on understanding the concrete security, as DILITHIUM has relatively lower CoreSVP security strength than other lattice-based round 2 schemes." The comment says: "from Morgan: if you want them to up their CoreSVP, you should explicitly say it, since you don't want them to change their parameters partway through round 3." Page 22 has the following text: "NIST researchers noted a gap between performance and theoretical complexity for a few attack avenues relevant to the Rainbow scheme. During the second round, some tighter theoretical analyses of as well as new algorithms for these well-known attacks have been published, see [20] and [15]. In particular [20] shows that a parameter tweak is necessary for all parameter sets to achieve the claimed levels of security. Still, with a more conservative parameter selection it will be possible to meet the claimed security levels with minimal performance cost." This sentence is highlighted from the paragraph above: "In particular [20] shows that a parameter tweak is necessary for all parameter sets to achieve the claimed levels of security. Still, with a more conservative parameter selection it will be possible to meet the claimed security levels with minimal performance cost." This is the comment associated with the highlight: "from Morgan: the Rainbow designers may not have much time to digest your analysis, and I would assume you want to standardize whatever parameters come into Round 3." Dustin added a second comment directly after the above comment: "He also noted that the write-up could be taken as a case for Rainbow being an alternate, so the reasons for being a finalist should be emphasized." Page 23 highlights "SPHINCS+" in the Section 3.26 header: "from Morgan: Your write-up for SPHINCS+ reads very similarly to the write-up for McEliece but you conclude it is a backup for standardization, as opposed to a standard that is ready to go as a backup." Personally, I would not characterize NSA as having no involvement or influence when the released documents show that NSA clearly communicated technical and editorial suggestions and evaluated evidence about rankings. NSA thought NIST would not want Dilithium to change its parameters partway through round 3. NSA also said there could be a case for Rainbow being an alternate. I am not even disagreeing with Morgan's observations. I am concerned that NIST did not show this communication in public without being sued by an interested third party to force production of the documents. I am also baffled why NIST later obfuscates and plays word games where it refused to engage with basic technical questions. This behavior by NIST is not engendering trust. This is in the context of trust in NIST being seriously damaged by public reporting about PROJECT BULLRUN's cryptographic sabotage, including using NIST to push Dual_EC_DRBG. By the way, Morgan was probably correct in at least one way when he commented: "In a technical sense, the security is never better than Kyber" - after all, Kyber hashed `m` at that point in time. I find it hard to believe that Morgan would say that Kyber-with-hashed-m and ML-KEM-with-raw-m are the same. > The most interesting result I see when searching this page for > "[email protected]" is from May 2017: > > We hope you'll be part of our post-quantum crypto project.... > > ... > > I've added you to the email alias "[email protected]" which we > use to send PQC stuff to all the other members of the project (all > NIST people). > > > Whereas the last email to "pqc" appears to have been sent before the > deadline for submitting proposals for PQC algorithms, many emails > were sent to "internal-pqc" over the years. This website's contents are the result of an adversarial legal process where NIST had to be sued to reveal the documents on that webpage. I was not involved with the lawsuit. I find it hard to believe that it is a comprehensive list of all NIST communications during the PQC process. We actually know that it is not a comprehensive list. NIST should save everyone the time and publish everything. > The email saying that comments from Donna and the NSA were > incorporated into the NISTIR was sent in January 2016. The comments > were on a NISTIR that Dustin said he hoped to publish by the end of > month if possible (end of January 2016). The NISTIR 8413 cited in > FIPS 203, which reports on the third round of the PQC > standardization process, was published in 2022. According to > https:// csrc.nist.gov/Projects/post-quantum- cryptography/ > publications, NISTIR 8105, Report on Post-Quantum Cryptography, was > published in April 2016. Perhaps Donna and the NSA commented on > NISTIR 8105. The "perhaps" is doing a lot of work in that sentence. It would be better if NIST just told us without a lawsuit. Regardless, NISTIR 8105 [1] also does not mention that NSA gave comments and that its feedback was incorporated. NISTIR 8413 following it is naturally related, and the public messaging from NIST about NSA's involvement remains lacking. It also strains credibility when absolute claims by NIST are contradicted by NIST's own documents, but only after a lawsuit produces them. > It seems that an actual reading of the FOIA material presents a very > different picture than the message below. Sure, if you selectively read what interests you, and if you are not part of the NIST/NSA working group, I would expect a selection bias that would bias the view of the overall situation as well. You are welcome to clarify your own role in the NIST/NSA working group if you think that would help readers understand the situation. Various security clearance obligations and other conflicts of interests are helpful context for everyone. Totally unrelated, but contrary to the impression given in my emails, I actually like many NIST standards. Especially NIST's synthetic turf on-site laboratory assessment accreditation [2]. I also like my coffee like I like my cryptographic standards: strong and without any secret NSA influence. Thank you for your work on ML-KEM. I hope you will encourage hashing of `m` and that NIST will issue errata for defense-in-depth against Dual_EC_DRBG-shaped threats. All the best, Jacob Appelbaum [0] https://nist.pqcrypto.org/foia/20241115/ pqc%20round%202%20report.pdf-attachment- PQC%20Report%20on%20Round%202%20June%2016.docx [1] https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8105.pdf [2] https://www.nist.gov/system/files/documents/2020/11/12/ LB-133-2020%20Synthetic%20Turf%20Testing%20in%20CCC.pdf > > On 7/8/26 11:10, Jacob Appelbaum wrote: >> 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 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<http://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: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] _______________________________________________ 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]
