[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08) (was Re: Re: Response to CoI Complaints)
Jacob Appelbaum <[email protected]> Sun, 19 Jul 2026 15:46:41 +0200
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <[email protected]> |
Hi Mark, On 7/19/26 00:29, [email protected] wrote: > Hi Jacob, > > I will be brief in my response, as I believe the vast amount of > prose on this subject makes things harder to follow for no reason. > I believe we are all on the same page regarding the following two > points. > I take your point about the prose. Sadly, we are not entirely on the same page. I also read that your conclusion is that we should leave implementers vulnerable by not mentioning the issues in any draft under discussion for this class of attack strategies. Is that correct? > 1. The sole justification for pre-hashing is to defend against an > algorithm substitution attack, where an adversary swaps out your > RNG with an atypically weak (possibly backdoored) RNG. An explicit > example is DUAL_EC_DRGB using default parameters. What algorithm is being substituted exactly? Cryptography Research Inc's work on this topic is legendary: https:// www.rambus.com/wp-content/uploads/2015/08/Intel_TRNG_Report_20120312.pdf and similarly https://eprint.iacr.org/2014/504 is an interesting read. Remember that as a _user_ or as a _developer_ the hardware RNG does not tell you the algorithm, it tells you some random bits and perhaps provides you with some interfaces to reseed. Also, you can demonstrate this at home with your own Dual_EC_DRBG parameters, the default parameters are just what NIST standardized and then withdrew while meanwhile Bouncy Castle still (!) ships them. If that RNG rather than being backed by hardware is actually Dual_EC_DRBG and ML-KEM reads from that directly, hashing `m` stops recovery with ML-KEM. Should every Java user of ML-KEM be vulnerable if they accidentally use one of the DRBGs shipped by Bouncy Castle? It is possible to find consumers of that interface and to request that they change things. Users will rarely if every do this, of course. The entire system will not be made safer from _all leaks_ because there are many leaks but an active oracle available in a dozen protocols _will_ be closed. If that RNG is purely in software and does not impact all of the system, then hashing `m` again stops ML-KEM from being a relevant oracle. > > 2. Against such an adversary, it is unlikely pre-hashing would > yield a secure system. In particular, no proponent of pre-hashing > has expressed comfort using a cryptography stack with ML_KEM (with > pre- hashing) + DUAL_EC_DRBG (or, even more strongly, using > DUAL_EC_DRBG for their system random). > It would make the system secure against hidden structure unless you have an attack against `H(m)` that allows you to carry out the regular hidden structure recovery against `m` alone. I asked if you had such an attack but you did not provide one or conceed that you do not have such an attack. Would you provide an attack on a cryptographic hash where you can recover Dual_EC_DRBG state? > Unless I am fundamentally mistaken on one the above two points, I > cannot see how pre-hashing confers any security benefit. Any is an easy bar to clear. It is on the floor. I have provided evidence that meets that bar several times. The NIST FIPS 203 standard does not actually clearly convey this nuance. Here is a matrix that reflects what implementers need to know for just one DRBG: ==================== dual_ec_drbg demo kem-stack stack: Dual_EC TRNG -> AES CTR_DRBG -> ML-KEM coins m (ML-KEM-768) params: Q = e*P; d = e^-1 mod n; d*Q==P : yes label : custom Q 076bdb7c0a105b8d TRNG : Dual_EC(serial || counter) serial f71410ea4795bf8e ctr 1 config: all raw L1 TRNG raw block B -> trapdoor d RECOVERED L2 CTR_DRBG table AES key; cache-2005 RECOVERED L3 ML-KEM raw coins m; m-oracle on ct RECOVERED -> generator + all future m/keys RECOVERED config: --hash-trng L1 TRNG H(B) off orbit; trapdoor void PROTECTED L2 CTR_DRBG table AES key; cache-2005 RECOVERED L3 ML-KEM raw coins m; m-oracle on ct RECOVERED -> generator state PROTECTED config: --hash-mlkem L1 TRNG raw block B -> trapdoor d RECOVERED L2 CTR_DRBG table AES key; cache-2005 RECOVERED L3 ML-KEM coins m = H(rng); m-oracle void PROTECTED -> generator state PROTECTED config: protected L1 TRNG H(B) off orbit; trapdoor void PROTECTED L2 CTR_DRBG const-time AES; no cache leak PROTECTED L3 ML-KEM coins m = H(rng); m-oracle void PROTECTED -> safe at every layer PROTECTED ==================== Those are simulations where Dual_EC_DRBG is the system TRNG and then a CTR_DRBG is fed "entropy" from it with and without hashing. Note that hashing stops the state recovery attack against the Dual_EC_DRBG system RNG from succeeding. I simulated a super simple TRNG, a counter and a device specific serial number, where the counter updates on each read, and then it is fed into Dual_EC_DRBG. The output looks uniformly random and only the trapdoor/secretkey(s) holder is able to mount a recovery attack (until quantum computers enter the picture). The attack does not change if the device also includes a TRNG or a static seed that is hashed forward. Random number generation is tricky but not as tricky as inspecting your actual device. > Against an adversary capable of mounting an attack where it has a > claimed benefit, the system is insecure anyway. Yes, like using CTR_DRBG in some cases, right? Here's another case: ==================== dual_ec_drbg demo drbg-chain params Q = e*P e = SHA256(label) mod n d = e^-1 mod n d*Q==P : yes label : custom Q 36df4b7bde0c1d3e TRNG : Dual_EC(serial || counter) serial 8d6df47757b73371 ctr 1 seed : B (raw) generate s1 -> B : 78e9985860094cfe55a0216eb620ccefbd24e775cfbd44d1c625cf8683c8065c CTR_DRBG <- B (raw) (SP 800-90A AES-128; Key||V) Key : 200b64969a777c9f63df3c3912c789b5 V : beac3dbbaf0be743350d0d3ff27af824 O1 : d6f14d3d727b2a4aa9ebbd0cb43fd081 recover 1 CTR_DRBG state [cache-timing attack, 2005] Key 16/16 : yes V (decrypt O1) : yes predict O2 : yes -> CTR_DRBG broken 2 seed material [invert instantiate: (Key||V) XOR C] matches fed-in : yes raw block x(s*Q) : yes 3 system TRNG [trapdoor d] d*R = s*P -> s2 : yes predict next B : yes -> system TRNG + all reseeds broken verdict : RECOVERED CTR_DRBG state + Dual_EC generator ==================== And again with the hash before the CTR_DRBG: ==================== dual_ec_drbg demo drbg-chain --hash params Q = e*P e = SHA256(label) mod n d = e^-1 mod n d*Q==P : yes label : custom Q 1f72001d65102942 TRNG : Dual_EC(serial || counter) serial c6aa1a123575d806 ctr 1 seed : SHA-256(B) generate s1 -> B : 88906f7d515b2a91b3fc727d104ba21d0fdcaba43df19795a2d766f48f74e994 CTR_DRBG <- SHA-256(B) (SP 800-90A AES-128; Key||V) Key : 015f8b95b4f9fa18d4febb71c0208d01 V : d23b76f7a439e9a1d0d2c7f9539c2c89 O1 : ed4070a096fb4e6f36b3966c1bc71dd8 recover 1 CTR_DRBG state [cache-timing attack, 2005] Key 16/16 : yes V (decrypt O1) : yes predict O2 : yes -> CTR_DRBG broken 2 seed material [invert instantiate: (Key||V) XOR C] matches fed-in : yes raw block x(s*Q) : no [= SHA-256(B)] 3 system TRNG [trapdoor d] SHA-256(B) off Dual_EC orbit -> no point : blocked predict next B : no -> system TRNG + all reseeds PROTECTED verdict : PROTECTED system TRNG (CTR_DRBG state broken this epoch) ==================== What is especially surprising about CTR_DRBG when seeded by a hardware random number generator backed by a sabotaged device with hidden structure like Dual_EC_DRBG is that both are known to have kinds of these problems for over _twenty years_. Combining the two together does not magically cancel out the resulting set of problems. We MUST systematically eliminate each class of attacks, and sometimes we need to do this more than once at different levels when we cannot define _one_ system. This is reasonable defense in depth in practice and it reflects that deployments are not a monolith. It also reflects the 2019/2020 blackswans result which showed a OpenSSL FIPS-certified module shipped table based AES in a way that was practically exploitable. > I would personally call this “security theater”. Even if it had no > overhead, I would argue against its inclusion in any scheme. It is > better to accurately describe the security properties of some scheme > rather than pretend it is strong in a setting where it would be > weak. You did not acknowledge that defense in depth is a term defined by NIST, nor did you acknowledge that NIST's change is not in accordance with that term. Hashing provides _a benefit_ and the benefit depends on where the hashing is located. Hashing _destroys the hidden structure_ required for mounting a recovery attack. > > Unless either one of the above two points is wrong, I will stop > engaging in this discussion. Shall we continue here or in another thread or in another working group? Alternatively, I kindly request that you also accept 1) that NIST removing the hash was unjustified, 2) that their acknowledgement that it weakened the system to do so is not wrong, and that 3) hashing "only" protects the KEM. If the bar you set really is "any" then, well, it is not hard to step over the bar that is on the floor. Meeting the goal of `any` has been demonstrated. > We’ve already seen one positive contributor to the WG say this > discussion has pushed them to withdraw from the WG. It is sad that Nadim left but I respect his choice. I am sorry that my emails had that impact on him, and I apologize to him; I did not realize that he was so deeply troubled by my emails. Hopefully he will return but if not, I do not think his summary of my emails is fair. Nonetheless, I acknowledge and appoligize to him that the impact of reading them was negative. That sucks, I am saddened and surprised. I had hoped the proof authors would include this class of issues in their proof(s). It would allow us to prove more and to increase our confidence. I think the symbolic proofs are very helpful and good; I respect Nadim's and Usama's hard work. > I do not want to be “half” of the discussion that pushes others in > this same direction. I understand and agree when it does not conflict with our various obligations to the larger picture. In any case, I want to say that unlike tables in AES which no one should use, we can probably table at least part of this discussion because of the recent chair announcement. Kind regards and with respect, Jacob Appelbaum P.S. I understand that you do not have interest in furthering the proof discussion or in engaging in discussions with the authors of the 2022 paper off-list. I respect that decision, so I will not email you off- list about this issue. Feel free to contact me if you want to open the discussion again. This email would have been shorter but well, I did not have more time. Thank you for your time and consideration. > > Cordially, > > Mark > >> On Jul 18, 2026, at 3:29 PM, Jacob Appelbaum >> <[email protected]> wrote: >> >> Hi Mark, >> >> On 7/18/26 19:46, [email protected] wrote: >>> Hi Jacob, I see you have had enough free time to write several >>> long messages. >> >> My time is not my own but it is certainly no one else's >> either. ;-) >> >> Yes, the email I have drafted to you in reply has taken me much >> longer than others. My delay is not a sign of disrespect and is >> quite the opposite. I will set that draft aside and respond here. >> It would have been shorter with more of a delay, so I trust you >> will address my points systematically or take it off-list with me. >> >>> Do you have enough time to write a short one? In particular, I >>> asked you a few days ago what I believe to be a question of >>> vital importance. Does pre-hashing m do anything? In >>> particular, if any RFC that leverages a ML-KEM variant included >>> pre-hashing, would you be comfortable setting your system random >>> to DUAL_EC_DRBG? Or even the RNG used in solely your TLS stack. >> >> No. I would not knowingly use Dual_EC_DRBG as either the system >> RNG or the TLS RNG, with or without pre-hashing. I would replace >> it immediately if discovered. >> >> That is not, however, the security claim being made or the >> concern raised. >> >>> I would not be comfortable with this. I doubt many on this >>> mailing list would think this is a sensible idea. I imagine >>> since you are devoting so much time to the subject of pre- >>> hashing, you think that it will give a concrete benefit. In >>> particular, in the setting you have been highlighting as the >>> relevant attack vector (a backdoored RNG, a la DUAL_EC_DRBG), I >>> would *hope* you think that pre-hashing ML-KEM would >>> meaningfully prevent an attack on TLS. >> >> It provides a concrete but limited benefit. >> >> With m = x, a peer controlling the decapsulation key can recover >> the raw structured RBG output used by the known Dual_EC_DRBG >> state- recovery procedure. With m = H(x), the peer receives H(x), >> so that procedure first requires recovering a suitable preimage. >> >> This separates four questions: >> >> 1. Must a local defense make the entire compromised system safe? >> >> No. Hashing does not repair the RNG or protect every consumer. It >> closes this ML-KEM-specific raw-output oracle. >> >> 2. Does hashing change the adversary's advantage? >> >> Yes. It changes the peer's input from the exploitable structured >> value x to its hash image H(x). >> >> 3. Is knowingly selecting Dual_EC_DRBG the realistic threat model? >> >> No. That assumes notice, detection, and meaningful choice. A >> successful hidden compromise is designed to deny all three. >> >> 4. What does the usual KEM security model cover? >> >> It may correctly analyze lattice security while omitting shared >> RBG state, peer-recoverable randomness, and later values >> generated from the same state lineage. >> >>> If you would not be comfortable with this, I can’t see the >>> point of debating pre-hashing. It would be (in my eyes) a >>> “defense in depth” countermeasure that does not defend against >>> the attack scenario that justifies it. This sounds useless to >>> me personally, and is precisely what I mean when I said that >>> “defense in depth” appears to be consistent with the definition >>> of “arbitrary protocol modifications of questionable >>> cryptographic value”. >> >> We are not really debating in any meaningful sense but I take the >> hint about your perspective. I was seeking to understand it from >> your perspective, and I had hoped that you were seeking to >> understand my perspective as well. >> >> A structured analysis of the evidence would probably immediately >> help one to realize that we do not get to choose which >> cryptography will be sabotaged. >> >> We are discussing adversaries with hundreds of millions of >> dollars in budgets allocated for this kind of activity. The >> agencies represented in various investigations showing their >> sabotage operations are also represented directly on this list. We >> see what those agencies want, and we see that some people are >> happy to grant it for a variety of reasons. It could be perfectly >> fine, but it may not be. Finding a problem that directly relates >> to a scenario where a known adversary strategy becomes exploitable >> is alarming, especially when we cannot test our machines and then >> decide to not trust our machines for that exact class of attacks. >> Practically, we are only able to choose to trust or in effect, to >> not compute. >> >> More than ten years ago, the number of people cleared to know >> about BULLRUN and related programs was hundreds to thousands of >> people, over eight hundred in the GCHQ's orbit alone. That does >> not capture the full workforce, so many in these agencies do not >> know about the full picture except perhaps through reporting. >> >> Was all of that captured in our game based proofs? No, it was not. >> >> Like other claims of provable security, a proof that does not >> capture an Adversary's advantage is well, perhaps proven, if >> verification of the proof works out as advertised. But is it >> relevant? >> >> Your test asks whether one layer makes a knowingly compromised >> machine wholly trustworthy. That would define defense in depth >> out of existence. >> >> The more practical test is whether the layer removes a concrete >> attack path when an upstream assumption fails. Here it does: ML- >> KEM no longer hands the peer the raw structured sample. >> >>> Is this the case? As others have expressed, it would be nice if >>> you could keep any reply short, as this is a very simple >>> question, so hopefully it has a simple answer. >> >> So the simple answer is: >> >> No, pre-hashing would not make me _trust_ Dual_EC_DRBG. Yes, it >> removes the ML-KEM-specific state-recovery oracle. Those >> statements are fully consistent. >> >> This thing that you call "pre-hashing" would increase my >> confidence in both the FIPS-certified and the non FIPS-certified >> setting. My original objection to NIST over three years stands: >> NIST did not make a security motivation for removing it, they >> freely accept that they weakened it in in the non FIPS-certified >> setting. That setting is the primary setting for most >> implementations of IETF protocols and it will likely impact the >> largest number users. >> >> I have implemented the attacks with TLS (1.1, 1.2, and 1.3) and I >> systematically addressed various related issues in tlslite-ng >> while doing so. Remarkably there exist situations where this is >> the only issue, or where one primitive _may_ weaken another >> including in the hybrid setting. >> >> This is concerning when we have seen (symbolic) proofs that did >> not capture this (uninteresting to some) nuance. We should expect >> that from a symbolic proof that does not model this exact >> situation and that was part of my point about the proofs offered. >> None of the previous analysis presented captured this issue as >> far as I have seen. It is simply uninteresting. A good Adversary >> does not care what interests us, they only care about winning. A >> great Adversary does care about what interests us, and that is >> part of why they have been decrypting TLS successfully. >> >> Hashing `m` stops the recovery of Dual_EC_DRBG. Leaving it >> unhashed allows an active adversary, after every other leak is >> plugged, to decrypt TLS. It also allows for cross session passive >> decryption after that point. That all the other leaks present a >> similar problem is not a reason to add another one. If it would >> help, I could also show you a demo. >> >> While I have asked other questions, I will pose a simple question >> to you in return. >> >> Let us assume that you control the trapdoor/secret. Absent side >> discussions about other leaks or a lack of entropy, do you have an >> efficient method to recover the Dual_EC_DRBG state from m1 (e.g., >> `m1 = x`) and m2 (e.g., `m2 = H(x)`) or is there a difference in >> your practical ability to recover the state from either m1 or m2? >> >> In the larger picture for TLS being prudent here seems wise, but >> in the end, no one will be responsible for this kind of attack >> strategy succeeding except the people carrying it out. >> >> I would be glad to continue the game-based proof with you off- >> list and bring a concise formulation back to the working group. I >> would also welcome a joint exchange with the authors of the 2022 >> paper that I cited earlier. Using ML-KEM's `m`-oracle works in >> other IETF protocols as well. I am happy also to discuss those >> issues with you as well but that is best not done on the tls >> working group list. >> >> Kind regards, Jacob Appelbaum >> >> P.S. >> >> I appologize again for the delay, I had hoped to show you a much >> more complete proof. >> >>> Best, Mark >>>> On Jul 18, 2026, at 9:48 AM, Jacob Appelbaum >>>> <[email protected]> wrote: Hi Nico, On 7/17/26 07:35, Nico >>>> Williams wrote: >>>>> On Fri, Jul 17, 2026 at 12:52:05AM +0200, Jacob Appelbaum >>>>> wrote: >>>>>> On 7/16/26 21:57, Nico Williams wrote: >>>>>>> The objective answer is that the horse left the barn >>>>>>> two decades ago when the IETF decided to get out of >>>>>>> fighting about national cryptographic standards, >>>>>>> therefore Deb's 37 years at the NSA are irrelevant in >>>>>>> this case, and you're fighting the wrong battle if you >>>>>>> want to change that two- decade-old decision. >>>>>> That is not correct and the ISE could easily publish the >>>>>> drafts under discussion without consensus as Rob >>>>>> suggested more than a week ago. >>>>> Has that not been opposed too? / The relevant decision- >>>>> makers would be the authors and the Independent Submission >>>>> Editor. I have not seen a definitive objection from either, >>>>> and I understood Eliot to be open to considering the idea. >>>>> Would that not be opposed too? It could certainly be >>>>> opposed. What kind of opposition do you mean? >>>> Rob's (it was Rob, right?) suggestion appears to be a viable >>>> fallback. The Independent Stream does not require IETF rough >>>> consensus, although it is not an automatic bypass: the >>>> authors and ISE would have to pursue it, and the IESG would >>>> still conduct the RFC 5742 conflict review [0][1]. I note that >>>> the authors have largely not engaged in discussion. >>>>> I swear I've seen arguments that users of RFCs don't really >>>>> understand these subtle differences in track and editor >>>>> queues, that they take any RFC as a 'standard'. >>>> Yes. Many readers treat any RFC number as a standard despite >>>> the stream boilerplate. That is a real drawback, but it is >>>> also why the distinction matters for _us_: Independent Stream >>>> publication would not assert IETF consensus. In practice, I >>>> suspect very few outside of the IETF would care about the >>>> distinction. It would allow us to provide clarity when the >>>> matter is raised. I still prefer resolving the issues in the >>>> working group. I am not opposed to publication; I am trying >>>> to identify text that makes publication responsible. >>>>>>> What you're really litigating is a social death penalty >>>>>>> for the NSA -- something we *could* do, but shouldn't. >>>>>>> We really, really shouldn't do that for at least >>>>>>> several reasons, such as: >>>>>> You may be surprised but I very strongly agree with you. >>>>>> We should not litigate a social death penalty. I do not >>>>>> advocate for removing Deb from the IETF. No one should be >>>>>> harassing her. No one should be making threats. No one >>>>>> should be giving her a hard time. No one should be >>>>>> mocking her on social media. No one should be sending >>>>>> threatening or slanderous or libelous emails. >>>>> It's not just the invectives against Deb. It's also the >>>>> invectives against the I-D authors and those who have >>>>> voiced support for the I- D. >>>> I extend that to everyone: Deb, the authors, supporters, >>>> opponents, and other participants. We need more technical >>>> communication, not threats, harassment, ostracism, or >>>> censorship. I have received several reports of troubling off- >>>> list conduct. That should be handled through the appropriate >>>> conduct process rather than mixed into the technical >>>> disposition of the drafts. It is unclear to me if those >>>> reports will by sent by those persons to the IETF out of >>>> (expressed to me) fear of retaliation. >>>>> The incessant urging to not publish anything that might be >>>>> tainted by the NSA *is* very much akin to a social death >>>>> penalty for the NSA. >>>> I do not oppose publication because NSA personnel were >>>> involved. The immediate concern is a documented NIST design >>>> decision: FIPS 203 removed Kyber's `m <- H(m)` step, whose >>>> stated purpose was protection against flawed randomness, >>>> because FIPS 203 requires approved randomness generation [2] >>>> [3]. The question is whether IETF documents should repeat >>>> that assumption silently or not, describe and explain the >>>> peer- recoverable value, and preserve a cheap local safeguard >>>> for deployments that do not satisfy the full FIPS model. It >>>> is indisputable that NIST removed the hash over `m`, ignored >>>> all pushback, ignored official comments on the matter, and >>>> unrelated to much of the discussion they then also declared >>>> that non FIPS-certified settings are expected to simply fail >>>> catastrophically if the RNG has an issue. So you see, >>>> removing the hash and qualatatively weakening the design of >>>> Kyber, they assert is fine. That they accept this outcome and >>>> state that they are correct was explictly stated by NIST on >>>> this very list. They additionally also push this without a >>>> hybrid construction, also over the express concerns of the >>>> authors of Kyber. Those two things together and my ability to >>>> exploit ML- KEM in the Dual_EC_DRBG setting correctly raise >>>> eyebrows. NSA involvement is relevant historical context, but >>>> it is not a social veto. NIST is not the final technical >>>> authority for the IETF, any more than BSI, CSE, ETSI, ISO, >>>> IEEE, or a corporation would be. Former NIST people dropping >>>> by to argue that the world should adopt their public security >>>> posture is unreasonable. They have a traditionally had the >>>> Suite A and Suite B security postures and we're being offered >>>> the B option by another name, again. The IETF should have a >>>> stronger security posture and wihtout being in a FIPS- >>>> certified setting. The same scrutiny should apply to every >>>> source: examine the design, assumptions, evidence, and >>>> consequences for the end user. The still-incomplete public >>>> record concerning NIST/NSA coordination and the answers given >>>> in this discussion make careful review more, not less, >>>> appropriate. I would also welcome explicit clarification of >>>> the IPR position, although the current drafts do not resolve >>>> it. Comments that are not made by NIST have not brought >>>> clarity because any such analysis carries no weight about >>>> NIST's actual position. If NIST makes clear that we are free >>>> to hash `m` and retain the IPR waiver, we would be able to >>>> resolve the issue of excess authority preventing a stronger >>>> security posture, if it is desired. Do you see that they are >>>> unwilling to bring this clarity? If they were gagged as John >>>> Kelsey was, I would expect that bringing this clarity would be >>>> out of bounds. NIST is free to say otherwise and what they did >>>> say on the matter is contridicted by the public record. It >>>> could be credibly explained but NIST did not deem it worthy of >>>> their time. The American cliché "good enough for government" >>>> is the phrase that comes to mind here. Is that good enough for >>>> the IETF? No, it is not. >>>>>> People should *especially* not be punished for the worst >>>>>> thing they are suspected of doing, and especially if they >>>>>> did not do it. Even if they are guilty, they deserve a >>>>>> chance at redemption. Everyone deserves a fair shot at >>>>>> re- integration. >>>>> For those who say TL;DR, the summary is that: IMO the ML- >>>>> KEM I- D - and all I-Ds specifying KEMs- should normatively >>>>> state which DRBGs are acceptable, and they should include >>>>> informative text about the unfortunate risk of RNG-based >>>>> kleptography when using KEMs outside DH hybrids. >>>> I broadly agree, with the qualification if 'acceptable' is >>>> stated as a 'MUST' or a 'requirement imposed by NIST to >>>> achieve security' and that a hybrid does not help if both >>>> components depend on the same recovered RBG lineage. >>>>> Ok then, here's my take: * Ideally we should have a >>>>> practical, strong PQ Diffie-Hellman. We do not. I agree in >>>>> the strongest terms. Practical post-quantum constructions >>>>> with genuine Diffie- Hellman-like contributory behavior >>>>> remain an important research goal. >>>> MIKE seems interesting but I have not analyzed it, evaluated >>>> it, used an implementation in a deployment. CTIDH is somewhat >>>> more familar to me and while there is literature that is >>>> relevant for the security in the quantum setting, I find it >>>> to be extremely promising. CTIDH and related commutative >>>> group- action work are interesting in that respect. I help >>>> maintain an implementation released by an academic group, but >>>> I did not design CTIDH and make no claim that it is ready to >>>> replace standardized KEMs. In my own experimental use I >>>> combine it with X25519. More generally, I would not deploy a >>>> comparatively young post- quantum construction without an >>>> independently generated classical component today. On balance >>>> I have decided that in at least two protocol withs no other >>>> PQC option available, a hybrid X25519 and CTIDH-512 or >>>> CTIDH-1024 were better than X25519 alone. This protects >>>> against CTIDH failures today, and hedges against a future >>>> with quantum computers. >>>>> * All KEMs are going to have this `m` problem in some >>>>> fashion. Is that a correct statement? That makes all of >>>>> them suitable for RNG- based kleptography. I do not think >>>>> that all KEMs necessarily have the same problem. We need a >>>>> precise property: can an adversarial recipient recover an >>>>> unchanged, sufficiently large, ordered sample of the >>>>> sender's RBG output? >>>> ML-KEM clearly exposes that shape in the most risky way >>>> possible and it is unnecessary risk. To recap before we en- >>>> and- de-cap: `ML- KEM.Encaps` samples a 32-byte `m`, and a >>>> decapsulating peer that controls its implementation can >>>> retain the reconstructed `m'`. Third-round Kyber instead >>>> hashed `m` before using it [2][3]. Other KEMs and their uses >>>> have to be analyzed construction by construction; a ciphertext >>>> carrying a recoverable secret is not necessarily carrying raw >>>> generator bytes. In addition to Kyber where everything is >>>> essentially equal except the hash in our discussion, sntrup761 >>>> is a useful contrast. It uses a structured fixed-weight >>>> ternary polynomial `r`, not a raw 32-byte `m`. In the >>>> reference sampler, many 32- bit random words are masked, >>>> sorted, and mapped into the ternary polynomial before `r` is >>>> used, and the shared key is derived by hashing its encoding >>>> [4]. The recipient can recover `r`, but `r` is not an >>>> unchanged contiguous generator block. The difference is >>>> extremely stark. That does not prove immunity to every >>>> malicious or specially shaped RBG. It means only that the >>>> direct ML-KEM argument does not transfer unchanged. I made a >>>> preliminary attempt to recover a Dual_EC_DRBG block through >>>> this sampler and did not succeed. I would welcome a better >>>> analysis, especially from the sntrup761 authors: do you see a >>>> practical method for reconstructing a full Dual_EC output >>>> block from the existing fixed-weight sampler? The sntrup761 >>>> authors and implementations could also hash the RNG as Kyber >>>> did to make the comparison even easier. Regardless, NIST and a >>>> couple of other people may discuss the construction of `m` and >>>> KEMs in a way that would lead a reasonable person to believe a >>>> KEM always has this issue. However, it is simply not true. A >>>> KEM does not imply an `m` must be composed of contiguous >>>> sample of the system RNG without transformation, otherwise. It >>>> is misleading and it is dangerous as I have shown with >>>> Dual_EC_DRBG as an example. In TLS this can lead to decryption >>>> of the connection, and future sessions. This is acceptable to >>>> NIST, and it should not be to the IETF. This difference is one >>>> reason I remain comfortable with sntrup761x25519 as a >>>> conservative OpenSSH option. The ML- KEM SSH exchange, like >>>> TLS, gives an unauthenticated client an opportunity to supply >>>> the encapsulation key and recover the server- generated `m` >>>> pre-auth; the actual risk still depends on the >>>> implementation's RBG, state separation, and generation order. >>>> This is a kind of landmine where it increases analysis work >>>> and where implementations may get it wrong. It is not the >>>> conservative choice that I would expect from the >>>> professionally prudent securtiy minds that brought us OpenBSD >>>> and OpenSSH. It however entirely makes sense if OpenSSH needs >>>> to provide ML- KEM. I hope that they will ensure that `m` is >>>> hashed in practice but if not, it only further underscores >>>> why the NIST's decision process and their conclusion is >>>> unreasonable. OpenSSH is not only used in a FIPS-certified >>>> setting, and I highly doubt that NIST will promote the >>>> various DRBGs used by GNU/Linux, FreeBSD, NetBSD, and OpenBSD >>>> as qualified designs. I would welcome it as long as they did >>>> not impose unreasonable changes as they did with Kyber for >>>> `m` since those designs are what the world uses. >>>>> For this reason I think we should have no RECOMMENDED=Y >>>>> non- hybrid KEMs. But I don't see why not have >>>>> RECOMMENDED=N KEMs. Interesting. I support hybrids as the >>>>> conservative default, but the hybrid label alone is not >>>>> sufficient for this issue. >>>> If the ML-KEM interaction permits recovery of an RBG state >>>> before the same state lineage generates the X25519 scalar, >>>> both components may be predictable. If the X25519 scalar was >>>> generated first and the RBG resists backtracking, that >>>> component may remain independent. Reseeding, per-connection >>>> state, buffering, and call order all matter. A compact >>>> version of my current classification is therefore: scheme >>>> recoverable value raw RBG block? ML- KEM 32- >>>> byte `m` yes Kyber r3 >>>> `H(m)` no sntrup761 fixed-weight >>>> ternary `r` no That table is deliberately narrow. I >>>> would not label every randomized signature, OAEP seed, DH >>>> exponent, or structured KEM secret as a "raw leak" merely >>>> because it depends on randomness; the transformation and >>>> recoverability must be analyzed. I have done most of that >>>> analysis on other IETF primitives but that is for a different >>>> email. >>>>> * TLS 1.3 has insanely large nonces ('random'), and that's >>>>> enough for RNG-based kleptography. >>>> Agreed. TLS `Random` fields already create a broader public- >>>> output problem, and I regret not addressing it while TLS 1.3 >>>> was being written. I am preparing separate work on public and >>>> peer- recoverable RBG outputs across TLS, QUIC, MLS, SSH, >>>> IKE, and other protocols. That broader work should not >>>> prevent fixing an additional clean oracle now. >>>>> therefore ML-KEM adds nothing much new *except* that when >>>>> using a FIPS-140-3 validated module then ML-KEM can sneak a >>>>> Dual_EC- style DRBG in through the back door even when the >>>>> TLS 1.3 implementation would not otherwise use such a DRBG. >>>> The word "except" is doing substantial work in your sentence. >>>> ML- KEM can expose an additional sample of the randomness >>>> used for secret generation even when an implementation >>>> separates or conditions other TLS-visible fields. A successful >>>> sabotage mechanism should be reliable, economical, and >>>> plausibly deniable. The protocol should not make that job >>>> easier when a wire-compatible hash removes the direct >>>> structured sample. >>>>> * We can insist that the choice of DRBG to use MUST be one >>>>> of a set we approve of, and, impliedly, none of the ones we >>>>> don't approve of. Agreed in principle. We should state the >>>>> actual requirement rather than invent combined algorithm >>>>> names. FIPS 203 requires fresh randomness from an approved >>>>> RBG, with the required security strength, under the SP >>>>> 800-90 framework [2]. Hash_DRBG, HMAC_DRBG, and CTR_DRBG >>>>> are the SP 800-90A mechanisms, but the requirement also >>>>> includes the entropy source and construction requirements in >>>>> SP 800-90B and SP 800-90C. >>>> I would then state the separate `m` issue. The approved-RBG >>>> requirement is the primary layer; hashing `m` is a local >>>> layer that prevents this consumer from returning >>>> algebraically structured output to a peer when the primary >>>> assumption fails. NIST and some of the IETF, such as myself, >>>> appear to have different risk tolerances on that point. NIST >>>> has publicly acknowledged the limited claim: hashing protected >>>> the KEM, while a broken RBG could still compromise the wider >>>> system. That is not an argument that the KEM-level protection >>>> has zero value but NIST agreeing that it has value, and that >>>> it is not valuable to _them_. Okay! I am glad that they did >>>> not present an attack as their original motivation to remove >>>> the hash. It is not a security issue to have the hash. It is >>>> good that we do not disagree on that point. The performance >>>> was also not a relevant concern. Their expressed concern is >>>> how they logically separate things in a FIPS- certified >>>> setting, and outside of that setting, they qualatiatively >>>> weakened the design and accept the consequences. This tells us >>>> their security posture, and it is less than the IETF should >>>> accept. These kinds of "logical" separations are how we had >>>> IPsec failures with Dual_EC_DRBG on the internet that allowed >>>> for full passive decryption through nonce leakage. This was >>>> reportedly exploited by the NSA and it is not in dispute. >>>> Juniper engineers probably deeply regret being tricked by >>>> that kind of mistaken protocol and implementation design. The >>>> public record concerning NIST/NSA coordination is, and >>>> remains, incomplete. Materials produced through litigation >>>> appear relevant to statements made during this discussion. My >>>> understanding is that the litagion is ongoing and that >>>> production of documented related to NIST/ NSA collaboration >>>> remains unfinished. I do not need to resolve that >>>> institutional history in this email. I do think NIST should >>>> answer concrete questions and publish enough of the record >>>> for independent evaluation. We could also wait for the lawsuit >>>> to finish but that is likely to take a long time, so NIST >>>> could really help speed things up by either stating their >>>> intention to 1) immediately and proactively produce the >>>> documents in question and/or 2) directly engage here with the >>>> understanding that if the documents later contridict them, >>>> they will be on the hook. Both of those seem incredibly >>>> unlikely and that is why an independent court has been >>>> involved to _force_ NIST to produce the facts. Does it not >>>> concern you that the facts _already_ produced in that lawsuit >>>> do not match the claims made by NIST on this very list? If >>>> not, what would be the line for you? I ask so that when the >>>> lawsuit is finished, we may do a proper retrospective >>>> analysis. >>>>> The AES counter DRBG is plenty good enough. Which >>>>> implementation? >>>> CTR_DRBG can be a sound construction, but naming it does not >>>> guarantee a side-channel-resistant implementation. Cohney et >>>> al. demonstrated cache- based recovery against vulnerable >>>> table-based AES CTR_DRBG code in SGX, including state >>>> recovery, loss of forward security, and an end-to-end TLS >>>> compromise [5]. This was an implementation attack, not a >>>> universal break of CTR_DRBG. These kinds of failures are >>>> possible because NIST's standards are below the security and >>>> the quality of the IETF's standards. There are examples worth >>>> considering such as the constraints described in NIST SP >>>> 800-90a. The distinction matters. FIPS 197 specifies AES, but >>>> does not by itself require a constant-time implementation or >>>> test for secret- indexed table lookups. SP 800-90A specifies >>>> the DRBG construction, but cannot make a leaky AES >>>> implementation safe. Hardware instructions can reduce this >>>> particular risk, while introducing their own hardware and >>>> microcode assumptions. Would you believe that one of the >>>> findings in [5] as presented in 2020 ( https:// >>>> rwc.iacr.org/2020/slides/Cohney.pdf ) included an OpenSSL FIPS >>>> module, the NetBSD kernel systemwide PRG (!), mbedTLS _inside_ >>>> SGX, and also the nist_rng library. That includes a FIPS- >>>> certified setting. Perhaps the FIPS-certified setting is not >>>> as strong as the NIST advertising would have us believe? NIST >>>> has not updated the corresponding standards in response to the >>>> publication [5] as far as I am aware. I am happy to be >>>> corrected on this point but if even NIST is able to get it >>>> right, maybe we should consider this as a factor in their >>>> security posture? I want to note as a matter of honesty that >>>> here, hashing `m` does not save a system after the attacker >>>> has extracted the CTR_DRBG key; the attacker can reproduce >>>> the hash. It does, however, address a different failure >>>> class: algebraic structure in output that is otherwise handed >>>> directly to the peer. Therefore the correct guidance is not >>>> "CTR_DRBG is broken" or "the hash fixes everything." It is: * >>>> exclude Dual_EC_DRBG and analogous structured generators; * >>>> require a securely implemented, prediction-resistant RBG; * >>>> require side-channel-resistant primitives and sound >>>> reseeding/ state management; * retain the local hash to avoid >>>> exporting raw structure; * even NIST's standards and certified >>>> FIPS modules get this wrong; * NIST updated their threat model >>>> in 2019; * NIST did not update the actual standards to >>>> require safe defaults! The longer document should review >>>> Hash_DRBG, HMAC_DRBG, and CTR_DRBG, including side channels, >>>> fault attacks, entropy failure, reseeding, and state >>>> compromise, rather than treating an approved algorithm name as >>>> an implementation proof. The authors of [5] note that CTR_DRBG >>>> is not provably secure, they note that Woodage and Shumow >>>> found problems with HMAC_DRBG, and they encourage the use of >>>> Hash_DRBG. Note that the authors in addition to the "Dual_EC >>>> Backdoor" they raise the "Juniper Dual_EC Incident" they also >>>> raise the DUHK Attack on ANSI X9.31. So - lets recap that >>>> into some conclusions: - No: Dual_EC_DRBG (withdrawn (!)) - >>>> No: CTR_DRBG (FIPS certifiable (!!) does not mean not >>>> exploitable) - No: HMAC_DRBG (see Woodage and Shumow's related >>>> work, and others) Meanwhile, NIST says they are working on an >>>> updated SP 800-90A where they announced a comment period >>>> ( https:// csrc.nist.gov/ pubs/ sp/800/90/a/r2/iprd ) which >>>> closed in late 2025: Date Published: September 4, 2025 >>>> Comments Due: November 4, 2025 (public comment period is >>>> CLOSED) Aside from the absurdly short comment period, NIST >>>> says that public comments will be posted after the closing >>>> date. Nearly a year later, that statement remains true as >>>> someday they may be posted. As of today, the public comments >>>> have not been posted as far as I am aware. Do you want to make >>>> a prediction about Hash_DRBG? >>>>> This, however, may run into a problem where FIPS-140-3 >>>>> validated cryptographic modules might not be configurable >>>>> as to DRBG choice. However, it is enough to state this >>>>> requirement. We do not have a Protocol Police function. >>>> Agreed. Accurately summarizing the NIST requirement and >>>> adding the right cross-references is sufficient for that part >>>> of the issue. >>>>> * As long as there is one acceptable DRBG that can be >>>>> selected, we can state a normative requirement and give >>>>> useful advice regarding the dangers of RNG-based >>>>> kleptography. >>>> Agreed. I would list the approved constructions as examples, >>>> state the required properties, and explain the kleptographic >>>> failure mode. >>>>> * I do suspect that all KEMs enable Dual_EC-style >>>>> kleptography. And yet ML-KEM should be published. Not >>>>> because that's a good thing, but because -once more- the >>>>> horse left the barn when the nonces (`Random`) were made >>>>> more than large enough and when the codepoint registries >>>>> were made Specification Required. I do not think the >>>>> general conclusion about all KEMs follows, but I also do not >>>>> think this is a reason to withhold ML-KEM indefinitely. My >>>>> request concerns an avoidable, wire-compatible footgun and >>>>> accurate Security Considerations, not ML-KEM's lattice >>>>> hardness assumptions. But also I'd have to see how >>>>> recovering *one* `m` value would allow a kleptographer to >>>>> steal *many* other clients' `m` values. >>>> For Dual_EC_DRBG, the result depends on truncation and state >>>> management. With an untruncated 32-byte output, one `m` may >>>> be enough for the trapdoor holder to recover the next state. >>>> With the standardized P-256 truncation, the attacker normally >>>> enumerates the missing bits and uses another output or other >>>> state information to identify the correct candidate [8]. Once >>>> a long- lived shared state is recovered, later outputs may be >>>> predicted until reseeding or separation defeats >>>> synchronization. Or put simply: you draw 32 bytes from the >>>> sabotaged RNG, you transmit it, you then draw 32 more bytes. >>>> An adversary with the Dual_EC_DRBG trapdoor/secretkey(s) that >>>> receives your first 32 bytes is able to predict the 32 bytes >>>> of the second draw, even if you do not send them. Would you >>>> like me to send you an implementation of this where you >>>> control the trapdoor/secretkey(s)? >>>>> * The large size of `Random` is still problematic. >>>> Agreed. I call these public or peer-recoverable wire oracles. >>>> TLS 1.1, 1.2, and 1.3 all expose large `Random` fields, and >>>> other protocols can inherit related risks through TLS or >>>> their own public randomness. My broader survey remains >>>> preliminary because implementation choices, state sharing, >>>> sequencing, and authentication phase change the answer. If >>>> this attack class is deployed, however, the strategic value >>>> for mass collection and real-time decryption could be >>>> substantial. >>>>> [Heavy trimming follows.] >>>> Thank you for tolerating my verbosity. I will try to return >>>> the favor. >>>>>>> * If the NSA wants to get burned again by playing the >>>>>>> Dual_EC game again, let them! >>>>>> This is frankly, reckless. We should not be used >>>>>> unwittingly or be party to such folly. >>>>> My personal advice: sometimes that is the smart play -- if >>>>> you never engage in tactical retreats thus badly losing >>>>> some battles, you'll exhaust yourself and lose the war. >>>> I take the advice. My claim here is bounded: we should learn >>>> from Dual_EC_DRBG and treat it as the canonical public >>>> example of strategic cryptographic sabotage. The tactical >>>> compromise I can support is to publish after adding accurate >>>> RBG requirements and the `m` guidance, while moving the >>>> larger analysis to separate work. I am exhausted, but that is >>>> another reason to turn the dispute into specific text rather >>>> than continue repeating it. >>>>>>> * The NSA is not likely the monolith a social death >>>>>>> penalty for it would have to presume. >>>>>> I do not understand this point but I agree that the NSA >>>>>> is not a monolith. Part of asking the questions that I >>>>>> asked is that there are NSA people I have directly spoken >>>>>> to who answered almost all of those questions without a >>>>>> problem. I am not only talking about whistleblowers but >>>>>> people whose job never involved cryptographic sabotage. >>>>> But you and/or others in these threads are treating all >>>>> involved with NSA in regards to ML-KEM as monolithically >>>>> motivated by the same interest in kleptography. That >>>>> amounts to treating the NSA as a monolith. "It's supported >>>>> by NSA pEoPlE!!" is basically the backup singers' line. >>>> Thank you for clarifying. I do not infer a common motive from >>>> NSA affiliation, nor do I want an institutional blacklist. I >>>> would apply the same skepticism to Edward Snowden, Bill >>>> Binney, Thomas Drake, an NSA engineer, a NIST employee, a >>>> defense contractor, or an independent academic: examine what >>>> they propose, what assumptions they bring, how they answer >>>> questions, and what outcomes their position produces. Most of >>>> all, I would want to examine their security posture. >>>> Institutional background can still be relevant without making >>>> the institution a monolith. People with access to classified >>>> systems may know constraints or attacks that they cannot >>>> describe publicly. That can create blind spots even without >>>> malicious intent. Suite A is the obvious example: public >>>> reviewers cannot reason from secret knowledge they do not >>>> possess, and a person who possesses it may be unable to >>>> explain why or even _that_ a public design is unsafe. >>>> Furthermore, they may feel that even if they _could_ do so, >>>> they do not agree with thwarting large-scale adversaries if >>>> it would thwart their favorite, civil-liberties respecting, >>>> honest, law- abiding, large-scale adversary... who they >>>> consider more as a friend in any case. The solution is not >>>> personal exclusion. It is transparent threat models, conflict >>>> disclosure where applicable, independent review, explicit >>>> assumptions, and technical mitigations that do not depend on >>>> trusting a person's institutional role. It is also important >>>> to look at the results. NIST's modified Kyber grants a >>>> cryptographic oracle in over a dozen protocols where the >>>> protocols are layered. Example: your Signal client uses ML- >>>> KEM in TLS, and again in the Signal e2ee ratchet. Neither are >>>> required to be FIPS-certified, to put it mildly. My own >>>> principle is simple: I will not support cryptographic >>>> sabotage or an accommodation designed to preserve it or that >>>> allows for it as an acceptable consequence of an imposed >>>> change against the express wishes of the cryptographic >>>> primitive's designer(s). I will support technically sound >>>> protections even when they protect people or institutions >>>> hostile to me. RFC 7258 says pervasive monitoring is an >>>> attack; the relevant IETF value is to reduce harm to the end >>>> user [12]. >>>>>>> * There is no technical content regarding ML-KEM to >>>>>>> back this up. >>>>>> I could easily believe that you were aware of these >>>>>> issues before the discussions on this list. Were you? >>>>> Some of them. >>>> Agreed. As exhausting as it has been, the discussion has >>>> produced a clearer technical record and some real convergence. >>>>>> For example, were you aware that you could do this kind >>>>>> of thing, including recovering `m`? >>>>> I believe my earlier response (and the above) should make >>>>> it clear that I am. Above is a fuller treatment of this >>>>> issue. >>>> Yes, now it is clearer. I was asking about before the >>>> discussion because the point is subtle and was absent from >>>> the drafts' Security Considerations and from several early >>>> responses. That suggests a gap in our protocol-analysis >>>> process worth fixing. >>>>>> Do you think that the removal of a hash function to >>>>>> enable it is not "technical content" when that single >>>>>> design choice was made exactly to counter this kind of >>>>>> thing? >>>>> Not sufficient to stop publication. Instead it is >>>>> sufficient to argue that the choice of DRBG must be limited. >>>> Then we agree that it is technical content. I am not asking >>>> for nonpublication as an end in itself. If the DRBG >>>> restriction includes the reason for it, the recoverability of >>>> `m`, and the Appendix C.1 tradeoff, we are close to agreement. >>>>>> Are you really buying the argument from NIST where they >>>>>> made it worse and accept that as a fact, over what, >>>>>> ~300-1500 cycles? >>>>> With a non-kleptographic DRBG it seems fine. >>>> Does that still hold with the cited research showing that the >>>> current (not even including Dual_EC_DRBG!) NIST DRBG have >>>> non- trivial security failures? Does it concern you at all >>>> that a practical full state recovery over the network against >>>> TLS was shown for CTR_DRBG in a FIPS- certified setting and >>>> NIST has so far only updated their _threat model_? If the >>>> authors did not catch that two month call for comments _five >>>> years later_, will NIST even address these issues? Regardless, >>>> as of now, it does not seem fine to me. Updating the threat >>>> model is absolutely hilarious, I am sure that is very >>>> reassuring to impacted parties. >>>>> I agree that the risk of inserting a kleptographic DRBG is >>>>> real, but not publishing is not really a good answer. >>>> We agree that the kleptographic-RBG risk is real, and I agree >>>> that nonpublication is not the only answer. I still would not >>>> call the unhashed design equally safe. It is qualitatively >>>> weaker than the same construction with one additional hash >>>> because it relies entirely on the RBG and its implementation. >>>> The hash was present specifically to tolerate one class of >>>> upstream failure. CTR_DRBG illustrates the distinction >>>> between an algorithm and a deployed system. The Cohney et al. >>>> work used cache leakage in a vulnerable AES implementation to >>>> recover DRBG state and compromise TLS [5]. That does not show >>>> that CTR_DRBG is kleptographic, but it does show that "use an >>>> approved DRBG" is incomplete implementation guidance. Similar >>>> questions exist for Hash_DRBG and HMAC_DRBG. What the >>>> relevant research literature says about side channels, fault >>>> injection, entropy failure, reseeding, (RNG) state compromise, >>>> and malicious implementation all deserve systematic analysis. >>>> We should define the attack classes carefully. Young and >>>> Yung's SETUP model is a natural starting point for deliberate >>>> kleptography, while side-channel and fault attacks may belong >>>> in adjacent categories. The engineering response can still be >>>> systematic: * write down each attack strategy and the >>>> required capabilities; * distinguish design, implementation, >>>> supply- chain, and compulsion failures; * test whether each >>>> construction and implementation resists it; * record >>>> mitigations and residual risk; and * set a minimum profile >>>> for protocol use. Hardware acceleration is not a magic >>>> boundary. AES instructions, RDRAND, and SHA extensions reduce >>>> some software-side channels but add assumptions about >>>> hardware, microcode, firmware signing, and update channels. >>>> Those assumptions can fail through ordinary bugs or >>>> sophisticated compromise. The point is not that every extreme >>>> scenario is occurring; it is that protocol guidance should not >>>> confuse a standardized algorithm with an immutable, side- >>>> channel-free implementation. Also, IETF should not push a >>>> standard that requires FIPS-certified setting as a general >>>> matter when the general case was made weaker and imposed a new >>>> dependency to acheive security: the FIPS- certified setting! I >>>> have preliminary experiments in which an ML-KEM interaction >>>> supplies a useful observation point against a deliberately >>>> vulnerable table-based CTR_DRBG implementation. I do not >>>> present that as a general break or a finished result. The >>>> research from 2019/2020 still generally applies. The >>>> immediate conclusion remains modest: require a defensible RBG, >>>> require secure implementation and state management, and hash >>>> `m` so this particular peer interface does not export raw >>>> structure. The longer-term work can determine what additional >>>> requirements are needed for each SP 800-90 construction. Also >>>> just to restate the obvious: we are really discussing some >>>> text in a text file that is _advice_ to implemnters who are >>>> not building in a NIST-certified setting. Those implementers >>>> better understand the situation and are required to >>>> diligently follow NIST's standards. Yes, that still leads to >>>> certified implementations being broken in some cases and that >>>> is _also_ NIST's problem, not the core concern that we face. >>>>>>> There is only the 1DES key weakening and the Dual_EC >>>>>>> adventure, >>>>>> This is not a fair or accurate accounting of the history. >>>>>> Even if you skip the Clipper Chip, export cryptography >>>>>> and all related attacks in SSL/TLS, and many other >>>>>> related matters, the issue of Dual_EC_DRBG amazingly >>>>>> *still* ships today in one of the most popular Java >>>>>> libraries in the world. It also ships ML-KEM. We agree >>>>>> about 1DES, of course. >>>>> Clipper was an overt attack on the public. There are at >>>>> least two distinct issues. >>>> Clipper was an overt policy attack, but policy opposition was >>>> not the whole story. From memory, Prof. Dr. Matt Blaze had to >>>> find a novel technical failure in the Escrowed Encryption >>>> Standard: the 16-bit LEAF authentication check could be >>>> searched so that a device retained strong Skipjack encryption >>>> while bypassing the escrow mechanism [9]. This was not a >>>> cryptanalytic break of Skipjack itself; it was a break of the >>>> key-escrow protocol surrounding it. That distinction >>>> strengthens, rather than weakens, the lesson that expert >>>> technical review can defeat a government-mandated access >>>> design. Skipjack itself followed the 1DES pattern with the >>>> 80- bit key and 64 bit block choices by the way. >>>>> The 512-bit modular DH group precomputation thing was not a >>>>> covert attack on the standards process. >>>> It is not only about 512-bit DH, of course. I understand the >>>> perspective that export controls and weak 512- bit groups >>>> were not, by themselves, covert manipulation of the standards >>>> process. Noteworthy however is that "covert" depends on a lot >>>> of assumptions about people's understanding of what certain >>>> technical framing means in a given context. The GSM >>>> cryptographic weaknesses may well have been understood by >>>> some telecom technician but most non-technical users of the >>>> phones most certainly did not always understand. They were >>>> nevertheless policy-created weaknesses whose practical >>>> consequences were not understood by most users of products >>>> marketed as secure. We should classify the history precisely >>>> without minimizing the harm. >>>>> Perhaps only Dual_EC was a covert attack on the standards >>>>> process. >>>> I do not think Dual_EC_DRBG exhausts the documented history >>>> of SIGINT enabling or weakened communications standards. GSM >>>> is one example. TETRA is another important case: the secret >>>> TEA1 algorithm, used in critical-communications systems, >>>> reduced an advertised 80- bit key to 32 effective bits and was >>>> only publicly understood after reverse engineering [10]. The >>>> researchers did not establish who inserted the weakening or >>>> whether it was exploited, but the result is directly relevant >>>> to how we evaluate secret or nationally constrained >>>> cryptographic designs. TETRA is highly relevant to European >>>> security. >>>>> ML-KEM might be a covert attack, but not on the standards >>>>> process because the codepoints were always going to be >>>>> assigned, and of course we're discussing the possibility >>>>> that ML- KEM is kleptography so much that everyone who >>>>> needs to know that it could be, does. >>>> The public, undeniable fact is that FIPS 203 removed the hash >>>> that Kyber said protected against flawed randomness [2][3]. I >>>> am not claiming that ML-KEM is itself a covert attack. I am >>>> saying that the change opens a direct hidden-structure >>>> failure mode and that an approved algorithm name does not >>>> eliminate implementation or side-channel risk and that is when >>>> we are speaking about the FIPS- certified setting. Outside of >>>> that NIST's change makes our lives harder which is not >>>> something that we are required to accept and to pass on to >>>> others. The NetBSD kernel wide DRBG CTR_DRBG example from [5] >>>> was impressive. >>>>> Clipper being an overt attack, and ML-KEM maybe a covert >>>>> attack, you can see that Clipper would be easier to defeat >>>>> -- the whole public could see it. >>>> Agreed: the removal is not covert. Appendix C.1 records it. >>>> The technical effect is also public: relative to third-round >>>> Kyber, ML- KEM no longer has that local safeguard against >>>> flawed randomness. Experts therefore have a responsibility to >>>> explain the tradeoff and the assumption that replaced it. >>>>>>> And again, if your fears turn out to be true, then you >>>>>>> win a big prize: more egg on the NSA's face. >>>>>> This does not follow. It took over a decade for John >>>>>> Kelsey to come out with his public apology tour. It only >>>>>> happened because one person blew the whistle and >>>>>> essentially killed himself for us to know about it. >>>>> But the egg landed on their face much earlier. Apologies >>>>> and non- apologies are merely the acknowledgement >>>> Agreed that the reputational damage began earlier but it was >>>> also paid in disrespect to people who raised the findings as >>>> a concern. That pattern repeats here as a variation on the >>>> theme but this time, the attack may be a fact to some but now >>>> instead of being in doubt, it is dismissed as old news or as >>>> irrelevent or unexploitable, and so on. The important point >>>> is not whether an institution eventually apologizes; it is >>>> how long users remain exposed before the technical problem is >>>> acknowledged and fixed. Shumow and Ferguson's 2007 rump- >>>> session observation, and Blaze's Clipper work, are reminders >>>> that early warnings deserve serious technical treatment. >>>>>>> Thus I don't think there is anything we can do >>>>>>> regarding `m` other than give advice for non-FIPS >>>>>>> implementations -- perhaps we should do that much, >>>>>> That sounds like the discussions have moved you! >>>>> Then you might like the above. Except you might not >>>>> because it doesn't move the needle as much as you seem to >>>>> want. >>>> I will take the movement and thank you for several intense >>>> but useful days of discussion. >>>>>>> but that seems like something TLS and IETF should say >>>>>>> much more generally in a BCP rather than in each >>>>>>> Internet protocol RFC that somehow needs RNGs. >>>>>> Or maybe, not? I guess I also agree with you that we need >>>>>> a draft about the overall issue. Would you be interested >>>>>> in co- authoring such a draft? >>>>> I cannot easily co-author I-Ds [for reasons], not with >>>>> celerity. I can comment and suggest text. >>>> Thank you. Comments and suggested text would be genuinely >>>> useful; I could take responsibility for an updated draft but >>>> I think the draft authors should resolve the outstanding >>>> technical issues that they see as valid. That tells us about >>>> the security posture that they wish to advance in the IETF. >>>> That applies _equally_ to the hybrid and the pure ML-KEM >>>> drafts. >>>>>>> * You and others are destroying your credibility and >>>>>>> good will towards yourselves and towards the IETF by >>>>>>> really reaching in your arguments against ML-KEM. >>>>>> That is a fair point. [...] >>>>> That sounds like the discussions have moved you as well :) >>>> Yes. The discussion has moved me toward a narrower, more >>>> actionable position where now I see that NIST's current DRBG >>>> offerings are _exceeding dangerous_ in the TLS context. >>>> Simply presenting them without qualification seriously >>>> misrepresents the risks as a general solution. I remain >>>> concerned that credibility and tone sometimes displace >>>> technical disposition, but I should also make my own arguments >>>> easier to assess and harder to dismiss. >>>>>> I observed an intense desire for conformity and >>>>>> harmonization in the form of a popularity contest. There >>>>>> are a few people in the discussion who broke through that >>>>>> wall. Quite a few people demonstrated that when it came >>>>>> down to a factual point that they have a duty to the >>>>>> truth. I personally respect that a lot more than the >>>>>> parasocial shaming behavior and the foot dragging. >>>>> Last October I was on DJB's side. His pounding the table >>>>> got me to abandon that side -- there were no real arguments >>>>> other than "they've done it before" and "of course they'd >>>>> do it again". Now there's the `m` matter, and regarding >>>>> that see the above. >>>> The cases for and against pure PQC and hybrids are broader >>>> than those two slogans. I also understand why perceptions of >>>> repetitive or abrasive presentation can cause readers to >>>> disengage. This is in part a big structural failing of the >>>> NIST process and it is a problem in the IETF as well. At the >>>> same time, process cannot substitute reaction to style for a >>>> technical disposition. NIST's participation raised factual >>>> questions about the history and rationale of the change, and >>>> the answers did not resolve all of them. My earlier comments >>>> also waited years for a partial response. That history helps >>>> explain the frustration, although it does not excuse >>>> unnecessary heat from any participant. I will focus this >>>> reply on the concrete convergence: define the RBG >>>> requirements, explain `m`, record the Kyber/FIPS change, and >>>> state the mitigation. >>>>> I really want to emphasize that DJB's manner of argument is >>>>> a tremendous turn-off. >>>> I hear you. It should not determine whether a reproducible >>>> technical claim is true. The working group needs both >>>> professional communication and a process that tracks >>>> substantive objections to a clear disposition. >>>>>> We should still try to do good things for the betterment >>>>>> of all people, even if they're unappreciative. >>>>> Some people, when faced with a difficult war, choose a hill >>>>> to die on, then die on it. Others fight until it's time to >>>>> retreat to live to fight another day. Martyrs don't win >>>>> wars. >>>> I understand. The useful response is not martyrdom but >>>> converting the issue into durable text and reproducible work. >>>> While it remains in our power, we should endeavor to create >>>> that centered around the End User's security. The End User >>>> that is not in the FIPS-certified setting especially as NIST >>>> has the FIPS-certified setting covered. It does not exactly >>>> inspire confidence that in the FIPS-certified setting the >>>> certified CTR_DRBG could be exploited to remotely extract the >>>> CTR_DRBG AES keys over a network through TLS. They have it >>>> covered alright! That security posture is their choice. >>>>>> This mistake by NIST should be undone in so much as we >>>>>> should not go along with something when the research data >>>>>> shows that it is dangerous. >>>>> Look at it from NIST's point of view: that hash merely >>>>> extends the DRBG, and via FIPS they mandate DRBGs, so if >>>>> the hash is important then it should be included in the DRBG >>>>> or the DRBG should be designed so it's not needed because >>>>> the DRBG is not necessary. >>>> I understand that position. But a protocol-level hash is not >>>> merely "more DRBG." It enforces a property at a separate >>>> boundary: the peer receives `H(x)` rather than the DRBG >>>> output `x`. That matters precisely when the upstream RBG >>>> assumption fails, and not every TLS deployment is inside the >>>> FIPS validation model. >>>>> Thus my [new] position is that we should limit the set of >>>>> acceptable DRBGs. >>>> We may agree on limiting acceptable RBGs if phrased as NIST's >>>> requirements that must be imposed to acheive their notion of >>>> security. Because approved construction names do not by >>>> themselves guarantee a safe implementation, I would add >>>> implementation guidance here and develop the broader >>>> requirements in a separate document. I was shocked when I >>>> realized that the literature piles up but the FIPS standards >>>> do not keep pace, rather the _threat model_ is updated! TLS >>>> should become stronger and stronger as we learn new things, >>>> and the threat model should become _stronger_ as adversary >>>> capabilities improve. The purpose of TLS is to provide >>>> _security_ not a false sense of security, after all. >>>>>> Yes, I understand the criticism that this appears to be >>>>>> contrived because you do not use /dev/hwrng or similar >>>>>> interfaces but I wonder what would change your mind? >>>>> The `m` issue did change my mind, as you noted. Just not >>>>> to the point of opposing publication. Rather, I propose >>>>> normatively limiting the choice of DRBGs to ones we believe >>>>> are not kleptographic. >>>> I do not oppose publication once the immediate issues are >>>> written down or referenced accurately. >>>>>> For example, the Cavium SIGINT enabling - Cavium has a >>>>>> kernel driver for their hwrng and it presents as /dev/ >>>>>> hwrng which does not transform the output. This kind of >>>>>> CPU is used in "security" devices. Please consider that >>>>>> NSA claims it as a SIGINT Enabling Success. >>>>> If you have a TLA-in-the-box attack, you have bigger >>>>> problems. And by you I mean we, naturally. >>>> My question is whether "if" is the right prior and what >>>> evidence would change it. The Cavium reporting shows a >>>> knowledge-and-choice problem: users may rely on hardware and >>>> firmware they cannot meaningfully audit, and hardware RNG >>>> interfaces can feed operating-system entropy pools or be >>>> consumed directly. A compromised source is a system- wide >>>> problem, but that is not a reason to remove cheap local >>>> barriers at protocol boundaries. The reason for the removal >>>> is not required for security and it re-introduces an entire >>>> class of security failures. Some large-scale deployments >>>> could easily remove that hash and no one will know, so in my >>>> view those kinds of deployments should not impose their >>>> extreme privilege on the rest of us. Most people, unlike the >>>> large defense contractors who mentioned hashing was going to >>>> impact their bottom line or the environment, do not have >>>> thousands of engineers working from the top to the bottom on >>>> their systems. Most people do not have absolute confidence in >>>> their full computing systems, they must make assumptions about >>>> trust which will change in a big way with this PQC transition. >>>>>> Would you believe that someone does the wrong thing with >>>>>> that kind of stack and does so in a way that harms >>>>>> security? >>>>> Certainly possible, even likely. >>>> I am glad we agree. >>>>>>> * We know they will go to IEEE if we don't publish. IETF >>>>>>> is much more open, so if we abdicate our remit to more >>>>>>> closed SDOs, what will you have achieved with this >>>>>>> social death penalty? >>>>>> I do not understand this part - the draft can go to the >>>>>> ISE if consensus can't be reached. Deb should not be >>>>>> pushed out of the IETF, and no one should be ostracizing >>>>>> her. This holds for anyone in these discussions, even >>>>>> convicted felons. >>>>> See above (at the very top). >>>> Understood. >>>>>> That said - if the authors of the draft want to take it >>>>>> elsewhere and publish it, especially because the WG won't >>>>>> rubberstamp something and want to add some basic security >>>>>> considerations, I would say that is their right. I note >>>>>> that they are welcome to integrate the text and then I >>>>>> think most objections would be handled. Most of us can't >>>>>> edit the draft by merging a pull request. I have the >>>>>> sneaking suspicion that that if I open the pull request >>>>>> that it would not be merged. If I am wrong, I would do >>>>>> the work. >>>>> Would you settle for publishing with a normative >>>>> requirement that the DRBG used to generate `m` be one we >>>>> approve of? >>>> Almost. I would settle on publication with a normative RBG >>>> requirement plus text that explains why `m` matters and >>>> recommends restoring the hash. The RBG restriction and the >>>> hash address different layers. The same is true of CTR_DRBG: >>>> choosing the construction does not excuse a leaky table-based >>>> AES implementation. That leaky table-based AES situation is >>>> catastrophic and that is for a current NIST DRBG. At the very >>>> least we should also normatively cite the (ever weaker?) NIST >>>> threat model! >>>>>>> Really, pick your fights carefully! >>>>>> I take your point(s) and I respectfully submit that I >>>>>> observe what appear to be some oversight in a few of your >>>>>> priors. I appreciate many of your points though. >>>>> Have I covered all points now? >>>> Probably, yes. Remaining is some discussion above as well as >>>> the task to produce the exact text. >>>>>> We all have a duty to resist and none of us have a duty >>>>>> to obey. We >>>>> I agree with this. >>>> Good to know, I am glad. >>>>>> have no requirement to simply go along with such things, >>>>>> especially if we think will lead to harm to the End User. >>>>>> With deep respect to the actual Indigenous people of the >>>>>> world: we the Indigenous Cryptographers of the Internet >>>>>> SHOULD help the End User to resist targeted and mass >>>>>> surveillance and indeed, we MUST treat pervasive >>>>>> monitoring as an attack [0]. To paraphrase Bill Hicks: >>>>>> there is a war on your privacy and each time that you >>>>>> protect your privacy with strong encryption, you're >>>>>> winning it. >>>>> On so many fronts. The whole age verification stuff is >>>>> clearly aimed at ending anonymous and pseudonymous posting >>>>> so as to force self-censorship on people. >>>> Agreed. The claimed benefit of broad age-verification >>>> mandates does not justify the resulting surveillance, identity >>>> linkage, and chilling of anonymous or pseudonymous expression. >>>>>> [0] A term the NSA has given *us* and we should claim it, >>>>>> and wear it with pride to stand in solidarity with other >>>>>> Indigenous peoples of the world. Note: "the fact that >>>>>> NSA/ CSS makes cryptographic modifications to commercial >>>>>> or indigenous cryptographic information security devices >>>>>> or systems in order to make them exploitable" is "Top >>>>>> Secret" - https:// www.spiegel.de/ international/germany/ >>>>>> inside-the-nsa- s-war-on- internet-security- >>>>>> a-1010361.html >>>>> But also public. And something we basically knew to expect. >>>> Yes. The history is public enough that surprise is no longer >>>> a reasonable response. The standards question is which >>>> concrete engineering lessons we apply now. Kind regards, >>>> Jacob Appelbaum [0] https://datatracker.ietf.org/doc/html/ >>>> rfc8730 [1] https://datatracker.ietf.org/doc/html/rfc5742 [2] >>>> https:// nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf [3] >>>> https:// pq-crystals.org/kyber/data/kyber-specification- >>>> round3-20210804.pdf [4] https://ntruprime.cr.yp.to/nist/ >>>> ntruprime-20201007.pdf [5] https://eprint.iacr.org/2019/996 >>>> [6] https://datatracker.ietf.org/doc/html/rfc4086 [7] >>>> https:// datatracker.ietf.org/doc/html/rfc8937 [8] https:// >>>> hovav.net/ ucsd/dist/juniper.pdf [9] https://www.mattblaze.org/ >>>> papers/ eesproto.pdf [10] https://www.midnightblue.nl/ >>>> research/ tetraburst [11] https://cr.yp.to/antiforgery/ >>>> cachetiming-20050414.pdf [12] https://datatracker.ietf.org/ >>>> doc/ html/rfc7258 >>>> _______________________________________________ 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]