Daniel J. Bernstein

Designing cryptography (deployed now: X25519, Ed25519, ChaCha20, sntrup, Classic McEliece) to proactively reduce risks. Coined phrase "post-quantum" in 2003.

Public Key

npub1mlraxjh09ng4420trssdw4wmlr90k7aaz40hxly5rc2d3s7pl9dqy5dqfw

NIP-05 Address

djb@mastodon-cr-yp-to.mostr.pub

Profile Code

nprofile1qqsdl37nfthje5264843cgxh2hdl3jhm0w732hmn0j2pu9xcc0qljkspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dshk2yqp

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1mlraxjh09ng4420trssdw4wmlr90k7aaz40hxly5rc2d3s7pl9dqy5dqfw

Show more details

Last Notes

2026-10-26 13:09:58 UTC

A new paper https://eprint.iacr.org/2026/2622 says that square-matrix-multiplication exponents below 9/4 would also reduce the exponent of lattice sieving. If that's correct, can it be generalized to use non-square matrix mult? "Rectangular" matrix mult is faster than square matrix mult.

2026-10-24 09:13:24 UTC

There's a survey by Neale Pickett from January of tools to convert git repos to static HTML: https://woozle.org/blog/2026/01-30-stagit/ I'm intrigued by the gitpages approach of showing the current files (rendering md etc.) while requiring cloning to see the history; is that too minimal?

2026-10-15 12:29:03 UTC

Posted slides for my talk "Getting a subroutine right: a case study" today: https://cr.yp.to/talks.html#2026.10.15 The case study I picked for the talk is integer sorting. The broader point is the multifaceted engineering benefit of limiting data flow from inputs to branches and array indices.

2026-10-12 18:20:43 UTC

Like you, I have a job trying to solve real-world problems. Did you realize how much of our tax money goes to pure mathematicians wandering around inventing and understanding pointless theory stuff like this PDF? https://web.archive.org/web/20031205035441/https://mast.queensu.ca/~kani/papers/numgenl.pdf Oh, oops, wait: https://www.quantamagazine.org/post-quantum-cryptography-scheme-is-cracked-on-a-laptop-20220824/

2026-10-09 20:52:16 UTC

Cryptography and computer security have all these cool attack names like CRIME and Spectre and the Slicer. I found a great name for the attack that I'm currently working on: I call it the Terminator. I've already proven that the algorithm terminates.

2026-10-09 20:43:22 UTC

Gave a talk today https://cr.yp.to/talks/2026.10.09/slides-djb-20261009-lattice-4x3.pdf reviewing the 35, oops, no, 37 lattice-cryptanalysis papers that appeared on eprint in the past 365 days. I decided to focus on cryptanalysis of conventional lattice problems; didn't include, e.g., the papers on HAWK.

2026-08-15 06:22:19 UTC

Looks like Aparne Gupte, Seyoon Ragavan, and Mark Zhandry have a computer-checked proof that Simon's DCP algorithm has cost/probability ratio _at least_ 2^(n/9): https://github.com/sragavan99/lean-ePrint-2026-1591-refutation For comparison, Regev's approach plus https://eprint.iacr.org/2020/168 seems to be around 2^(2n/9).

2026-08-14 19:19:04 UTC

New blog post: "NSA and IETF, part 9: An update." https://blog.cr.yp.to/20260814-update.html

2026-08-07 12:18:37 UTC

Daniel Apon in https://nist.pqcrypto.org/foia/20250416/Re_%20Suggestion-%20we%20should%20meet%20sometime%20over%20th....pdf re eprint 2021/1093: "they took their shot at Dilithium and only just missed". Funny to watch Chris Peikert now insisting that people would never use such shooting language.

2026-08-07 09:40:54 UTC

- reply

@nprofile…27fc The error I'm commenting upon isn't specific to the bullets metaphor; it would be a mistake in any area of risk management.
I was talking about proactively recognizing and managing risks. The commentator I was replying to was quietly switching to a view that blinds itself to risks by focusing on situations where _in retrospect_ risks turn out _not_ to be realized ("leaves the status quo unchanged"). That switch is the mistake.

2026-08-07 09:12:22 UTC

- reply

@nprofile…rspk It's "Trusted Computing Base". The name is from DoD in the 1980s, although the concept was already used in the Multics project, I think already in the first versions in the 1960s. Often people say "kernel", but that ends up competing with other meanings of "kernel" and doesn't account for, e.g., the security-relevant code in a web browser.

