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

[email protected]

Profile Code

nprofile1qqsdl37nfthje5264843cgxh2hdl3jhm0w732hmn0j2pu9xcc0qljkspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dshk2yqp

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1mlraxjh09ng4420trssdw4wmlr90k7aaz40hxly5rc2d3s7pl9dqy5dqfw

Show more details

Last Notes

2026-04-18 05:01:02 GMT

"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:04:23 GMT

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-11 06:41:05 GMT

- 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 GMT

- 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 GMT

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-10 23:17:29 GMT

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 GMT

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 GMT

- 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 GMT

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-05 19:49:22 GMT

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-19 15:33:49 GMT

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 GMT

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-10 16:42:03 GMT

- reply

@nprofile…4424 According to @nprofile…7dhr, gcc 15.2 can still give wrong results depending on the optimization level.

2026-02-10 16:28:22 GMT

- reply

@nprofile…4424 I agree that what's triggering this specific issue is how gcc (mis)uses x87 instructions, but I think the main reason for -mfpmath=387 to be enabled is people writing -m32.

2026-02-10 16:23:30 GMT

- reply

@nprofile…zaxj Well, this allowed form of mixing of types is also one part of what's happening in the second example of code triggering this gcc bug.

2026-02-10 16:06:59 GMT

- reply

@nprofile…zaxj Does the void * in the standard interfaces for memcpy etc. look like nonsense? I expect typical C programmers to read it as a hint that the function is at least partially polymorphic (whereas the traditional char * is now more of a hint that the function wants byte arrays or byte strings).
Anyway, this gcc bug looks like it comes from someone simply not understanding that FLD-FST isn't equivalent to a copy. This is compiler confusion about machine-language semantics, not about C types.

2026-02-10 14:33:14 GMT

- reply

@nprofile…zaxj Feel free to change void * to float * in this code and you'll see the same FLD-FST gcc bug appearing. However, the void * is a helpful hint for human readers.

2026-02-10 13:51:18 GMT

More bureaucratic way to display this gcc -O1 -m32 bug: void foo(void *x) { int i; if (isnan(*(float *) x)) memcpy(&i,x,4); printf("%x\n",i); } void bar(void *x) { int i; memcpy(&i,x,4); printf("%x\n",i); } int main() { float x = __builtin_nansf(""); foo(&x); bar(&x); return 0; }

2026-02-05 07:52:34 GMT

One of the OpenSSL disasters announced last week (CVE-2025-15469) is really the fault of OpenSSL's detached-signature interface. With a signed-message/message-recovery interface, the bug would have had no effect on security, and would have been easier to catch. Interfaces matter.

2026-02-02 13:33:42 GMT

Couldn't resist measuring speed of a layer of MSD radix sort (radix 256; should try more) on top of djbsort: https://cr.yp.to/2026/20260202-sort.c Beware that adding this layer removes djbsort's features of being in-place/constant-time/verified. Most libraries are in-place, not CT, not verif.
https://mastodon.cr.yp.to/system/media_attachments/files/116/001/285/904/223/389/original/993d9aad4e20554c.png

2026-01-29 06:50:19 GMT

- reply

@nprofile…fap3 Thanks for the portability report. Let me know if you encounter any packaging issues.

2026-01-28 06:29:25 GMT

- reply

@nprofile…fap3 Typically, yes. I'm also interested in hearing about any changes to compiler/linker flags so that I can try the verification toolchain with those. Third parties should be able to follow https://sorting.cr.yp.to/verif.html#run to verify the compiled library afterwards, but I want to be proactive about finding and fixing any problems.

2026-01-27 11:55:15 GMT

Major new release of djbsort, my library for sorting numeric arrays: https://sorting.cr.yp.to More AVX2 speed, more data types supported (int32, uint32, float32, int64, uint64, float64), many test improvements, easier-to-use packaging, more documentation, multi-library benchmarks.

2026-01-24 16:33:38 GMT

- reply

@nprofile…w5un Should probably be a paper at some point, but my main target right now is getting the software online.

2026-01-24 15:45:03 GMT

