Daniel J. BernsteinApr 10
The IETF TLS chairs have now issued a "last call" for objections to non-hybrid signatures in TLS. Do they admit that their previous "last call" re non-hybrid KEMs ended up with a _majority_ in opposition, and that many opposition statements obviously also apply to signatures? No.
Show threadARGVMI~1.PIFApr 10

@djb

Why do they want non-hybrid KEMs and signatures, anyway? Seems like a bad idea to protect all of everything with nothing but unproven crypto.

paepcke.de    +    + 🇪🇺Apr 13
Show threadDaniel J. Bernstein

@argv_minus_one I have an introductory chart https://blog.cr.yp.to/20260221-structure.html showing the arguments and counterarguments.

Most common argument from proponents: NSA is asking for non-hybrids, ergo support non-hybrids. This argument works for (1) companies chasing NSA money, (2) companies that take any excuse for extra options as a barrier to entry for competitors, and (3) people who think that "NSA Cybersecurity" isn't a conduit for https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf but rather an independent pro-security agency.

Apr 10 at 9:10pmWeb
Show threadARGVMI~1.PIFApr 10

@djb

Welp, I think it's safe to assume that ML-KEM is already broken and so is the IETF TLS committee. Lovely.

Show threadrsalzApr 10
@darkuncle Sorry to see you promoting this. He's done great work, but this whole thread is crazy conspiracy thinking.
Show threadScott FrancisApr 10

@rsalz DJB sees a conspiracy where one may not exist ... but has a history of seeing one where it did very much in fact exist.

I think cryptographers erring on the side of extreme caution is a net benefit (and his points about unjustified and unexplained foot-dragging and resistance on Classic McEliece adoption have been well documented)

Show threadScott FrancisApr 10
@rsalz I feel like the whole Dual_EC_DRBG saga kind of permanently poisoned the well here
Show threadrsalzApr 10
@darkuncle At the time of Dual_EC, NIST was required by law to take NSA's advice. They no longer are. But what history of seeing conspiracy where it did exist are you thinking of?
Show threadScott FrancisApr 10

@rsalz Dual_EC specifically is an example of NSA hijacking the standards process for nefarious purposes. Maybe that was the only one ever, and an anomaly! (But see also DES back in the 90s ...)

But it would be wise to proceed with skepticism on all future contributions from a source that proved to be a bad actor. When an actor has a documented history of bad behavior, it's both natural and wise that all their future behavior face extra scrutiny and skepticism.

More recently, the arguments against hybrids seem ... weak. See e.g., https://blog.cr.yp.to/20240102-hybrid.html and https://blog.cr.yp.to/20251004-weakened.html (which has six sequels)

Show threadrsalzApr 10
@darkuncle I don't recall Dan suspecting dual EC but I may just be forgetting that. NIST, however did learn their lesson and sponsored global contests for AES post quantum etc. Not NSA.
Show threadScott FrancisApr 10
@rsalz NSA and other intel agencies still influencing standards process (see prior links), which is what I think is cause for skepticism if not suspicion
Show threadrsalzApr 10
@darkuncle as an active participant in many of the working groups, and colleagues with NSA and others, I do not believe there is any covert influence happening. His arguments have devolved to little more than ad hominem attacks. Kind of sad. I've known him for 30 years.
Show threadScott FrancisApr 10
@rsalz this is good news in terms of engagement from the agency! However, given their mission to subvert foreign comms (that primarily rely on the same standards to which NSA contributes) that at least we should consider where incentives lie.
Show threadKoos Pol 🇺🇦Apr 11
@rsalz @darkuncle This is an very naive stance. Ofcourse they are. It's their god given purpose on earth. As long as the NSA is tasked to know more about me than for me to know more about them, my decision is made. Also "I've know him for 30 years" is an ad hominem in itself.
Show threadrsalzApr 10
@darkuncle Yes, erring on the side of extreme caution is right. But you completely discount Bas Westerban, Sophie Schmeig, etc?
Show threadScott FrancisApr 10
@rsalz not at all! Bas and Sophie in particular are awesome cryptographers and good people; I'm just saying that proceeding with the assumption that cryptographic proposals from NSA require greater-than-average skepticism seems wise based on the history.
Show threadPaul_IPv6Apr 10

