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-07-09 19:12:08 GMT

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 GMT

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-07 23:32:35 GMT

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 01:14:32 GMT

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

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

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 GMT

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

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 GMT

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 GMT

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-02 18:51:20 GMT

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 15:07:45 GMT

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

- 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 16:16:50 GMT

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:10:33 GMT

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

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 GMT

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

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

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

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

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

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 GMT

"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 07:53:33 GMT

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 GMT

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 GMT

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

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 GMT

"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-19 13:49:45 GMT

- 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-05-16 13:13:48 GMT

- 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 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:31:29 GMT

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 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-16 16:54:38 GMT

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 GMT

- 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 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-11 01:59:21 GMT

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-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-06 20:41:21 GMT

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

- 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 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-21 19:28:09 GMT

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