Almost done packaging a new release of djbsort; mainly now waiting for some big verification runs to finish. As an example of the new speeds, here's a comparison graph for AMD Zen 3. This is for random inputs, not inputs chosen to slow down the competitors that use quicksort.
https://mastodon.cr.yp.to/system/media_attachments/files/115/950/834/882/038/680/original/e52f75bda6850a09.png

2026-01-18 06:50:30 GMT

Sorting the following input seems to reliably trigger a buffer overflow in vxsort with clang-{18,19}: https://cr.yp.to/2026/20260118-vxsort.sh Outside asan, the same pattern for varying N sometimes triggers an assertion in vxsort and sometimes produces incorrectly sorted results. @nprofile…spca

2025-12-30 12:56:06 GMT

Haven't really been satisfied with the tools I've tried over the years for comparing PDFs (for example, comparing paper-v6.pdf to paper-v7.pdf), so wrote yet another tool: https://cr.yp.to/2025/pdfspotthediff-20251230 Internally, this is a short Python script that calls pymupdf for the real work.

2025-12-28 12:28:11 GMT

Some security features of the https://lib25519.cr.yp.to/ed25519-cli.html keypair/sign/open CLI (ed25519 package in Debian etc.): if verification fails, message opening guarantees error code _and_ empty message; no parsing-dependent add-ons (headers, comments, base64, etc.); works with NOFILE=0.

2025-12-15 13:36:50 GMT

Posted a fast demo https://cr.yp.to/2025/20251215-recover-isc-key.c for CVE-2025-40780, where https://gitlab.isc.org/isc-projects/bind9/-/commit/6876753c7ccd67d445a6a2341219fe79cff6c77f says it was "discovered during research for an upcoming academic paper" that BIND's ID RNG is predictable. The attack is easy; what's interesting is why such a poor RNG ended up deployed.

2025-11-25 14:47:59 GMT

One day left in "last call" for this NSA-driven TLS document. More and more people are showing up to object. Proponents deploy their top argument: "NSA is buying this for their own use; they trust it!" Here's where I spelled out the flaw in the argument: https://blog.cr.yp.to/20251004-weakened.html#dogfood

2025-11-23 18:18:33 GMT

Posted three new updates on NSA and IETF! Part 2: corruption continues. https://blog.cr.yp.to/20251123-corruption.html Part 3: dodging the issues at hand. https://blog.cr.yp.to/20251123-dodging.html Part 4: An example of censored dissent. https://blog.cr.yp.to/20251123-scope.html Part 1 was last month: https://blog.cr.yp.to/20251004-weakened.html

2025-10-21 18:14:48 GMT