@darkuncle @rsalz

DJB has always been touchy and can really get into the weeds on some conspiracy theory. really smart guy but i tend to take his rants with a heavy grain of salt.

it's been this way since early usenet days.

Show threadScott FrancisApr 10
@paul_ipv6 @rsalz as they say, just because you're paranoid doesn't mean they aren't after you. :)
Show threadDaniel J. BernsteinApr 10
@rsalz @darkuncle You think https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf is a conspiracy theory?
Show threadPedroMJApr 10
@djb @rsalz @darkuncle We can try to amend such kind of dangerous situations with a new draft.
Show threadrsalzApr 10
@djb @darkuncle no I do not, but that does not mean that the NSA is corrupting the IETF.
Show threadDaniel J. BernsteinApr 11
@rsalz @darkuncle Let me see if I understand. You're agreeing that NSA has a large budget to sabotage "standards and specification for commercial public key technologies" etc., but you presume that this doesn't include IETF, since the document doesn't _specifically_ name IETF? Also, just checking: by the same logic, you presume that this doesn't include ISO? NIST? IEEE? When we recommend proactive steps to protect SDOs against sabotage, you accuse us of being crazy conspiracy theorists?
Show threadrsalzApr 11
@djb @darkuncle I presumed nothing. Read what I wrote. Twisting words to win an argument. Your better than this Dan.
Show threadPaul HoffmanApr 11
@rsalz @djb Do you have any evidence of that last statement, Rich?
Show threadrsalzApr 11
@paulehoffman Very funny. :). And sad :(
Show threadDaniel J. BernsteinApr 13

@paulehoffman @rsalz Paul, great to see you showing up here!

We're currently discussing Rich's delusion that NSA doesn't attack IETF. On that topic, can you please state for the record how much NSA paid you for your promotion of TLS randomness extensions in IETF (https://web.archive.org/web/20260331174508/https://sockpuppet.org/blog/2015/08/04/is-extended-random-malicious/)? Or are you denying that this happened?

Also, do you dispute https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/checkoway saying that Dual EC becomes thousands of times cheaper to attack whenever those randomness extensions are deployed?

Is Extended Random A Malicious NSA Plot? — Quarrelsome

Show threadChristian HuitemaApr 13
@djb @paulehoffman @rsalz I don't know for 2012, but from 2013 on a large number of IETF participants were absolutely convinced of being under attack. It was fairly obvious that some IETF participants were either willing enablers of these attacks, or "useful idiots". But we don't know which ones, and we quickly realized that launching a witch-hunt would be very destructive, and that the safest path was to keep discussions strictly technical.
Show threadEliot LearApr 13

@huitema

I would argue that what we had at the time was a frenzied mob, particularly in Vancouver.

Show threadDaniel J. BernsteinApr 13
@huitema @paulehoffman @rsalz Using ECC+PQ instead of non-hybrid PQ is a straightforward, low-cost, broadly recommended, broadly deployed technical step to limit the damage from PQ security failures (such as the SIKE break and KyberSlash). The problem at hand is non-technical, namely NSA pressuring various companies such as Cisco to support non-hybrid PQ. See https://blog.cr.yp.to/20251004-weakened.html#tls for quotes from employees of NSA and Cisco admitting this.
Show threadChristian HuitemaApr 13
@djb @paulehoffman @rsalz The political problem is complex. First, there is a wide consensus in the IETF for not standing in the way of deployments, and in particular not using IETF processes to block IANA registration except in some very specific registers -- because blockades generate various kinds of smuggling that end up very counter-productive in general.
Show threadChristian HuitemaApr 13
@djb @paulehoffman @rsalz So the question for the PQ-only algorithms is not whether the IETF can prevent deployment (it cannot), but whether publishing these algorithms as RFCs is necessary or harmful. There is consensus that it is not necessary, since the IANA registrations do not require it. What we see is mostly a debate on whether it is harmful, because it would help promoting an unproven algorithm that might be compromised. This is where opinions vary.
Show threadDaniel J. BernsteinApr 13
@huitema @paulehoffman @rsalz I've been tracking the arguments and counterarguments (see https://blog.cr.yp.to/20260221-structure.html for a chart) and I don't see where you're getting this "promoting" idea from. Both sides of the debate want to roll out PQ to try to stop quantum attacks. The difference is that one side says you're allowed to replace ECC with _just_ PQ, whereas the other side is requiring ECC+PQ (at negligible extra cost) to reduce the damage caused by more failures of PQ security.
Show threadChristian HuitemaApr 13
@djb @paulehoffman @rsalz By promoting, I meant "publication as an RFC would help the marketing (or promotion) of the PQ-only approach by actors linked to the US government." As in, "of course you can do that, the IETF published it as an RFC, do not look at the fine print."
Show threadDaniel J. BernsteinApr 14
@huitema @paulehoffman @rsalz It's important to distinguish the non-controversial part (rolling out a PQ layer) from the controversial part (_removing_ the existing ECC layer rather than _supplementing_ the existing ECC layer). Saying that the objection is to "promoting an unproven algorithm" misunderstands what's actually at issue. Same for lumping both parts together into a combined "approach" and saying the objection is to that.
Show threadChristian HuitemaApr 14
@djb @paulehoffman @rsalz I don't understand what you mean by "removing". The hybrid key exchanges are defined in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/, which went through IETF last call and is in the final stage of approval by the IESG. I don't know that anybody is proposing to remove that.
Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

This draft defines three hybrid key agreement mechanisms for TLS 1.3 - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 - that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Elliptic Curve Diffie- Hellman) exchange.

