@djb@mastodon.cr.yp.to

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Unhappy with NSA's SIGINT Enabling Project sabotaging cryptographic standards? This week you can take action to register an objection with IETF regarding an NSA-funded project to standardize ietf-tls-mlkem, a weakened version of ietf-tls-ecdhe-mlkem: https://nsa.2026.action.cr.yp.to/

nsa.2026.action.cr.yp.to

28

9

33

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 2mo ago

SHA-512 hash: 6674cf422ca5356e3a189eca7fb01cc511ee34194ae8f654e58491f4e01a480d095c2057a2316f479976155c752cc03029b9fab3d6ca18cc677403946c04f4e8

9

3

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

NSA lost IETF's February 2026 vote on this NSA-driven document. See https://blog.cr.yp.to/20260405-votes.html for tallies. Do they admit what happened? No. They call another vote and try hard to pack the room with new pro-NSA voters. But if we show up and object, all they can do is whimper.

blog.cr.yp.to

9

2

6

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Why add a PQ layer? To try to reduce the damage caused by quantum computers. Why also keep the existing (low-cost) ECC layer? To try to reduce the damage from further PQ security failures. For some reason this suddenly seems difficult for U.S. military contractors to understand.

22

0

9

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

NSA pressuring U.S. defense contractors to support solo PQ: "If there is one vendor that produces one product that complies, then that is the product ... approved for use. Our interactions with vendors suggests that this won't be a problem in most cases." https://web.archive.org/web/20250613195524/https://mailarchive.ietf.org/arch/msg/spasm/xUKIoHQwm1BjNZWS2x3xb-BhsLI/

web.archive.org

5

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 2mo ago

If https://archive.cr.yp.to/2026-08-06/07:22:47/YsHY7T0pBzBPgb0dukGNgEWT5F24hHibVcr38xs7rhg/https/eprint.iacr.org/2026/1591.pdf collapses upon examination, lattice-based cryptographers will say "See, we dodged another bullet"; but aren't all the bullets more than a bit terrifying? Use the largest parameters you can afford; keep the ECC seatbelt; keep investing in alternatives.

archive.cr.yp.to

2

0

2

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

GCHQ's "Peter C" pushing RFC for draft-ietf-tls-mlkem: "An Internet Draft ... is not sufficient as most SDOs (including the IETF) won't allow their standards to cite I-Ds normatively." Same Peter C yelling at opponent: "While ... is standards track, draft-ietf-tls-mlkem is not."

4

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

"Safety blanket" in https://web.archive.org/web/20260414114106/https://soatok.blog/2026/04/13/hybrid-constructions-the-post-quantum-safety-blanket/ and https://web.archive.org/web/20260418021002/https://symbolic.software/blog/2026-04-13-hybrid-constructions/ tells typical readers: using ECC+PQ, not just PQ, is for familiarity, not security. Huh? Millions of sessions used CECPQ2b=ECC+SIKE. ECC is the _only_ reason those weren't instantly exposed to the SIKE break.

Dhole Moments

Hybrid Constructions: The Post-Quantum Safety Blanket - Dhole Moments

The funny thing about safety blankets is they can double as stage curtains for security theater. Art: CMYKat “When will a cryptography-relevant quantum computer exist?” is a question ma…

11

12

11

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

IETF TLS WG chairs have closed the vote, and say they'll go through https://mailarchive.ietf.org/arch/browse/tls/ "to see what the consensus is". Consensus? Each side received more than 80 votes on list: e.g., 7 positive votes from DoD, 4 from Cisco, etc. (5 on each side didn't give full real names.)

mailarchive.ietf.org

3

0

2

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Wasn't someone saying a moment ago that ML-KEM is super-easy to implement correctly? How do we explain https://www.cve.org/CVERecord?id=CVE-2026-6330 then? Offhand I'd think this one isn't exploitable, but we'll see more and more ML-KEM bugs, and some of them will be severe vulnerabilities.

cve.org

3

0

2

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@Savagejen@mastodon.social Looking at the whole attack surface makes even more obvious that solo PQ damages security. We've already seen exploitable bugs and timing attacks for Dilithium (ML-DSA) and Kyber (ML-KEM)! Check out https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys for a graph of the estimated number of ML-DSA keys that will be broken because of predictable software vulnerabilities even if there are _no_ breaks of the ML-DSA spec. For ML-KEM a similar calculation shows an even bigger disaster.

