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

atlas.nostr.land

relay.damus.io

nos.lol

Author Public Key

npub1mlraxjh09ng4420trssdw4wmlr90k7aaz40hxly5rc2d3s7pl9dqy5dqfw

Show more details

Last Notes

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-10 16:28:22 UTC

- 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 13:51:18 UTC

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 UTC

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-01-28 06:29:25 UTC

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

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 UTC

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

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 UTC

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 UTC

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-11-23 18:18:33 UTC

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 UTC

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 UTC

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

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 UTC

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

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 UTC

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-04 21:36:32 UTC

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 UTC

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

2025-07-28 13:02:49 UTC

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 UTC

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 UTC

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 UTC

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-04-07 12:51:46 UTC

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

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.