IETF Datatracker
Show threadDaniel J. BernsteinApr 15
@huitema @paulehoffman @rsalz Let's try an example. Google and Cloudflare used CECPQ2b = ECC+SIKE for tens of millions of user connections, instead of the usual ECC. That wasn't _removing_ ECC in favor of SIKE; it was _supplementing_ ECC with SIKE. This is why the break of SIKE still left those connections with the usual security of ECC. If they had instead incompetently _removed_ ECC and replaced that with SIKE, the SIKE attack would have immediately broken all of those connections.
Show threadChristian HuitemaApr 13
@djb @paulehoffman @rsalz The IETF has a strong bent towards "publishing rather than censoring", unless the technical flaws are obvious. That bent drives strongly towards "publishing with some proper warning in the text", while not publishing at all would be pretty extraordinary, especially in presence of a constituency that really want to sell products to the US government. So at that stage of the debate, the issue is really about how strong the warning should be.
Show threadDaniel J. BernsteinApr 13
@huitema @paulehoffman @rsalz We require seatbelts in cars to reduce the number and severity of injuries in the event of a crash. The problem with allowing seatbelts to be skipped is something we explain to 6-year-olds. No, we don't allow cars to be sold with warnings in place of seatbelts. And, no, we don't allow the seatbelt rules to be corrupted by funding from the National Morgue Association.
Show threadPaul Wouters 🇪🇺🇨🇦Apr 13

@djb @huitema @paulehoffman @rsalz the analogy is of course ridiculously broken because everyone is building towards and expecting the future to be PQ only.

A better comparison is a scenario where we mandate hybrid cars because perhaps EV technology will fail in the future, even though we know eventually everyone will drive a pure EV.

Some people now prefer gas, some hybrid, some EV. We let people choose because non of the car variants are dangerous.

You are trying to force hybrid cars on everyone because you think EV might break despite years of research of the worlds best experts.

Show threadDaniel J. BernsteinApr 13

@letoams @huitema @paulehoffman @rsalz Requiring seatbelts in cars reduces the damage to humans from car crashes. Requiring ECC along with PQ reduces the damage to the users from PQ security failures.

Saying that people are trying to prevent PQ failures doesn't break this analogy. People are also trying to prevent car crashes.

I'm unable to decipher your attempt to draw another analogy: e.g., I can't figure out whether "perhaps EV technology will fail" is sticking to the topic of _safety_.