2026-08-07 07:49:29 UTC

I think that for secure software it's more useful than ever to measure, minimize, and verify the TCB. State a security goal (e.g. "my screen will show 'From: Alice' only for messages from Alice"); restructure software with a tiny nucleus enforcing this goal against all other LOC.

2026-08-07 05:59:49 UTC

Saving a screenshot of this one for the next time I give a talk about cryptographic risk management.
https://mastodon.cr.yp.to/system/media_attachments/files/117/052/682/610/214/982/original/2b8dca3f3bf9d019.png

2026-08-06 08:39:17 UTC

- reply

@nprofile…u3x7 We want proofs to be completed and published, so we should assign credit to the first to publish a complete proof. We also want comprehensible exposition (e.g., shorter proofs), so we should also assign credit for that. The weights naturally adjust depending on difficulty.

2026-08-06 07:29:31 UTC

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.

2026-08-03 18:27:40 UTC

Assuming the poly hierarchy doesn't collapse: NP-completeness results for approx-CVP can't cross the wall in 2005 Aharonov-Regev (https://web.archive.org/web/20150905161543/https://cims.nyu.edu/~regev/papers/cvpconp.pdf); FrodoKEM's approx-CVP problem is on the other side of that wall and will never be supported by an NP-completeness theorem.

2026-08-03 14:53:51 UTC

Cross-posting Twitter+Mastodon results from my latest survey re timing of next exponent drop of isogeny costs after https://eprint.iacr.org/2026/1486: 52+7 predicted 2026-2030, 15+2 predicted 2031-2035, 3+2 predicted 2036-2040, 12+2 predicted 2041 or later or never.

2026-07-30 06:33:55 UTC

SHA-512 hash: 6674cf422ca5356e3a189eca7fb01cc511ee34194ae8f654e58491f4e01a480d095c2057a2316f479976155c752cc03029b9fab3d6ca18cc677403946c04f4e8

2026-07-29 09:19:30 UTC

All versions of HAWK rely on the supposed hardness of examples of "LIP", a problem whose Hamming-weight analog was broken decades ago by Sendrier in almost all cases. Here's my posting four years ago saying that the first "LIP" paper was setting off alarm bells: https://microblog.cr.yp.to/1532377205501661184/index.html#1532382444812308480

2026-07-24 17:02:25 UTC

Now wondering what happens to the claw-finding inside https://eprint.iacr.org/2026/1486 if the internal degrees are allowed to go up to, say, p^(1/5) instead of p^(1/6). Bigger space to work with is nicer for vOW; are there many more collisions, as in subset-sum algorithms from HGJ etc.?

2026-07-22 06:38:47 UTC

Here's a script using our PQCrypto 2008 software to decode the 2^255 size from tii_decoding_challenge in <1 sec on 1 core: https://cr.yp.to/2026/20260722-break-fake-mceliece-sizes-from-tii.sh When TII announced its fake sizes in 2023, I said they had omitted "one of the central defenses in McEliece": https://web.archive.org/web/20260616122115/https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/KzmgtZ3qBME/m/LTiMRSnKAQAJ

2026-07-21 15:13:07 UTC

- reply

@nprofile…w5un I'm not aware of any way that the patent mess for ML-KEM would be triggered specifically by using ECC+ML-KEM. Cloudflare already reports that it sees 70% of its incoming HTTPS connections using ECC+ML-KEM. NSA is waving a ton of money around (see https://blog.cr.yp.to/20251004-weakened.html#tls) for companies to remove ECC from that, first as an option in standards and then in production.

2026-07-21 14:41:38 UTC

Wow. After disenfranchising an unspecified list of people and making claims about the resulting numbers, the IETF TLS WG chairs refused to answer an evidence request from Fabiana Da Pieve, the European Commission's Team Leader Post-Quantum Cryptography: https://web.archive.org/web/20260721143439/https://mailarchive.ietf.org/arch/msg/tls/RLDcZHHbCUZRgmmWbP1j2dDQhAQ/

2026-07-19 13:01:20 UTC

Can we get the IETF TLS WG chairs to help out with the U.S. elections? Allow votes only from pre-existing landowners plus the list of people who the chairs declare have demonstrated enough expertise to vote? Also, make sure to hide that list: https://web.archive.org/web/20260719121145/https://mailarchive.ietf.org/arch/msg/tls/tPe7m_vpmDco43588yVW3JWrb8U/

2026-07-19 12:52:02 UTC

"IETF participation is free and open to all interested individuals. ... Decision-making requires achieving broad consensus via these public processes." (https://web.archive.org/web/20260703153542/https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/). Reality: pay-to-play; NSA casts 6 votes; NSA pays its vendors to vote; chairs throw away _your_ vote.

2026-07-19 12:23:17 UTC

IETF TLS WG chairs have arrogated to themselves the power to disenfranchise all except "pre-existing WG participants" + people who the chairs say have "demonstrated expertise": https://web.archive.org/web/20260719121145/https://mailarchive.ietf.org/arch/msg/tls/tPe7m_vpmDco43588yVW3JWrb8U/ They say: gives 7/10 in favor; "rough consensus". RFC will claim "consensus".

2026-07-17 04:53:31 UTC

- reply

@nprofile…xpux https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys is a graph estimating the number of breakable keys each year for Ed25519, ML-DSA-44, and the Ed25519+ML-DSA-44 combination. That's for signatures but the KEM situation is similarly scary. No idea where you're getting the idea that we aren't worried about the combined risk; we're fighting multiple fires at once here.

2026-07-09 19:12:08 UTC

Wait, I undercounted: NSA cast _six_ votes (Mike Jenkins, Nicholas Gajcowski, William Layton, Morgan Stern, Peter Yee from non-NSA address, Mark Motley from non-NSA address). Looking beyond NSA: DoD's Ann Krieger; DoD lifer Major Mike StJohns. Three GCHQ, two CSE, one partridge.

2026-07-09 16:40:45 UTC

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

2026-07-08 15:12:00 UTC

In my sysadmin hat, I'm puzzled by the "now that you've upgraded your kernel, restore rxrpc etc." parts of some online guides. If system works with, e.g., ptrace_scope=2 and userns_clone=0 and without act_pedit ah4 ah6 algif_aead cifs esp4 esp6 rds rxrpc, why turn those back on?

2026-07-08 13:38:37 UTC

- reply

@nprofile…mnzz I do have DMs enabled, but note that Mastodon doesn't do end-to-end encryption.

2026-07-07 23:32:35 UTC

Retort from Cisco's Richard Barnes to "What if ML-KEM implementations have bugs?" is "What if ECDH implementations have bugs?" (his words). Does he not understand that the point of ECDH+ML-KEM is to face the attacker with the problem of breaking the ECDH key _and_ the ML-KEM key?

2026-07-07 22:56:35 UTC

- reply

@nprofile…tw96 NSA is overtly waving around a lot of money here. I've seen at least 6 DoD votes so far (including 4 from NSA), and there are many more votes from defense contractors (e.g., 4 votes from Cisco). Obviously the TLS WG chairs will be searching desperately for ways to discount the 70 people (so far) who have spoken up in opposition. But maybe their lawyers will explain to them that labeling this as "consensus of the IETF community" is fraud, an antitrust violation, etc. We'll see.

2026-07-07 22:46:03 UTC

- reply

@nprofile…tw96 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!

2026-07-07 12:00:45 UTC

There are continual advances in lattice attacks (see https://blog.cr.yp.to/20260630-risk.html) but I don't think https://eprint.iacr.org/2026/1364 qualifies as one of them: it's basically just standard enumeration (picking a random node in the enumeration tree) after standard sieving as preprocessing.

2026-07-07 01:14:32 UTC

- reply

@nprofile…tw96 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).

2026-07-07 00:34:18 UTC

- reply

@nprofile…tw96 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.

2026-07-06 20:21:34 UTC

New blog post "NSA and IETF, part 8: Fairness." https://blog.cr.yp.to/20260706-fairness.html #pqcrypto #hybrids #nsa #ietf #riskmanagement

2026-07-05 00:16:40 UTC

- reply

@nprofile…5v2w After the WG chairs non-consensually ram a document through the WG, the decision to issue an RFC is made by "IESG", a committee of a dozen or so people where the majority are employees of defense contractors (plus one NSA lifer, Deb Cooley): https://archive.cr.yp.to/2026-06-25/07:39:46/T1FKlGNI1p875U2wBe-_XpptOkDGXM7sKvKMgtJVVO0/https/mailarchive.ietf.org/arch/msg/last-call/MwSAqD8nZGEHCeCefH82zE4AYBE/
IETF's rules force IESG to solicit community input, but not to pay attention to the input. The only real shot to stop this is the "51%" rule: the WG chairs can't proceed with only 51% or less of the WG.

2026-07-04 23:39:34 UTC

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

2026-07-04 09:46:22 UTC

Mike StJohns (not mentioning his DoD employment): "We tend to be able to differentiate between an individual's considered opinion and an unconsidered solicited 'vote' " ... Were the chairs already planning this when in https://archive.cr.yp.to/2026-07-04/09:42:09/4tKUIl5FSz3AqWJndmdORIE1aRf1SV5-8DoiAV-z0A8/https/mailarchive.ietf.org/arch/msg/tls/7l8RfNfdCABM0HYpGrbx-Eja5p0/ they asked voters to say just yes/no?

2026-07-04 09:22:08 UTC

50 people have filed objections now! See https://nsa.2026.action.cr.yp.to to catch up and add your own voice. Some proponents are trying to discourage inputs by claiming disenfranchisement powers, but IETF's "51%" rule (https://web.archive.org/web/20251217213247/https://www.rfc-editor.org/rfc/rfc2418.html) says they _cannot_ proceed with 51% or less.

2026-07-03 15:19:04 UTC

- reply

@nprofile…j5rj To be clear, leaving _some_ sort of ECC in place in case of PQ security failures is more important than the exact choice of ECC. There are good reasons to use X25519/Ed25519 rather than NIST P-256 ECDH/ECDSA (see generally https://cr.yp.to/papers.html#safecurves); P-256+PQ has higher risk than X25519+PQ; but solo PQ has _much_ higher risk.

2026-07-02 19:13:18 UTC

24 June 2026: IETF TLS WG chairs call another vote on allowing ECC to be dropped from ECC+ML-KEM. https://www.cve.org/CVERecord?id=CVE-2026-6330 is dated 25 June 2026. Nothing to see here, that's the last ML-KEM bug ever, just bad timing, move along now.

2026-07-02 18:51:20 UTC

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.

2026-07-02 18:07:03 UTC

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

2026-07-02 17:56:04 UTC

Short new blog post "A standard by any other name: How IETF evades responsibility for its actions." https://blog.cr.yp.to/20260702-standard.html #standards #doublespeak

2026-07-02 16:17:00 UTC

- reply

@nprofile…w7t7 @nprofile…ph0g @nprofile…uvmw @nprofile…c6ly Btw, I've posted a response to the ad-hominem attacks: https://nsa.2026.action.cr.yp.to/guide.html#goldfish

2026-07-02 15:19:36 UTC

Proponents of allowing solo PQ, a weakened version of ECC+PQ, have been posting various talking points recently to the IETF TLS mailing list. I've posted a quick guide to those talking points: https://nsa.2026.action.cr.yp.to/guide.html

2026-07-02 15:07:45 UTC

- reply

@nprofile…zzfr 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/

2026-07-02 06:40:07 UTC

- reply

@nprofile…zzfr "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.

2026-07-01 20:12:01 UTC

- reply

@nprofile…zzfr NSA employees are on record waving around federal-contracting money to pressure NSA's "vendors" to endorse solo PQ: https://blog.cr.yp.to/20251004-weakened.html#tls
NSA and its "vendors" started flooding the room with votes. You didn't complain. I pointed out this was happening and called for volunteers to speak up on the public-interest side: https://nsa.2026.action.cr.yp.to/
30 people have spoken up in opposition by now. You're frantically searching for a way to disenfranchise opponents and declare consensus.

2026-07-01 16:16:50 UTC

30 people have already spoken up against weakening ECC+PQ to solo PQ! We can do this! Spread the word: https://nsa.2026.action.cr.yp.to

2026-07-01 08:23:44 UTC

Publicly, NSA highlighted "the fact that NSA has endorsed the use of DES for the encryption of national security-related information, including selected classified information" (https://web.archive.org/web/20220805195031/https://cryptome.org/nsa-inman-1979.pdf). Secretly, NSA said DES was "weak enough" to break: https://archive.org/details/cold_war_iii-nsa/cold_war_iii-ISCAP/page/n239/mode/2up

2026-07-01 08:10:33 UTC

- reply

@nprofile…5v2w Yeah. I've posted a graph https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys estimating the number of ML-DSA keys that will be broken because of predictable software bugs _even if_ the spec is never broken. (An ML-KEM graph would have much bigger numbers because there are many more ML-KEM keys.) ECC+ML-DSA often saves the day, even with continued reductions in the cost of quantum attacks breaking some ECC keys.
Re Lincoln Labs, look at https://web.archive.org/web/20240326163508/https://www.princeton.edu/~ota/disk1/1995/9501/9501.PDF explaining how and why the government created FFRDCs.

2026-06-30 20:24:00 UTC

New blog post "Understanding lattice risks: Many differences between marketing and reality." https://blog.cr.yp.to/20260630-risk.html #lattices #software #looseness #modules #asymptotics #worstcase

2026-06-30 04:20:46 UTC

- reply

@nprofile…wt2h @nprofile…xxfl
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.

2026-06-29 15:09:57 UTC

- reply

@nprofile…777k One of the basic mistakes made for decades by the Black Chamber -> SIS -> AFSA -> NSA was trying to stay invisible, and then the public learned NSA's name in the context of scandals. Eventually NSA realized that it was better to have a cover story of openly doing something useful for the public, like a mobster running a popular pizza joint. See https://blog.cr.yp.to/20250930-stealth.html for much more about the history.

2026-06-29 14:40:19 UTC

- reply

@nprofile…777k Take a look at https://publish.illinois.edu/science-of-security-lablet/files/2016/08/10062016-Heninger-Slides.pdf for examples of NSA-driven weak options causing security problems for decades, even after people thought they had successfully migrated away from those options.

2026-06-29 14:35:32 UTC

- reply

@nprofile…xxfl 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.

2026-06-29 11:59:47 UTC

- reply

@nprofile…777k 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.

2026-06-29 11:33:48 UTC

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/

2026-06-29 09:35:34 UTC

"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." (source: IETF's official working-group procedures, https://web.archive.org/web/20251217213247/https://www.rfc-editor.org/rfc/rfc2418.html)

2026-06-29 08:16:55 UTC

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.

2026-06-29 07:53:33 UTC

In a democratic world aware of what's going on, NSA's push for a weakened cryptographic standard would lose by approximately eight billion votes. In the real world, NSA and its buddies sneak off into a back room to call a quiet vote. They then advertise the result as "consensus".

2026-06-29 07:40:59 UTC

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/

2026-06-24 14:55:00 UTC

- reply

@nprofile…lv9g Yeah, the second time through the outer loop in this program avoids the SEGV by forcing the right RDPMC index for Intel's fixed-function cycle counter. But the problem shared across all of the loops isn't just that perf is returning index 0; it's that perf is halting the cycle counters on the E-cores.

2026-06-24 12:59:30 UTC

Wondering if anyone sees Linux PERF_COUNT_HW_CPU_CYCLES working as per the documentation on Intel E-cores. https://cr.yp.to/2026/20260624-rdpmc.c fails in various ways under, e.g., kernel 6.12.57. Works fine on P-cores.

2026-06-23 20:57:29 UTC

"Post-" is a really confusing concept that we can just leave out when we don't know what we're talking about, right? Post-modernism = modernism. Post-war Europe = war Europe. Post-meridiem = meridiem/meridies. Post-quantum cryptography = quantum cryptography. Post-truth = truth.

2026-06-23 20:14:24 UTC

- reply

@nprofile…n07e Hmmm. I guess the main argument for a benefit would be that the previous 2035 has been moved up to 2030/2031, but I'm not sure how many people seeing 2035 as an excuse to delay upgrades would see 2030/2031 differently.

2026-06-23 17:30:05 UTC

One interesting aspect of https://web.archive.org/web/20260622222335/https://www.whitehouse.gov/presidential-actions/2026/06/securing-the-nation-against-advanced-cryptographic-attacks/ is the demand that federal contractors (starting mid-2027) label "the use of non-FIPS approved algorithms" as a "vulnerability". The 1990s version of this would be telling contractors to label RSA above 512 as a "vulnerability".

2026-06-19 14:09:07 UTC

New blog post "EuroQCI feedback: A simple idea for improving Europe's investments in data security." https://blog.cr.yp.to/20260619-euroqci.html This covers my reply to a European Commission survey that still seems to be open; maybe you have thoughts on it too. #qkd #quantumcrypto #euroqci #pqcrypto

2026-06-19 13:49:45 UTC

- reply

@nprofile…n7wm Hmmm. Are you sure you'll be doing that when the first quantum attacks happen (my median estimate is 2029), as opposed to when the first public demos of quantum attacks happen (my median estimate is 2032)? See https://cr.yp.to/talks/2023.06.15/slides-djb-20230615-pqrisk-4x3.pdf#page.10 regarding "Two common mistakes analyzing this risk", the first mistake being "assuming attackers aren’t ahead of us".

2026-06-14 12:42:56 UTC

lib25519-20260614 released: https://lib25519.cr.yp.to https://lib25519-cr-yp-to.viacache.net Many new and improved ARM implementations from Kaushik Nath. Improved integration of verified code from s2n-bignum. Ported to more environments. CPUID tests and compiler lines are now auto-generated.

2026-06-12 09:26:22 UTC

"There was some excitement and confusion about the cryptanalysis of the McEliece public-key cryptosystem a few years ago. Korzhik and Turkin, announced that they had broken the cryptosystem. ... However, the demonstration was only a toy" (quote from 1997: https://web.archive.org/web/20060129192743/https://www.anagram.com/berson/mceliece.pdf)

2026-06-01 21:56:53 UTC

Posted new paper "Exploiting ML-DSA bugs" and demo scripts: https://cr.yp.to/papers.html#mldsa The current panic to roll out new ML-DSA code in place of ECC signatures will give away tons of keys to attackers through the predictable flood of efficiently exploitable software vulnerabilities.

2026-05-16 13:13:48 UTC

- reply

@nprofile…26t9 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.

2026-04-18 05:01:02 UTC

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

2026-04-18 04:31:29 UTC

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 deployments 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"?

2026-04-18 04:04:23 UTC

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%. https://mastodon.cr.yp.to/@djb/116382470987007356 https://x.com/hashbreaker/status/2042712462487585022

2026-04-16 16:54:38 UTC

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.

2026-04-11 20:12:50 UTC

- reply

@nprofile…23h7 @nprofile…ph0g Here's the obvious, straightforward hybrid ECC+PQ signature system (from, e.g., https://cr.yp.to/talks.html#2016.02.24): to sign, sign with ECC and with PQ; to verify, verify both signatures. This combiner is even fewer lines of code than typical KEM combiners.
Screwups for encryption and for signatures in some non-TLS protocols motivate _slightly_ more complicated approaches that I recommend for key exchange (Chempat) and for signatures (Mothma). TLS could use these but doesn't need to.

2026-04-11 06:41:05 UTC

- reply

@nprofile…lv9g There's certainly a risk-reduction argument for combining more systems, but most combinations will have people complaining: "wait, here's an application that can't afford this". What's nice about the ECC+PQ combination in particular is that its total cost (communication plus computation for both parts) is coming almost entirely from the PQ part. Opponents have been trying to find _any_ examples where PQ is affordable while ECC+PQ isn't, and have been reaching comic levels of failure.

2026-04-11 06:18:20 UTC

- reply

@nprofile…4nyz Well, the problem with _not_ rolling anything out is that then we're not even _trying_ to deal with the quantum risk.
Hybrids (double encryption, double signatures) nicely resolve this tension: we roll out a post-quantum layer to _try_ to protect against quantum computers, while (at very low cost) keeping the existing ECC layer to reduce the damage if the post-quantum layer is broken.

2026-04-11 02:42:46 UTC

Some energy numbers for breaking a post-quantum proposal, SIKEp751: https://eprint.iacr.org/2023/376 reports 11 seconds to break one key on a mass-market Intel Xeon Gold 6248R. That's a 200-watt CPU; maybe 100 watts more for MB, RAM, PS inefficiency; so about $0.0001 electricity per key.

2026-04-11 01:59:21 UTC

Corrected numbers (tnx PLDD): https://arxiv.org/abs/2603.28846 estimates 2^19 qubits, 1/3 hour, to break an ECC key. https://arxiv.org/abs/2304.14344 estimates 6 watts/qubit. 2^20 watt-hours costs $100 in electricity + hardware-building cost. More analysis can change numbers in either direction.

2026-04-11 01:31:46 UTC

- reply

Sigh, have to fix these numbers: the 29 is a stupid typo, should have been 19, and this cascaded into the watt-hour calculation. Thanks to Pierre-Luc Dallaire-Demers for the correction. Will issue revised calculation momentarily.

2026-04-10 23:17:29 UTC

https://arxiv.org/abs/2603.28846 estimates 2^29 qubits running 1/3 hour to break an ECC key. https://arxiv.org/abs/2304.14344 estimates 6 watts per qubit. 2^30 watt-hours costs about 0.1 million USD in electricity + cost of building hardware. More analysis can change numbers in either direction.

2026-04-10 22:23:07 UTC

My 2023 slides for the Federal Reserve TechLab estimated 50% chance by 2029 of secret quantum computer breaking RSA-2048, estimated 50% chance by 2032 of public quantum computer breaking RSA-2048, noted common mistake of ignoring advances in algorithms: https://cr.yp.to/talks/2023.06.15/slides-djb-20230615-pqrisk-4x3.pdf#page.10

2026-04-10 21:10:28 UTC

- reply

@nprofile…rtl5 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.

2026-04-10 20:08:59 UTC

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.

2026-04-06 20:41:21 UTC

- reply

@nprofile…26t9 Well, it's nice to see people being honest that they're chasing money at the expense of security! Sometimes people have even admitted that it's NSA money. NSA is also on record pressuring vendors to support non-hybrids.
Unfortunately, the money sometimes also pressures people into fantasizing technological motivations (e.g., claiming that the spec helps high-frequency trading) and then not responding to objections. Neutral chairs would have said "Let's resolve this".

2026-04-05 20:56:46 UTC

- reply

@nprofile…4424 Consensus is required, certainly, but it's also impressive to see this spec not even managing to achieve majority support. A year ago the "security area director" was putting up postings claiming support for this spec from (1) everybody but me, (2) the "vast majority", and (3) the "overwhelming majority". The chairs today aren't claiming consensus but still haven't admitted how much opposition there is; they're acting as if there were merely some editorial objections.

2026-04-05 19:49:22 UTC

New blog post "NSA and IETF, part 7: Counting votes." https://blog.cr.yp.to/20260405-votes.html Turns out to be 22 votes against, 21 votes for: not even a majority in favor, never mind consensus. IETF management is throwing the votes away, insisting on a replay, and trying to silence opponents.

2026-02-21 19:28:09 UTC

Another new blog post in my NSA-and-IETF series: "The structure of the debate." https://blog.cr.yp.to/20260221-structure.html This is intended to be an accessible starting point for catching up on what's going on: it's a chart tracking the claimed pros and cons of the NSA-driven proposal on the table.

2026-02-19 18:45:38 UTC

https://eprint.iacr.org/2026/279 claims to chop another few bits out of the Kyber/ML-KEM security level. If the idea works then (given the attack structure) I think that it should straightforwardly combine with the larger security loss from the October paper https://eprint.iacr.org/2025/1910.

2026-02-19 15:33:49 UTC

People with enough confidence in proof-checking software have been happily letting LLMs write proofs. For example, https://github.com/jrh13/hol-light/commit/0a5e935c976d1ff780906c23b8f82939189844e5 has an LLM translation of some proofs from math textbooks into HOL Light, a proof checker that has survived particularly intense audits.

2026-02-19 13:50:59 UTC

New blog post "NSA and IETF, part 5: One battle after another": https://blog.cr.yp.to/20260219-obaa.html Security objections successfully blocked the 2025 push for non-hybrids, but the chairs have now issued another "last call" and will treat anyone who doesn't object by 27 Feb as approving.

2026-02-12 16:07:34 UTC

Video is up (https://video.cr.yp.to/2026/0203/video.html) for my first talk on the new speed records from https://sorting.cr.yp.to for sorting integer arrays. I hadn't recorded the live presentation last week but I did a retake for a general audience. Slides are also up: https://cr.yp.to/talks/2026.02.03/slides-djb-20260203-sorting-4x3.pdf

2026-02-10 13:32:40 UTC

- reply

@nprofile…7dhr @nprofile…rljr It's obvious what the compiler writer was thinking, namely that FLD followed by FST would just be a copy of the original data. It's also clear how this breaks real code. All we're discussing is whether the C standard (foolishly) allows this bug; I don't see how it does.