cr.yp.to

3

0

2

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@FritzAdalis@infosec.exchange More fundamentally, https://web.archive.org/web/20250528213926/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/ says the following: "IETF activities are conducted with extreme transparency, in public forums. Decision-making requires achieving broad consensus via these public processes." IETF also labels every RFC from every WG as "consensus of the IETF community". The more people we have speaking up, the more obvious it is that what happened here wasn't consensus (even if they try to claim it was "rough consensus", whatever exactly that means).

web.archive.org

2

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@FritzAdalis@infosec.exchange The "51%" rule in IETF rules (https://web.archive.org/web/20251217213247/https://www.rfc-editor.org/rfc/rfc2418.html) says they can't proceed with 51% or less of the WG.

web.archive.org

RFC 2418: IETF Working Group Guidelines and Procedures

2

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@rsalz@ioc.exchange @letoams@defcon.social The actual rules (RFC 2418) use "IETF community" and "Internet community" interchangeably: "Anyone from the Internet community who has the time and interest is urged to participate in IETF meetings and any of its on-line working group discussions." You're trying to narrow this to companies that can afford to send people to _continually_ participate. But that's not what RFC 2418 says. Furthermore, IETF says that it's not a "pay-to-play organization".

2

0

2

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@katzenmann@c3d2.social The "chart of the debate" link near the top of https://nsa.2026.action.cr.yp.to/ links to a chart of the arguments and counterarguments. That chart https://blog.cr.yp.to/20260221-structure.html includes links to the original statements from both sides so you can read for yourself and decide.

nsa.2026.action.cr.yp.to

2

7

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

https://web.archive.org/web/20260418042422/https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html points to quantum threats _and_ the risk of PQ deployment being "breakable even with today's computers". See the difference from @kaepora claiming (https://web.archive.org/web/20260418021002/https://symbolic.software/blog/2026-04-13-hybrid-constructions/) that what "motivates hybrid KEMs" is "the harvest-now-decrypt-later (HNDL) threat"?

web.archive.org

4

0

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@FritzAdalis@infosec.exchange Here's the real story that RFC 7282 avoids citing: https://supreme.justia.com/cases/federal/us/486/492/ Antitrust law has an exception for standards-development organizations, but only when they provide "openness, balance of interests, due process, an appeals process, and consensus" (https://www.law.cornell.edu/uscode/text/15/4301#a_8) This is why IETF claims that a "wide range of perspectives is represented", that "decision-making requires achieving broad consensus", etc. These are not promises that IETF can easily weasel out of!

supreme.justia.com

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Cross-posting the Mastodon+Twitter results for comparison. Mastodon (215 replies): 9% "clearly trustworthy", 58% "Hmmm, I'm skeptical", 33% "I hate cryptographers". Twitter (69 replies): 11.6%, 65.2%, 23.2%. @djb@mastodon.cr.yp.to https://x.com/hashbreaker/status/2042712462487585022

X (formerly Twitter)

Daniel J. Bernstein (@hashbreaker) on X

Survey time: If you see a cryptographer saying "We told you for many years to trust cryptosystem X, but, oops, it's actually giving away all your data; please panic right now", how much do you believe the same cryptographer saying "We're telling you to trust cryptosystem Y"?

3

0

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

New blog post: "Bugs happen: The easy way to compare solo PQ to ECC+PQ." https://blog.cr.yp.to/20260704-bugs.html #pqcrypto #bugs #vulnerabilities #hybrids

blog.cr.yp.to

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@rsalz@ioc.exchange @letoams@defcon.social The chairs asked people to say whether or not they support issuing this document as an RFC. Posting an answer to that question is an example of participating in IETF. I have, from the outset, explicitly asked people to use their real names. Seems to me that the vast majority did. You're advocating disenfranchisement of a bunch of real people. Meanwhile I didn't notice you complaining about "Soatok Dreamseeker" posting endlessly in support of the document.

1

0

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@paulehoffman@infosec.exchange @rsalz@ioc.exchange 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?

web.archive.org

Is Extended Random A Malicious NSA Plot? — Quarrelsome

3

41

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@Elliptickiwi @light Note: _publicly_ factored. Presumably the first secret factorization will be earlier, but it's hard to be sure how much earlier, so secret doesn't work as a topic of a bet.

3

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@rsalz@ioc.exchange @letoams@defcon.social Did you complain when NSA overtly waved around money to pressure its "vendors" to support this draft? Did you complain when they suddenly called a new vote and flooded the room with votes, such as the vote from NSA's Mike Jenkins, his first-ever TLS list message? Explicitly in response to that, I called for volunteers to speak up in the public interest. Suddenly you're issuing one-sided complaints and inventing new IETF rules to retroactively disenfranchise opponents.

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@neverpanic@chaos.social @katzenmann@c3d2.social You're pointing to one-sided statements claiming, e.g., that solo-PQ endorsement will result solely in NSA usage, and that the first quantum attacks will instantly remove the value of ECC. No response when I challenged those errors. My chart https://blog.cr.yp.to/20260221-structure.html instead summarizes what _both_ sides say. It links to statements from both sides, so readers can check. I keep updating it for new claims. If anyone ever points out any mistakes then I'll fix that.

blog.cr.yp.to

1

5

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@KoosPol @kbr @edwintorok @filippo There's actually already terminology that's more accessible and less confusing: "double encryption" and "double signatures" are safer than "single encryption" and "single signatures". People tend to say "hybrid is safer than non-hybrid" since that's more concise, or "ECC+PQ is safer than PQ" since the usual situation is that we're adding a PQ layer (trying to protect against quantum attacks) and keeping an existing ECC layer (to limit damage from PQ failures).

2

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@huitema@social.secret-wg.org @paulehoffman@infosec.exchange @rsalz@ioc.exchange 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.

blog.cr.yp.to

2

38

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@multisn8 Typical readers will understand "safety blanket" here as having the second meaning from https://dictionary.cambridge.org/us/dictionary/english/safety-blanket "something familiar that makes you feel safe or confident". (The dictionary also lists as "UK" another meaning, namely "a type of cover made of a material that does not burn very easily, that you throw over flames to put them out or stop them from spreading".)

dictionary.cambridge.org

safety blanket

1. a type of cover made of a material that does not burn very easily, that you…

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@letoams @huitema @pedromj @paulehoffman @rsalz The basic dividing line is very simple: I endorse various _good_ things. I oppose endorsement of various _bad_ things. I'm not the one here issuing a confusing mixture of (1) acknowledging "strong consensus that pure PQ should not be recommended at this time", (2) claiming that it's good to issue RFCs on "pure" (non-hybrid) PQ, and (3) claiming that such RFCs wouldn't be endorsement despite prominently claiming "consensus of the IETF community".

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@huitema@social.secret-wg.org @paulehoffman@infosec.exchange @rsalz@ioc.exchange 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.

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@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.

1

2

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@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.

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@huitema @pedromj @paulehoffman @rsalz All WG-issued RFCs state that they represent "the consensus of the IETF community". The important effect of issuing an RFC, as opposed to a spec just sitting around somewhere, is IETF endorsement. This matters because endorsement often triggers usage. What happened for the non-hybrid-ML-KEM-in-TLS spec is a bunch of people (the majority of people who spoke up!) objecting to an RFC, most importantly because usage would violate common-sense security rules.

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@huitema@social.secret-wg.org @paulehoffman@infosec.exchange @rsalz@ioc.exchange 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.

0

29

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to on defcon.social

@letoams@defcon.social Let me get this straight. Your argument for ignoring IETF rules and disenfranchising a bunch of people is that you claim that you heard that some person you're unable to name was misled and regrets an earlier vote? Is this like your imaginary friend telling you that solo PQ is important for "high-frequency trading"? https://archive.cr.yp.to/2026-02-21/18:04:50/g3QdEISLDFLsAFawzKSvmOCazLoSXkdd8Dy6urqOqvY/https/mailarchive.ietf.org/arch/msg/tls/YZT5IzoumhTt3C53lQR2WOZNvBU/

archive.cr.yp.to

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@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.

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@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.

blog.cr.yp.to

0

9

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@rsalz@ioc.exchange @letoams@defcon.social From IETF's working-group rules: "There is no formal membership in the IETF. Participation is open to all. This participation may be by on-line contribution, attendance at face-to-face sessions, or both. Anyone from the Internet community who has the time and interest is urged to participate in IETF meetings and any of its on-line working group discussions." https://web.archive.org/web/20251217213247/https://www.rfc-editor.org/rfc/rfc2418.html Re "minority": In a democratic world, this NSA-driven proposal would lose by 8 billion votes.

web.archive.org

RFC 2418: IETF Working Group Guidelines and Procedures

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@neverpanic@chaos.social @katzenmann@c3d2.social Every reader can see that the first link has a "not impacting anyone else" claim as I said, that the second link has an "only benefit is protection if ML-DSA is classically broken before the CRQCs come" claim as I said, that your accusations are unfounded, and that you're throwing a temper tantrum rather than addressing the content.

0

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@rsalz@ioc.exchange @letoams@defcon.social "There is no formal membership in the IETF. Participation is open to all. This participation may be by on-line contribution, attendance at face-to-face sessions, or both. Anyone from the Internet community who has the time and interest is urged to participate in IETF meetings and any of its on-line working group discussions." That's from IETF's official working-group procedures, RFC 2418.

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@rsalz Example of a quote from an NSA employee on an IETF mailing list in 2025: "As the CNSA 2.0 profiles should make clear, we are looking for products that support /standalone/ ML-DSA-87 and /standalone/ ML-KEM-1024. If there is one vendor that produces one product that complies, then that is the product that goes on the compliance list and is approved for use. Our interactions with vendors suggests that this won't be a problem in most cases." See https://blog.cr.yp.to/20251004-weakened.html#tls for further quotes.

blog.cr.yp.to

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 4mo ago

Replying to

@NohatCoder@mastodon.gamedev.place Yeah, it's very low cost to just use 256-bit secrets everywhere. I commented on this in more detail in https://cr.yp.to/papers.html#bruteforce

cr.yp.to

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@huitema @pedromj @paulehoffman @rsalz Now you're just making things up. https://blog.cr.yp.to/20251004-weakened.html gives concrete examples, such as SIKE and KyberSlash, to illustrate the PQ security risks. https://cr.yp.to/papers.html#qrcsp gives many more examples. Instead of responding to _any_ of these examples, you grossly mischaracterize what I'm saying as "that risk is very high because the promotion efforts are orchestrated by the government". Of course, you don't give a URL.

blog.cr.yp.to

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@huitema @pedromj @paulehoffman @rsalz The core issue is endorsement. It isn't about having a stable reference; having a stable reference doesn't need an RFC. It isn't about interoperability; interoperability doesn't need an RFC. The "control" argument is circular; https://archive.cr.yp.to/2026-04-10/05:38:16/1w0wAgKE9fiKZKunAg8qCyVyWYZ4j-aHgW-0aFDzgcw/https/mailarchive.ietf.org/arch/msg/tls/LqG-gHxgRvVPebE3m28D8VT7dN4/ spells this out in baby steps.

archive.cr.yp.to

0

3

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@letoams@defcon.social @rsalz@ioc.exchange IETF claims that every WG-issued RFC has "consensus of the IETF community". You don't seem to understand what the word "consensus" means.

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@letoams@defcon.social "There is no formal membership in the IETF. Participation is open to all. This participation may be by on-line contribution, attendance at face-to-face sessions, or both. Anyone from the Internet community who has the time and interest is urged to participate in IETF meetings and any of its on-line working group discussions." You're trying to disenfranchise real people by calling them "sockpuppets". You hype a few pseudonymous objections, ignoring pseudonymous _support_ statements.

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@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.

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@huitema@social.secret-wg.org @paulehoffman@infosec.exchange @rsalz@ioc.exchange 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.

blog.cr.yp.to

0

1

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 3mo ago

Replying to

@neverpanic@chaos.social @katzenmann@c3d2.social 1st page you cited (https://web.archive.org/web/20251225222528/https://keymaterial.net/2025/11/27/ml-kem-mythbusting/) includes "if you really think ML-KEM is broken, then yes, the NSA has successfully undermined the IETF in order to make their own systems less secure, while not impacting anyone else". Again, this claims that solo-PQ endorsement will result solely in NSA usage. 2nd page (https://web.archive.org/web/20260511083730/https://words.filippo.io/crqc-timeline/) says "we should go straight to pure ML-DSA-44" and, as I said, claims that the first quantum attacks instantly remove ECC's value.

Key Material

ML-KEM Mythbusting

What is this? There have been some recent concerns about ML-KEM, NIST’s standard for encryption with Post-Quantum Cryptography, related standards of the IETF, and lots of conspiracy theories …

0

3

0

Daniel J. Bernstein @djb@mastodon.cr.yp.to

· 5mo ago

Replying to

@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?

blog.cr.yp.to

0