Show threadDaniel J. BernsteinApr 13
@letoams @huitema @paulehoffman @rsalz I do understand that your attempted analogy somehow involves decisions between gas vehicles, electric vehicles, and hybrids. But those have major cost differences, whereas the cost of PQ (which is dominated by communication cost for typical PQ choices) is so close to the cost of ECC+PQ that we've been seeing comic levels of failure to find _any_ application that can't afford to keep the ECC part.
Show threadDaniel J. BernsteinApr 13
@letoams @huitema @paulehoffman @rsalz ML-KEM-768 has 1184-byte public keys and 1088-byte ciphertexts. Bleeding-edge ML-DSA-44 has 1312-byte public keys and 2420-byte signatures. It ends up sounding pretty damn stupid to complain about the extra cost of also continuing to send 32-byte ECC keys and 32-byte ECC ciphertexts.
Show threadPedroMJApr 13
@djb @letoams @huitema @paulehoffman @rsalz I insist [1], this fits into a new I-D.
[1] https://mastodon.social/@pedromj/116399619082728297
Show threadPedroMJApr 13
@djb @huitema @paulehoffman @rsalz The problem discussed in this thread can be amended with a new prescriptive draft that states the potentially undesired outcomes and that specifies the means to avoid them.
Show threadChristian HuitemaApr 13
@pedromj @djb @paulehoffman @rsalz I am really not sure that publishing more words would help counter propaganda by the bad faith actors that Dan fears. If the WG does decide to publish the ML-KEM TLS draft, strong warnig would help somewhat. Changing the registration option of the hybrid key exchange algorithms to recommended=Y would also help. But propaganda is countered by public speech, not so much by standard actions.
Show threadPedroMJApr 14
@huitema @djb @paulehoffman @rsalz Some one cannot force other one to add the warning to their I-D, but can write the warning in a new I-D and find enough support for it to make the previous I-D to integrate the new I-D ---hence adding the warnin---, or live separately to help engineers know about the problem.
Show threadChristian HuitemaApr 14
@pedromj @djb @paulehoffman @rsalz Actually, working groups can pressure for changes in a draft. Once a draft is accepted by a working group, the status of the authors change. They are not the only one in charge of the text anymore. What they write must reflect the consensus of the WG, and if that consensus includes adding a warning, they have to do that.
Show threadPedroMJApr 14
@huitema @djb @paulehoffman @rsalz I know this, but one must be active in a WG to convince enough members to vote for something like adding some text. It is not easy to be so active sporadically. It is much more feasible to write concerns in an I-D ---a formal document with familiar structure--- and discuss it in some MLs and/or meetings.
Show threadChristian HuitemaApr 14
@pedromj @djb @paulehoffman @rsalz We are heading towards a situation where the ML-KEM key exchange draft will be published, probably in about a year. I would much prefer to see a warning in the text itself, and I think that can be achieved. After that, the IETF will have published 2 documents, hybrid ML-KEM and naked ML-KEM. If we follow Dan's reasoning, we can expect the US Gov to encourage "naked", which they might be able to break. We will be in the domain of opinions, not standards.
Show threadChristian HuitemaApr 14
@pedromj @djb @paulehoffman @rsalz After publication of naked ML-KEM, we could try to sway opinion by publishing Internet drafts such a "naked ML-KEM considered harmful". We could lobby browser vendors to not implement that. We could publish in news papers, rally suppport from the EFF, etc. All that may help getting people to deploy hybryd ML-KEM instead. But it would help more if there is an warning in the naked ML-KEM draft itself.
Show threadrsalzApr 14
@huitema @pedromj I'll assume you read the draft and the PR with the revised security considerations. You also know that pushing on social media doesn't much impact IETF, unless you're trying to do brigading which I do not think you are.
Show threadDaniel J. BernsteinApr 15
@huitema @pedromj @paulehoffman @rsalz You're confused. The normal way to deploy post-quantum KEMs is _already_ as a second layer _on top_ of ECC. See the long list of examples at the top of https://blog.cr.yp.to/20251004-weakened.html. What NSA has been trying to do is pay for IETF endorsement of a weaker alternative that removes ECC.
Show threadrsalzApr 14
@huitema You think it will be published? I'm not sure sure it has consensus.
Show threadChristian HuitemaApr 15
@rsalz Not that I specially want to, but yes I assume that after a couple more months of discussion the naked ML-KEM draft will be published. This is not certain, but that's the most likely outcome. This is not like the visibility draft, for which there was a plurality of "strongly oppose". This kind of debate typically ends with a compromise, such as OK to publish if the opponents get a strongly enough wording in the security section, or maybe in the intro.
Show threadDaniel J. BernsteinApr 15
@huitema @pedromj @paulehoffman @rsalz The previous "last call" for objections to the _non-hybrid_ ML-KEM spec produced objections from 22 people and support from 21 people. Names, quotes, links: https://blog.cr.yp.to/20260405-votes.html This is obviously very far from the "consensus of the IETF community" that every WG-issued RFC claims to have. Are you really claiming that IETF will issue this as an RFC? Why do you claim this?
Show threadDaniel J. BernsteinApr 15
@huitema @pedromj @paulehoffman @rsalz The burden is the other way from what you're describing. The WG can't issue non-consensual RFCs. Conflicts must be resolved by a process of open review and discussion; if they aren't resolved then issuing an RFC would violate IETF rules for how WGs operate. It's not merely that the authors have to add a warning if there's consensus on a warning. There's no default entitlement for documents to sail through.
Show threadDaniel J. BernsteinApr 11
@rsalz @darkuncle You wrote "this whole thread is crazy conspiracy thinking" but I'm unable to figure out what you're disputing, i.e., what specifically you're claiming is a conspiracy theory. You _don't_ seem to be questioning the authenticity of https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf, an internal NSA document on NSA's massive budget to weaken "standards and specification for commercial public key technologies" etc. so as to make those "exploitable". What, then, _are_ you disputing?
Show threadrsalzApr 11