Impressed with the level of compatibility of the new memory-safe C/C++ compiler Fil-C (filcc, fil++; https://fil-c.org/) based on clang. Many libraries and applications that I've tried work under Fil-C without changes, and the exceptions haven't been hard to get working.

2025-10-21 17:19:12 GMT

- reply

@nprofile…eqlq Among key-value stores, cdb generally provides the best read time and the best database-rewrite time. The tradeoff is that it doesn't provide updates of individual items except via rewriting the database. Applications typically store updates in a slower database and then periodically transfer everything from the slower database to cdb for fast access.

2025-10-21 14:38:00 GMT

Released cdb-20251021 (https://cdb.cr.yp.to). Biggest improvement, matching some of the cdb spinoffs out there: support for cdb64 format to go beyond 4GB. I should also note another interesting >4GB cdb spinoff: Spotify's Sparkey (https://github.com/spotify/sparkey), also used by airbnb.

2025-10-08 19:50:49 GMT

- reply

@nprofile…m74z The part where I was running through an audit during my talk is a theorem verified by HOL Light saying that each function computes the desired results (and, at least end to end, doesn't change memory outside the specified regions). Separately from that, there's a script that checks that instructions are within the subset that CPU designers say are constant-time. Looks like there's progress towards also proving constant-time properties in HOL Light, but that's not complete yet.

2025-10-07 20:36:46 GMT

Posted slides for my talk "Fast, constant-time, correct: pick three": https://cr.yp.to/talks/2025.10.07/slides-djb-20251007-pickthree-4x3.pdf Presented remotely today at the OpenSSL Conference Prague 2025.

2025-10-06 00:48:20 GMT

New blog post "MODPOD: The collapse of IETF's protections for dissent." https://blog.cr.yp.to/20251005-modpod.html #ietf #objections #censorship #hybrids --- Note that there's useful action here that you can take by "Tuesday October 7 (in any time zone)".

2025-10-05 10:12:40 GMT

- reply

@nprofile…9dqp "Creation or adoption of a draft by a working group -- as well as substantive changes to the document -- need to represent working group rough consensus." Of course people in IETF claim that they aren't bound by this, and aren't bound by "IETF activities are conducted with extreme transparency, in public forums. Decision-making requires achieving broad consensus via these public processes". What's interesting is why the false advertising is there in the first place.

2025-10-04 21:36:32 GMT

New blog post "NSA and IETF: Can an attacker simply purchase standardization of weakened cryptography?" https://blog.cr.yp.to/20251004-weakened.html #pqcrypto #hybrids #nsa #ietf #antitrust

2025-09-30 15:33:36 GMT

New blog post "Surreptitious surveillance: On the importance of not being seen." https://blog.cr.yp.to/20250930-stealth.html #marketing #stealth #nsa

2025-09-06 12:10:55 GMT

Someone now shows up in MODPOD and files cogent objections to the draft: https://web.archive.org/web/20250906115220/https://mailarchive.ietf.org/arch/msg/mod-discuss/wWoWI3kLFUjKK2tYUMkEhSL46LQ/ Draft author's reply includes claims such as "RFC 3934 does not permit appeals": https://web.archive.org/web/20250906115209/https://mailarchive.ietf.org/arch/msg/mod-discuss/4prRWM8MHJOYHcSt9VeGhUtAftY/ WTF? Of course RFC 3934 explicitly authorizes appeals: https://web.archive.org/web/20250729112512/https://www.rfc-editor.org/rfc/rfc3934

2025-09-03 06:10:42 GMT

MODPOD officials are now retaliating. The censorship technology is already there; the MODPOD WG chairs have configured it so that my messages to their "open" mailing list are delayed and redirected to them to maybe delete. Messages from MODPOD proponents are posted immediately.

2025-09-03 05:53:34 GMT

- reply

@nprofile…7gap The MODPOD spec grants broad powers to censors, so every appeal that IESG politically approves of will end up with IESG saying "This action was within the censor's powers". Even if some of the censorship ends up being reversed on appeal, that won't magically undo the damage done by the censorship: it's too slow, and it doesn't change the fact that authorizing bans of dissenters based on the content of their postings will terrorize most dissenters into staying silent.

2025-09-03 05:43:25 GMT

- reply

@nprofile…7gap A real appeals process (e.g., https://share.ansi.org/Shared%20Documents/About%20ANSI/Current_Versions_Proc_Docs_for_Website/ER_Pro_current.pdf Section 2.8) has procedural protections: impartiality, full responses, due process, etc. IESG isn't impartial, and here are the _complete_ rules for its appeals process: "The IESG shall then review the situation and attempt to resolve it in a manner of its own choosing." IETF LLC officials have admitted the "dearth of upheld appeals"; they then pretend this shows that IETF's procedures do a great job of fixing problems before appeal.

2025-09-02 10:31:13 GMT

In theory IETF allows anyone to participate. If you look at the MODPOD spec and have thoughts about it then you can simply speak up on the mailing list before the 8th: https://datatracker.ietf.org/wg/modpod/about/ The people who lied about MODPOD's goal will also try to discount your input, of course.

2025-09-02 10:13:54 GMT

Is IETF censor looking at a case of dissent _without_ requests for evidence? Censor simply declares it to be "uncivil". Or "disruptive": company wants X, dissenter is stopping X. Or "behaviors not listed here" decided ad-hoc by the censor. These quotes are from the MODPOD spec!

2025-09-02 10:05:48 GMT

Tech firms overcomplicate protocols as barriers to entry; avoid antitrust scrutiny by labeling collusion as IETF standardization. Complications-are-needed claims are more and more often challenged. MODPOD authorizes IETF bans to retaliate for "incessant requests for evidence".

2025-09-02 09:33:28 GMT

Here's the MODPOD spec that, when the cover stories and marketing are stripped away, creates five new IETF censorship positions with "the widest possible freedom of action" to suppress any objections they don't like, even banning people from IETF: https://web.archive.org/web/20250902092254/https://datatracker.ietf.org/doc/draft-ietf-modpod-group-processes/

2025-07-28 13:02:49 GMT

A standard argument to use medians is that averages aren't robust against occasional corrupted measurements. Unfortunately, for some distributions, medians aren't even stable, let alone robust. Interquartile means fix that. Analogous fix for quartiles: https://cr.yp.to/papers.html#rsrst

2025-07-17 18:10:32 GMT

Quantum computers haven't factored anything interesting yet. Peter Gutmann concludes that quantum computing is "not getting anywhere" (https://www.theregister.com/2025/07/17/quantum_cryptanalysis_criticism/). The same logic 70 years ago would have said we'll never land on the Moon. More on this analogy: https://blog.cr.yp.to/20250118-flight.html#moon

2025-05-18 15:30:30 GMT

Interesting new overview "What we in the open world are messing up in trying to compete with big tech" from Bert Hubert: https://berthub.eu/articles/posts/what-the-open-world-must-do-better/ Hmmm, not sure about this part: "Your post-quantum crypto library does not need to be available as a service or have an attractive UI."

2025-05-07 16:43:12 GMT

libmceliece-20250507 available: https://lib.mceliece.org Uses latest cryptoint. Code is now ready for -Wc++-compat and -Wshadow. The checkinsns script to check instruction-set usage now supports many more platforms. The checknamespace script now works on FreeBSD and even Solaris.

2025-05-05 15:51:02 GMT

Posted new paper "Symbolically executing emulators": https://cr.yp.to/papers.html#symexemu The tool is more efficient than Inception inside the Matrix, really! The paper also reviews how symbolic execution supports easy-to-use equivalence verification.

2025-05-05 09:01:34 GMT

Eurocrypt talk today says that in 2^529 operations it can tell that a mceliece348864 public key is a public key. IACR has been refusing to post the Classic McEliece Team response https://classic.mceliece.org/mceliece-529-20250417.pdf on eprint (IACR's preprint archive for "any author" to post crypto research).

2025-04-25 08:33:37 GMT

- reply

@nprofile…j5lu @nprofile…wrw6 Even if that patch were upstreamed and also in gcc and widespread by now, it wouldn't deal with the core issue of stopping compilers from introducing bool: it's only looking at the use of bool for selections.

2025-04-24 20:30:13 GMT

Happy to announce my new paper "The cryptoint library": https://cr.yp.to/papers.html#cryptoint Constant-time code is the main way that we avoid leaking secrets to timing attacks. This is a paper on how much progress there has been, what's left to do, and how to do it.

2025-04-24 09:07:22 GMT

The gcc/clang excuse for changing program behavior, often introducing bugs and security holes (see https://www.usenix.org/system/files/usenixsecurity23-xu-jianhao.pdf), is performance. But a new paper https://web.ist.utl.pt/nuno.lopes/pubs/ub-pldi25.pdf modifies clang to eliminate most (all?) such changes, and finds negligible effect on benchmarks.

2025-04-24 08:39:26 GMT

IACR has now passed two weeks of violating their announced "any author" policy by refusing to put https://classic.mceliece.org/mceliece-529-20250417.pdf on eprint. The title might sound wonky, but this is getting at the heart of a major risk-analysis dispute covered in my new https://blog.cr.yp.to/20250423-mceliece.html blog post.

2025-04-23 23:16:30 GMT

New blog post "McEliece standardization: Looking at what's happening, and analyzing rationales." https://blog.cr.yp.to/20250423-mceliece.html #nist #iso #deployment #performance #security

2025-04-19 15:24:04 GMT

Senior eprint censor Joppe Bos says it's "defamatory" and "cyber libel" to say that he bears responsibility for eprint not posting https://classic.mceliece.org/mceliece-529-20250417.pdf yet. Not only does he in fact bear responsibility, but also his own email, cc'ing me, continues to argue for this censorship.

2025-04-18 13:31:56 GMT

I've put up a page "NSA-NIST-PQC FOIA highlights": https://nist.pqcrypto.org/foia/highlights.html This is a short page presenting some selected examples of information revealed so far by my ongoing lawsuits. Full details and documents are in my comprehensive tracking page: https://nist.pqcrypto.org/foia/index.html

2025-04-17 11:36:15 GMT

For McEliece, when a new paper says one can see that your public key is a public key in only 2^529 operations, the reaction is: Wow, best-paper award! For Kyber, when a new paper says an attack recovers secret keys faster than breaking AES-128, the reaction is: Yeah, it's Monday.

2025-04-17 11:24:14 GMT

A new document is online from the Classic McEliece Team: "Notes on a recent claim that a mceliece348864 distinguisher uses only 2^529 operations" https://classic.mceliece.org/mceliece-529-20250417.pdf (This is an analysis of the impact of the "syzygy distinguisher" paper. Standard attacks take ~2^150 bitops.)

2025-04-07 12:51:46 GMT

- reply

@nprofile…j5lu Should work on Alpine with --no-tryifunc. The compilation also tries to auto-detect whether this is necessary, but the auto-detection can fail with clang.

2025-04-07 10:45:08 GMT

Happy to announce the newest crypto microlibrary: lib1305 (https://lib1305.cr.yp.to) has fast code from Kaushik Nath for Poly1305 on Intel/AMD CPUs; e.g. 0.8 cycles/byte on Skylake and Zen 2, twice as fast as the S&P 2024 paper. Also includes automatic fallback to portable code.

2025-03-27 10:21:44 GMT

Posted video for a talk "The McEliece cryptosystem" that I gave (online) a few days ago: https://cr.yp.to/talks.html#2025.03.24 Covers high-level advantages and the mathematics. Live talk was for non-native English speakers; native speakers should be able to handle 2x playback speed in Chrome.

2025-03-25 17:49:37 GMT

One of the Classic McEliece security features: IND-CCA2 security (which is what applications use) in the QROM follows tightly from OW-CPA (one-wayness) for the original McEliece system. No need for "decisional" or "indistinguishability" assumptions. See https://classic.mceliece.org/mceliece-security-20221023.pdf.

2024-12-27 18:45:27 GMT

- reply

@nprofile…uy6d @nprofile…jcyt Thanks for trying it out! There's a "Compatibility" channel on https://zulip.pqconnect.net for "What works; what doesn't work yet; workarounds". If you post a description there of what you typed to set up your test, what you expected to see, and what you saw instead, then presumably we'll be able to get things working.

2024-12-27 15:07:56 GMT

- reply

@nprofile…uy6d @nprofile…jcyt The software automatically avoids address conflicts. It also has an option to configure the local-network choice (e.g., pqconnect -a 192.168.15.1 -m 24) for sysadmins who prefer full control. NAT doesn't meet some conceptions of beauty in network design, but it's useful for privacy, and it's how billions of people use the Internet.

2024-12-27 13:27:33 GMT

Pleased to announce PQConnect: https://www.pqconnect.net Easy-to-install software for your Linux box (more OSes coming later) to protect network applications against future quantum computers. Paper will appear at NDSS 2025. Joint work with @nprofile…jcyt, Jonathan Levin, Bo-Yin Yang.

2024-04-24 22:50:49 GMT

Is your .tex file using typical Computer Modern fonts, \mathbb from amsfonts/amssymb, and boldface for definitions, section titles, etc.? Are you annoyed at \boldmath not affecting \mathbb? Solution: https://cr.yp.to/2024/20240424-bfbb/bfbb.pdf https://cr.yp.to/2024/20240424-bfbb/bfbb.py https://cr.yp.to/2024/20240424-bfbb/bfbb.tex

2024-01-02 17:13:05 GMT

New blog post "Double encryption: Analyzing the NSA/GCHQ arguments against hybrids." https://blog.cr.yp.to/20240102-hybrid.html https://blog-cr-yp-to.viacache.net/20240102-hybrid.html #nsa #quantification #risks #complexity #costs