Just to be very clear, NIST SP 800-90a does not include DUAL_EC_DRBG, and has not for more than a decade now. In my entire professional career I have not seen an implementation of DUAL_EC_DRBG, must less a deployment. The way random number generator fails is because someone includes math.rand instead of crypto.rand in golang (thankfully since fixed by Fillipo), not that they were somehow tricked into deployment of DUAL_EC_DRBG. You might as well guard against ghosts haunting the wire in CPUs. The chance of a backdoor being introduced through a random number generator is about as large as a backdoor in any other component of the system in question.
On Sat, Jul 11, 2026 at 1:14 PM Jacob Appelbaum <[email protected]> wrote: > Hi Henrick, > > On 7/11/26 19:43, Henrick Hellstrom wrote: > > I agree, that discussion could be generalized and carried over to > > the TLS security considerations. > > I'm glad we agree on that. The remaining question is what the text > should say. > > I would suggest something along these lines: > > FIPS 203 requires that ML-KEM.KeyGen and ML-KEM.Encaps use fresh > randomness generated by a NIST-approved randomness source. > Implementations should not use raw primary RNG output directly as > the ML-KEM `m` value because that value is recoverable by the > decapsulating peer. Implementations should use a properly separated > RBG/DRBG and/or a context-bound derivation for ML-KEM encapsulation > randomness, and as the original design of Kyber did `m <- H(m)`, > the `m` value should be hashed by a suitable secure cryptographic > hash function. This is a defense-in-depth measure against > hidden-structure RNG failures, including Dual_EC_DRBG-shaped > kleptographic attacks. > > I am not attached the text but the core message is very important. > > > In the case of ML-KEM specifically, you get it implicitly for TLS as > > long as the implementation of ML-KEM is fully FIPS 203 conformant. > > This is what the relevant paragraph on page 16 of FIPS 203 says: > > > > "Randomness generation. Two algorithms in this standard require the > > generation of randomness as an internal step: ML-KEM.KeyGen and ML- > > KEM.Encaps. In pseudocode, this randomness generation is denoted by > > a statement of the form m <- B32. A fresh string of random bytes > > must be generated for every such invocation. These random bytes > > shall be generated using an approved RBG, as prescribed in SP > > 800-90A, SP 800-90B, and SP 800-90C [18, 19, 20]. Moreover, this RBG > > shall have a security strength of at least 128 bits for ML- KEM-512, > > at least 192 bits for ML-KEM-768, and at least 256 bits for ML- > > KEM-1024." > > I understand that argument and I am surprised when really intelligent > people fall for this extremely low budget argument. It doesn't even have > to be an Adversary trick, it's simply not an actually met requirement > most of the time in reality. The core problem is that TLS deployments do > not automatically become fully validated FIPS 203 environments merely by > using ML-KEM. The TLS draft also does not currently call out this > specific FIPS 203 dependency in its Security Considerations but it has > other details, oddly. > > So I do not think TLS gets this protection "implicitly" in a way that is > clear enough for implementers. I have surveyed quite a number of > libraries and found that FIPS203 is followed for the removal of the hash > over `m` but rarely, if ever, for the NIST-approved entropy source as a > hard requirement. The draft _should_ say the assumption explicitly, and > it should say why it matters since it is absolutely critical for security. > > Relying only on the phrase "approved RBG" is also not enough history for > this particular discussion. Dual_EC_DRBG was once standardized in the > same general family of standards. The lesson should not be "trust the > label"; it should be "do not expose structured RNG output when cheap > separation or whitening avoids it." > > If an implementation is not FIPS-constrained, then restoring Kyber-style > `m <- H(m)` or using a context-bound derivation of `m` is the simpler > defense-in-depth answer. If side-channels are a concern then I observe > that having a remote oracle isn't likely to make those less effective. > > Either way, the security goal is the same: do not give the decapsulating > peer a clean sample of raw, structured RNG output. > > Kind regards, > Jacob > > [0] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/ > m/o2XJ2YvfAwAJ > <https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/WFRDl8DqYQ4/m/o2XJ2YvfAwAJ> > > [1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf > > > > On 2026-07-11 18:00, Jacob Appelbaum wrote: > >> Hi Henrick, > >> > >> On 7/11/26 13:53, Henrick Hellström wrote: > >>> Hi Jacob, > >>> > >>> On 2026-07-09 18:11, Jacob Appelbaum wrote: > >>>> Obviously no one should use Dual_EC_DRBG. The problem is that > >>>> users often do not know when their randomness source is > >>>> sabotaged. Hashing does not solve all bad-RNG problems, but it > >>>> does destroy the > >>> algebraic > >>>> structure used in this known attack class. > >>> > >>> Yes, I understand this might once have been brought in as a > >>> quick-fix for Dual_EC-DRBG debacle, but at this time it ought to > >>> be replaced by a more permanent fix. > >>> > >> I agree that a permanent fix is better than an ad hoc fix. > >> > >> Where I disagree is the implication that the issue has already > >> been permanently fixed in the TLS draft. If the permanent fix is > >> "never hand raw primary RBG output to ML-KEM.Encaps() as > >> decapsulator-recoverable `m`", then that should be stated clearly > >> in the Security Considerations. > >> > >> The Kyber hash was not merely nostalgia for Dual_EC_DRBG. It was a > >> cheap defense-in-depth step against exposing raw system RNG output > >> to the recipient. Prof. Dr. Peter Schwabe made that point > >> explicitly during the NIST discussion [0]. FIPS 203 removed that > >> step and instead relies on a requirement for approved randomness > >> generation [1]. That dependency is exactly what the TLS draft > >> should surface. > >> > >>> Because who exactly do you mean by "user" in this context, and > >>> what kind of conformance certification is required? > >> > >> By "user" I mean the people who rely on TLS deployments: browser > >> users, citizens using government systems, operators, > >> administrators, device owners, library consumers, and people > >> depending on remote services. They are usually not in a position > >> to audit whether a hardware RNG, firmware RNG, HSM, cloud module, > >> or library RNG is sabotaged. > >> > >> That is why this belongs in protocol security guidance. A lab > >> conformance story is not the same thing as user protection. > >> > >>> If you would want the implementation to be FIPS 140 conformant, > >>> the randomness source consumed by ML-KEM would have to be an > >>> approved DRBG, but it can be a secondary DRBG, like I described, > >>> and it should be one of the symmetric, more easily analysed > >>> DRBGs. > >> > >> That may indeed be a good answer if it is mandatory, isolated, and > >> specified carefully. > >> > >> A secondary symmetric DRBG seeded from a primary RBG can plausibly > >> destroy Dual_EC_DRBG-shaped (x-coordinate) structure, provided > >> that raw primary output is not exposed elsewhere and the secondary > >> DRBG is properly instantiated, reseeded, separated by use, and > >> implemented. If that is the intended FIPS-friendly permanent fix, > >> then the draft should say so. > >> > >> What the draft should not do is silently inherit the assumption > >> "approved RBG" as if that alone answered the historical failure > >> mode. Dual_EC_DRBG was once standardized in the same general > >> standards family. The lesson should not be "trust the label"; it > >> should be "do not expose structured RBG output when cheap > >> separation or whitening avoids it." > >> > >>> On the other hand, if you add a hash between the approved DRBG > >>> and the ML-KEM implementation, it would become an algorithm that > >>> clearly differs from the specifications and requirements of NIST > >>> SP 800-90, so I doubt it would be FIPS 140 certifiable. > >> > >> This may be true for a strict FIPS validation boundary. If so, it > >> is not a rebuttal; it is the problem stated plainly. Also, this > >> isn't a draft about FIPS per se, though it is clearly very related > >> to IETF finding consensus on FIPS 203. > >> > >> If restoring Kyber's `m <- H(m)` step would make an implementation > >> no longer FIPS 140 certifiable as ML-KEM, then the TLS draft > >> should say what FIPS-constrained implementations are expected to > >> do instead. For example: use an approved, separate, symmetric DRBG > >> or approved derivation construction for ML-KEM encapsulation > >> randomness, with domain separation, so that raw primary RBG output > >> is never used directly as `m`. > >> > >> For non-FIPS-constrained implementations, Kyber-style hashing or > >> context-bound derivation of `m` remains the simple defense-in- > >> depth answer. For FIPS-constrained implementations, the answer may > >> be a validated secondary DRBG construction. Either way, the > >> security goal is the same: do not give the decapsulating peer a > >> clean sample of raw, structured RNG output. > >> > >> So I think we may be closer than it first appeared. If your > >> position is: > >> > >> "Do not use raw primary RBG output directly as ML-KEM `m`; use a > >> properly separated approved secondary DRBG instead if FIPS > >> validation is required" > >> > >> then I would appreciate seeing that written into the draft's > >> Security Considerations, along with the reason it matters to > >> implementers. > >> > >> Kind regards, Jacob > >> > >> [0] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ > >> WFRDl8DqYQ4/ m/o2XJ2YvfAwAJ > >> > >> [1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf > >> > >> [2] https://csrc.nist.gov/pubs/fips/140-3/final > >> > >>>> On 7/9/26 10:39, Henrick Hellstrom wrote: > >>>> > >>>>> On 2026-07-09 10:10, Tanja Lange wrote: > >>>>> > >>>>>> The question by Benjamin Kaduk was if there are cases > >>>>>> where the > >>>> server hellow would not leak the state of the PRNG (adding P > >>>> for clarity^*) and Botan implements that protection. There are > >>>> other libraries that have seperate PRNGs for public and > >>>> private values. > >>>> > >>>> To further support Tanja's point: The sub-topic is not > >>>> ordinary PRNG quality. It is avoiding leakage of bytes that > >>>> can form a covert channel and carry algebraic structure from > >>>> kleptographic RNGs such as Dual_EC_DRBG. That kind of leakage > >>>> can happen through many protocol fields, including TLS fields, > >>>> and it is a specification-level defense- in-depth gap. > >>>> > >>>> ML-KEM as finalized in FIPS 203 removed Kyber's hash over `m`, > >>>> even though at least one Kyber designer explicitly argued that > >>>> hashing `m` avoids sending system RNG output to the recipient > >>>> [0]. NIST later announced that the hash would be removed [1]. > >>>> I have not seen an analysis from NIST showing that this > >>>> removal remains safe against their own historical example: > >>>> Dual_EC_DRBG, a DRBG NIST described as "provided by NSA," > >>>> which NIST later said there were many reasons to reject or > >>>> modify, but "instead, we left it in" [2][3]. > >>>> > >>>> Any such analysis would have had to address the central point: > >>>> hashing destroys the Dual_EC_DRBG algebraic structure needed > >>>> for efficient state recovery. > >>>> > >>>>> Yes, but just hashing the output from a DRBG is not the > >>>>> approved way > >>>> to do it. Instead you are supposed to spawn a secondary DRBG > >>>> with a seed generated from a primary DRBG. > >>>> > >>>> That may be an approved construction for ordinary DRBG > >>>> engineering, but it is not obviously a defense against a DRBG > >>>> whose output is intentionally structured to leak its state. If > >>>> the primary DRBG is Dual_EC_DRBG-shaped, spawning another DRBG > >>>> from it may simply give the defender two things to audit. > >>>> Please point me to the specific approval text you mean where > >>>> the "do it" is defending against this class of Dual_EC_DRBG > >>>> kleptographic backdoor. > >>>> > >>>> Dual_EC_DRBG output can look secure by many metrics and still > >>>> act as a covert channel [4]. With the relevant trapdoor/ > >>>> secret key(s), an Adversary who can sample enough output can > >>>> recover DRBG state and predict future outputs. The general > >>>> attack is well established [5][6] [7]. The RSA/Dual_EC_DRBG > >>>> reporting and the BULLRUN reporting are the relevant > >>>> historical context here [8][9]. > >>>> > >>>> Obviously no one should use Dual_EC_DRBG. The problem is that > >>>> users often do not know when their randomness source is > >>>> sabotaged. Hashing does not solve all bad-RNG problems, but it > >>>> does destroy the algebraic structure used in this known attack > >>>> class. > >>>> > >>>>> Just hashing wouldn't do much good, if you are really > >>>>> concerned that > >>>> the DRBG output might reveal anything about the internal > >>>> state. > >>>> > >>>> For this attack class, it does good. > >>>> > >>>> Hashing `m` during `ML-KEM.Encaps()`, for example with the ML- > >>>> KEM public key and/or transcript context, binds `m` to context > >>>> before the ML-KEM ciphertext is sent. In the normal non-ECH > >>>> TLS 1.3 case, that closes the Dual_EC_DRBG-shaped oracle > >>>> against the server's RNG output. With ECH using ML-KEM or a > >>>> hybrid KEM, the same concern can arise in both directions. > >>>> > >>>> A few objections have come up repeatedly: > >>>> > >>>> 0. Ad-hominem attacks > >>>> > >>>> 1. TLS already has random fields written to the wire, so we > >>>> should not worry about ML-KEM > >>>> > >>>> 2. NIST already issued FIPS 203, so the IETF should not > >>>> revisit the issue > >>>> > >>>> 3. Updating drafts, RFCs, or implementations would be work > >>>> > >>>> 4. The issue also affects hybrids, so the hybrid > >>>> recommendation should be weakened > >>>> > >>>> 5. Hashing may not increase entropy > >>>> > >>>> 6. Hashing DRBG output merely creates a new DRBG, DRBG' > >>>> > >>>> Briefly: > >>>> > >>>> 0. The IETF mission is to make the Internet work better for > >>>> the people who use and manage it [10], and the IETF considers > >>>> pervasive monitoring an attack [11]. Cryptographic sabotage is > >>>> part of how pervasive monitoring becomes actionable > >>>> intelligence. Attacking the person raising the issue is > >>>> irrelevant to the technical question. > >>>> > >>>> 1. It is true that TLS has a broader problem with raw random > >>>> bytes in protocol-visible fields. That is a reason to fix the > >>>> broader issue, not a reason to preserve the same problem in > >>>> ML- KEM. Tanja pointed out that Botan already has a TLS > >>>> protection strategy. Other libraries use different ad-hoc > >>>> strategies, or none. That is exactly why IETF guidance would > >>>> help. > >>>> > >>>> 2. FIPS 203 being final is not the end of the story. NIST can > >>>> publish errata, revisions, or clarifications. NIST withdrew > >>>> Dual_EC_DRBG after public reporting on BULLRUN and related > >>>> cryptographic sabotage. A NIST participant who described > >>>> himself as a main author of FIPS 203 is on this list, and I > >>>> have asked for clarification on both the hashing decision and > >>>> the IPR implications. > >>>> > >>>> 3. Yes, updates take work. That is not a security argument. If > >>>> the Security Considerations of the draft omit an important > >>>> assumption and a cheap mitigation, that should be fixed. This > >>>> is a constructive suggestion and an easy win to build > >>>> consensus. > >>>> > >>>> 4. The issue also applies to hybrid X25519MLKEM* > >>>> constructions. The answer is not to weaken hybrids; it is to > >>>> hash `m` in the ML-KEM component. Failure to hash `m` can > >>>> contribute to compromising later values, including later > >>>> X25519 keypairs, if the same long-running RNG state is used > >>>> and no strong reseed or unknown additional input intervenes. > >>>> > >>>> 5. Hashing Dual_EC_DRBG output does not magically add entropy, > >>>> and may reduce it in some constructions. That is not the > >>>> point. The point is destroying hidden algebraic structure. We > >>>> should not shift the discussion from structure recovery to > >>>> entropy accounting and then conclude that no mitigation is > >>>> useful. > >>>> > >>>> 6. Yes, hashing DRBG output can be described as constructing > >>>> DRBG'. That is fine. DRBG' should still be treated as suspect, > >>>> but it no longer preserves the Dual_EC_DRBG x- coordinate > >>>> structure needed by the published attacks. Unkeyed hashing > >>>> appears sufficient to block the known Dual_EC_DRBG recovery > >>>> attacks; a keyed hash may be useful for stronger designs, but > >>>> it is not needed to make this point. > >>>> > >>>> My conclusion is simple: when history and user-centered harm > >>>> reduction are the concern, the arguments favor hashing. We > >>>> know this class of kleptographic attack is real. We know > >>>> standards influence is part of the game. We should not leak > >>>> raw pre-whitened system entropy to the network, and we should > >>>> not hand raw RNG-derived `m` to a potentially adversarial > >>>> decapsulator. > >>>> > >>>> To restate the completely obvious: this isn't an accusation of > >>>> a backdoor in ML-KEM. It is a statement of fact that a > >>>> defense- in-depth protection was knowingly removed by NIST. > >>>> NIST did so over the objection of several people > >>>> participating in the NIST PQC process, and without analysis > >>>> that accounts for the extremely serious failures of NIST in > >>>> the very recent past with regard to Dual_EC_DRBG. The change > >>>> by NIST serves as an example where surprise: no one is > >>>> responsible for the user's security even though the difference > >>>> in exploitability for the Dual_EC_DRBG scenario is roughly a > >>>> single hash function call. > >>>> > >>>> The IETF should give implementers clear guidance and it should > >>>> be in the draft's Security Consideration at the very least. > >>>> Hash `m`. Relatedly, do not write raw RNG output into > >>>> protocol- visible fields when cheap whitening destroys known > >>>> hidden structure. > >>>> > >>>> Kind regards, Jacob Appelbaum > >>>> > >>>> P.S. > >>>> > >>>> Consider also the scale of the budgets for only a single > >>>> agency [12]. It may also be worth your time looking at the > >>>> cryptographic libraries worked on by former NSA people once > >>>> they were officially out of government and firmly on the > >>>> defending side of the fence. It is also informative for > >>>> spotting the folks who have retained their first job while > >>>> taking on another, another thing we learned about PROJECT > >>>> BULLRUN. Remember: there is no need for accusations of a > >>>> conspiracy as the business plan as the documented [12] attack > >>>> budget appears to exceed the IETF's operating budget by a very > >>>> large margin. The larger issue isn't even really about the NSA > >>>> as the NSA's track record serves as a fairly clear example of > >>>> what to look for from many other large-scale adversaries. > >>>> > >>>> [0] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ > >>>> WFRDl8DqYQ4/ m/o2XJ2YvfAwAJ > >>>> > >>>> [1] https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ > >>>> WFRDl8DqYQ4/ m/MRa5O0CvAAAJ > >>>> > >>>> [2] https://rwc.iacr.org/2015/Slides/RWC-2015-Kelsey-final.pdf > >>>> > >>>> [3] https://csrc.nist.gov/csrc/media/projects/crypto- > >>>> standards- development-process/documents/ > >>>> dualec_in_x982_and_sp800-90.pdf > >>>> > >>>> [4] https://csrc.nist.gov/glossary/term/covert_channel > >>>> > >>>> [5] https://rump2007.cr.yp.to/15-shumow.pdf > >>>> > >>>> [6] https://eprint.iacr.org/2015/767 > >>>> > >>>> [7] https://www.usenix.org/system/files/conference/ > >>>> usenixsecurity14/ sec14-paper-checkoway.pdf > >>>> > >>>> [8] https://www.reuters.com/article/world/exclusive-secret- > >>>> contract- tied-nsa-and-security-industry-pioneer- > >>>> idUSBRE9BJ1C5/ > >>>> > >>>> [9] https://www.theguardian.com/world/2013/sep/05/nsa-gchq- > >>>> encryption- codes-security > >>>> > >>>> [10] https://datatracker.ietf.org/doc/html/rfc3935 > >>>> > >>>> [11] https://datatracker.ietf.org/doc/html/rfc7258 > >>>> > >>>> [12] https://archive.nytimes.com/www.nytimes.com/ > >>>> interactive/2013/09/05/ us/documents-reveal-nsa-campaign- > >>>> against- encryption.html > >>> > >> > > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