@djb @darkuncle

Everything I wrote is simple and consistent and, if you look at the context of when they were made, easy to follow. For those just jumping in.

1. As a long-time person involved with the IETF I have not seen any hidden/coercive NSA involvement.

2. I accept that the EFF budget piece is accurate.

3. The term "crazy conspiracy thinking" referred to your blog posts on this topic.

I do not argue with NSA/NIST and pointed out why they could do that in the past. I find it amusing that ISO refused to standardize NSA's Simon and Speck. Perhaps they're not as good at influence as they used to be.

Show threadJoe BrockmeierApr 11

@rsalz @djb @darkuncle dumb questions from the sidelines:

1: doesn’t it make sense to treat NSA preferences with a bit of suspicion given their history and mission?

2: if there is strong opposition to non-hybrid, besides djb’s, doesn’t that bear listening to? What’s the benefit here in overriding the concerns?

Very much not a crypto expert, I’m assuming there’s a lot I don’t know or understand here. Appreciate any answers.

Show threadrsalzApr 12

@jzb To answer your questions:

1. If it were only the NSA, sure, be suspicious. But it's not (IEEE, Ericsson I believe, others) and I do not believe they were all cofrupted.

2. Sure, the IETF is having that discussion. See what you think of https://github.com/tlswg/draft-ietf-tls-mlkem/pull/14/changes for example.

Rework security considerations by richsalz · Pull Request #14 · tlswg/draft-ietf-tls-mlkem

Rather than do what issues 10 and 11 request, this instead does a very light comparison from the hybrid ML-KEM draft, based on what each document says in its IANA recommendations. Fixes: #10,#11

GitHub
Show threadDaniel J. BernsteinApr 12
@jzb @rsalz @darkuncle Side note re "crypto expert": The issue here is basic security risk management. For example, Google and Cloudflare tried ECC+SIKE (CECPQ2b: https://web.archive.org/web/20260411125124/https://blog.cloudflare.com/the-tls-post-quantum-experiment/) for tens of millions of user connections, and then SIKE was publicly broken years later. The only reason this didn't immediately expose all those user connections to attackers is that the connections were still encrypted with ECC.
The TLS Post-Quantum Experiment

Take a look at the results of a real-world TLS post-quantum experiment conducted by Cloudflare & Google.

The Cloudflare Blog
Show threadScott FrancisApr 12
@djb @jzb @rsalz belt and suspenders
Show threadDaniel J. BernsteinApr 12
@rsalz @darkuncle NSA has a huge budget to "covertly influence and/or overtly leverage" cryptographic designs: https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf NSA _paying_ the RSA company to put Dual EC into RSA's BSafe library (https://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220/) is an example of overt leverage towards the RSA company, and of covert influence for the public not knowing about this. Same for NSA _paying_ companies to put non-hybrids into products. Do you dispute these examples of covert influence and/or overt leverage? If so, why?