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.
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. 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). Unless I am fundamentally mistaken on one the above two points, I cannot see how pre-hashing confers any security benefit. Against an adversary capable of mounting an attack where it has a claimed benefit, the system is insecure anyway. 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. Unless either one of the above two points is wrong, I will stop engaging in this discussion. We’ve already seen one positive contributor to the WG say this discussion has pushed them to withdraw from the WG. I do not want to be “half” of the discussion that pushes others in this same direction. 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 [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]
