DJB's Cryptographic Odyssey: From Code Hero to Standards Gadfly
Early Innovations and the Birth of "Safe" Curves
Daniel J. Bernstein ("DJB") made his name in the late 2000s by upending established cryptographic primitives. In 2006 he unveiled Curve25519, an elliptic curve meant to be faster and safer than NIST's curves, and shortly after introduced complementary algorithms like the ChaCha stream cipher and Poly1305 MAC for authenticated encryption. He even packaged these into a high-level library, NaCl (short for "Networking and Cryptography library"), to promote easy adoption. The community marveled at the boldness — all the primitives in NaCl were DJB's own designs. As one early reviewer noted in 2009, "If it wasn't DJB, you'd think I was crazy to even consider a library that implements all new ciphers" 1. But DJB had a reputation for "fanatical attention to security" coupled with a unique approach 1, so many gave him the benefit of the doubt. His code was fast, his designs had obvious elegance, and he seemed to anticipate pitfalls that had tripped others for years (constant-time arithmetic, simpler formulas, no RNG misuse, etc.). By 2011, Bernstein and collaborators introduced Ed25519, a signature scheme on the same curve, rounding out a suite of "modern" crypto building blocks free from the shadow of the NSA's influence (a selling point not lost on a post-Snowden world).
From Academia to Ubiquity: Widespread Adoption
DJB's creations didn't remain niche toys; they rapidly became the new industry defaults. OpenSSH jumped in early — in 2014 it added Curve25519 ECDH as a key exchange (making it the default when supported) and Ed25519 as a host/user key type 2. OpenSSH also adopted DJB's ChaCha20-Poly1305 cipher suite for fast authenticated encryption 2. In the TLS arena, Google and Cloudflare championed ChaCha20-Poly1305 for HTTPS, and soon RFC 7905 standardized it for TLS 1.2 in 2016. By 2018, TLS 1.3 had been finalized and "recommend[ed] using X25519 for key exchange and Ed25519 for identity verification" 3 — a huge win for the upstart algorithms over legacy P-256 and RSA. Browser vendors and libraries followed suit. Chrome and Firefox implemented X25519 key agreement in their TLS stacks; even many smartcards and secure messaging apps (Signal, WireGuard, etc.) embraced Ed25519 for signatures.
The result? Within a decade of its introduction, Curve25519 went from academic proposal to the dominant public key system in practice. A 2025 Cloudflare report dryly observed that "in 2024 almost all [TLS] traffic is secured with X25519" 4. (Another noted that X25519, first published in 2006, "now secures the majority of Internet connections" 4.) It's hard to overstate how extraordinary this is — cryptographic primitives rarely achieve such rapid, widespread adoption. By the early 2020s, the mythos around DJB's designs had grown so large that some in the community half-jokingly viewed them as infallible. Curve25519 in particular was often touted as the "perfect" curve that sidestepped all the landmines of earlier ECC: no secret array indices, no need for clumsy point validation checks, no patent encumbrances, and performance to spare. The legend of Bernstein's cryptography was at its peak.
No Silver Bullet: Cofactors, Clamping, and Curve Controversies
Inevitably, reality caught up with the legend. As more experts pored over these schemes, subtle complexities emerged. Curve25519's design made novel choices to balance security and convenience — notably, every 32-byte string is a valid public key input, and the scalar multiplication algorithm "handles all input public keys without returning errors" 5. This was intentional: by design, X25519 doesn't require the traditional public-key validation steps that prior ECDH schemes did. Bernstein's implementation "clamps" the private scalar (setting/clearing certain bits) to mitigate small-subgroup issues, and then blindly multiplies by whatever public coordinate it's given. No muss, no fuss — any input yields an output. The IETF's RFC 7748 (2016) describing X25519 did introduce an escape hatch, though: it allows a protocol to abort if the output is the all-zero point (a telltale sign something went wrong). The all-zero case can only happen when the input point is of small order (on Curve25519's twist or a low-order subgroup) 5.
This led to an unexpected debate in cryptographic circles: should protocols explicitly check for the all-zero output and treat it as a failure? Some voices argued yes — if an implementation didn't include this check, it was a latent "vulnerability" waiting to happen 5. After all, classical ECDH protocols always mandated validation to thwart an attacker from sending a weird point and tricking you. Indeed, with Curve25519's structure, an adversary could send a specially crafted public key of small order (the curve has a cofactor of 8, meaning "there can be points of order 1, 2, 4, and 8" 6). If the receiver naively multiplies by such a point, the shared secret ends up in a small subgroup. In the worst case, as one explainer noted, "if Bob sends Alice a public key that is actually a point of small order… [he] can eventually recover Alice's whole private key" by repeating the trick to glean a few bits at a time 6. That sounds terrifying! Why wouldn't we always guard against this?
Well, DJB and colleagues argued, Curve25519 already did guard against it — in its own way. The private-key clamping effectively multiplies the secret scalar by 8 (the cofactor), meaning any small-order element will yield the neutral point (all-zero output) which can be detected or will simply lead to a failed key derivation. In other words, the design trades a full validation step for a one-time tweak to keys. Trevor Perrin summarized the philosophy on the CFRG mailing list: "X25519 was designed to avoid confusion by providing an extremely simple API that could not be misused by omitting a check… This simplicity is a large part of its success." 5 From that point of view, adding an extra check on the output was belt-and-suspenders paranoia — or worse, a potential source of new mistakes. Perrin called the zero-check "a CFRG compromise" made to placate traditionalists, one that "received little discussion or support… and remains controversial" 5.
The clash between these views tempered the aura of perfection surrounding 25519. It turned out this "magic" curve wasn't entirely free of footguns: you still had to know what you were doing in certain edge cases. Was ignoring an all-zero result truly harmless? (If you were doing one-off ephemeral key exchanges like in TLS, probably yes; if you were doing something funky with static keys, maybe not.) Could implementors skip validation safely? (Generally yes, but the debate raged in niche scenarios and academic analyses.) The discussion spilled into blogs and forums — one camp arguing that "blacklisting the known bad public keys" or checking the derived shared secret was prudent 7, and the other camp noting that full validation was overkill since X25519 already is a validated Diffie-Hellman in all the ways that matter.
In the end, the 25519 myth emerged a bit scuffed: still a great curve, still the go-to choice, but not a kryptonite-laced gift from the crypto gods. It had a small cofactor that needed minding in advanced protocols (leading to tweaks like Ristretto for prime-order group abstraction), and it illustrated that even "safe" curves involve trade-offs. To an insider, this was all normal — there's no such thing as a perfect cipher or curve, only well-understood ones. But it's noteworthy that this was one of the few times Bernstein's work faced public technical pushback. The atmosphere remained respectful and technical. Little did we know that far more rancorous fights were on the horizon, once the topic shifted from how to do crypto to who controls crypto's future direction.
Post-Quantum Ambitions and the Rise of Friction
Bernstein was not just resting on the laurels of Curve25519. He has been deeply involved in the post-quantum crypto (PQC) effort for years — in fact, he likes to point out he coined the term "post-quantum cryptography" back in 2003 8. As the threat of quantum computers breaking RSA/ECC became more tangible, DJB pivoted much of his research to PQC algorithms. He co-authored multiple proposals in the NIST PQC competition (e.g. NTRU Prime for encryption, SPHINCS+ for signatures, and others) and continued his pattern of challenging the status quo. True to form, he was an outspoken critic whenever he smelled a hint of old-school bureaucracy or insecurity in the PQC process. In one paper he surveyed the NIST submissions and dryly observed that "48% of the 69 round-1 submissions in 2017… have been broken by now" 8 — a pointed reminder that many post-quantum schemes were (and are) immature and fragile. His takeaway was clear: we'd better hedge our bets when rolling out post-quantum crypto.
That philosophy set the stage for Bernstein's next big crusade: hybrid encryption. By 2016, Google had already run experiments combining classical ECC (X25519) with a post-quantum key exchange, precisely to "belt and suspenders" the handshake security 9. The logic was simple: if the fancy new PQC math gets broken in five years, the classical part (Curve25519) still provides the same protection we've relied on for decades 9. And if quantum computers arrive, the PQC part will resist those, even though the ECC part falls. The chance of both failing at once is astronomically low. This two-key, two-algorithm approach (often called a hybrid KEM or "double encryption") became the common-sense strategy endorsed by many practitioners. Even in 2025, half of Cloudflare's TLS connections were using a post-quantum hybrid handshake — 95% of those with X25519 + Kyber (a lattice-based KEM) 9. It seemed obvious that early post-quantum deployments should add safety nets, not remove them.
Obvious to everyone except, apparently, some powerful voices in government circles. Enter the NSA and GCHQ, stage left. In Bernstein's telling of the saga, the US and UK security agencies had begun quietly pushing standards bodies to adopt pure post-quantum cryptography without any classical crypto in the mix. The ostensible reason? To meet future "Suite 2.0" requirements for national security systems that would only allow the new algorithms. The cynical interpretation? They wanted to deliberately weaken internet security by removing the ECC fallback. By late 2023 and into 2024, the Internet Engineering Task Force (IETF) was considering two proposals for TLS 1.3 key agreement: one to support hybrid ECDH+PQC (e.g. X25519+Kyber), and one for non-hybrid PQC-only handshakes. This might sound like a minor technical detail, but for Bernstein it was a hill to die on.
On the TLS mailing list and related forums, he relentlessly argued that dropping the X25519 "seatbelt" was foolish and dangerous. And not just dangerous — suspicious. He pointed out that no real-world client or server was unable to handle the small extra cost of hybrid handshakes; there was no practical downside to using two algorithms except maybe 64 bytes more network traffic. So why the push for pure post-quantum? Bernstein's answer: because certain large governmental actors want to weaken our crypto under the guise of moving to the future. He didn't mince words. According to him, "surveillance agency NSA and its partner GCHQ are trying to have standards-development organizations endorse weakening ECC+PQ down to just PQ" 9. He drew parallels to the Dual EC scandal, noted that NSA's public "CNSA 2.0" guidelines were ambivalent at best about hybrids, and essentially accused these agencies of leveraging compliance-minded companies to do their bidding.
This is where DJB's long-cultivated insurgent streak burst into full view — and started to chafe many of his peers. The TLS Working Group discussions became combative. Some participants (including employees of Cisco, Cloudflare, Amazon and others) were advocating for optional non-hybrid modes, often citing compliance with government requirements or the desire to keep protocol designs simple. In one exchange, a Cisco crypto engineer justified the need for a pure PQC mode by saying certain experts (unnamed) recommended it, and crucially, "for my employer, that's what they're willing to buy. Hence, Cisco will implement it; I am essentially just asking for code points." 8 Bernstein seized on this as evidence that commercial interests (driven by government influence) were overriding technical merit. To an impartial observer, the Cisco rep's comment might sound pragmatic — if big customers demand a feature, vendors will provide it. But to DJB, this was treason against the open internet. He lambasted the email as an attempt to invoke employer clout on an IETF decision (violating the IETF's cherished "individual contributor" ethos) and as an admission that NSA's preferences were dictating corporate behavior 8. He went so far as to accuse a "cartel" of companies of chasing government money instead of securing users, writing that the "NSA-wants-it argument — pushed by a cartel of companies chasing NSA money — has overwhelmed and suppressed IETF discussion of the engineering considerations" 8.
This rhetoric was beyond the normal frankness of technical debate; it was openly calling out colleagues as pawns of an enemy. If it had come from a newbie, the WG chairs might have simply shown them the door. But this was DJB — a figure who, for better or worse, had contributed enormously to the very protocols under discussion. The situation was tense. By late 2024, after several heated threads, the TLS working group chairs finally stepped in and issued Bernstein a formal public warning for disruptive behavior on the mailing list 10 (an action defined under IETF's RFC 3934 for moderating lists). This is a rare step; it essentially says "shape up or we'll ban you from the list." DJB did not shape up. Instead, true to form, he doubled down and went procedural: he filed an appeal to the IETF's leadership, contesting the warning and alleging all sorts of process fouls.
To give a flavor of these meta-arguments: Bernstein's appeal (December 2024) claimed that the WG chairs were biased or acting improperly by silencing him. He even argued there was a conflict of interest in the normal appeals chain because one of the Security Area Directors at the IETF had previously worked for the NSA. (In his view, that alone was enough to suspect the entire process was tainted by NSA influence.) The IETF's response in January 2025 was unambiguous and not sympathetic. They noted that issuing a warning was fully within the chairs' authority, and that DJB had bypassed the proper chain (he was supposed to first appeal to the Security AD — whom he distrusted due to her NSA resume — before escalating to the full steering group) 10. The IESG found "no credible evidence" to support Bernstein's insinuations of conflict in the process 10. In a particularly tart aside, the IESG remarked that his appeal text included "entirely personal and irrelevant" material that was "inappropriate" 10. In other words, his appeal read more like a conspiracy theorist's rant than a focused argument of process error.
Not content with that outcome, Bernstein continued to litigate the matter. He re-filed and extended his appeals to other bodies (including the IAB), wrote long blog posts rehashing the TLS WG saga in excruciating detail, and even invoked antitrust law — yes, antitrust law — by claiming that companies colluding to favor NSA's preferred standards could put the IETF in legal jeopardy 8. By this point (late 2025), the whole episode had descended into farce. Here was a man who once rewrote the rules of cryptography by sheer brilliance and tenacity, now flooding mailing lists and bureaucratic offices with accusations that border on espionage thriller fiction. The veteran insiders, watching from the peanut gallery, could only shake their heads.
From Code Hero to Standards Gadfly
The contrast could not be more stark. In his younger days, DJB shifted the paradigm of real-world cryptography largely by writing code and math — making something so good that everyone wanted to use it. Curve25519 and friends succeeded on their technical merits and through careful evangelism that never devolved into mudslinging. Bernstein earned influence because implementers trusted his genius (even if reluctantly, as with NaCl's initially radical choices 1) and because he delivered quality. But in the post-quantum chapter of his career, we see influence of a very different kind being attempted: not through deployment and adoption, but through polemics, procedural maneuvers, and personal attacks. The same individual who skillfully out-argued entire NIST teams on elliptic curve safety now finds himself writing appeals about ex-NSA "conflicts of interest" and painting colleagues as a corrupt cabal. It's an almost tragic arc — the veteran cryptographer turned into the embittered gadfly.
To be sure, Bernstein's technical points about hybrid cryptography are not without merit. Many experts agree with the substance: hybrids are prudent, and rushing to rip out time-tested crypto is unwise. But the way he went about it — the accusatory tone, the refusal to compromise or even acknowledge that others might simply have honest differing opinions — squandered much of the goodwill he'd accumulated. There's an unwritten rule among engineers: if you have to keep invoking conspiracies and lawsuits to win an argument, you've probably already lost. It didn't help that even as these debates raged, the world was moving on. NIST standardized Kyber (the very lattice KEM he distrusted) and governments began planning transitions. TLS will almost certainly get a hybrid mode standardized (thanks in part to DJB's push), but it will do so despite his combative involvement, not because of it. In the meantime, the human fallout is that Bernstein has alienated many of the standards folks who were once his natural allies. The TLS working group — which had long welcomed input from academia and mavericks — became so toxic during this fight that multiple participants publicly announced taking a break from it.
In cryptography, as in any field, influence is a strange currency. Daniel Bernstein gained it by giving the community tools that undeniably improved security in practice. Yet in the end, he began to burn through that hard-earned influence by insisting that only he saw the truth about a grand plot against encryption. The veteran posting anonymously in a corner of the internet might wryly observe that we've seen this pattern before: brilliant innovators sometimes drift into intransigence and paranoia when the tide of progress no longer flows their way. It's one thing to earn trust by showing superior solutions; it's another to demand trust by claiming everyone else is compromised.
DJB's odyssey from youthful cryptographer-warrior to embattled standards antagonist is a cautionary tale for our field. It reminds us that technical excellence can conquer the world — up to a point. Beyond that, continued influence requires diplomacy, humility, and a bit of faith in your peers. Bernstein once revolutionized internet crypto by leaps of engineering. But recent years have found him trying to do the same by flurries of emails. The results speak for themselves. The new algorithms in TLS owe much to his past work, but his direct role in shaping their standardization has been minimal — in no small part because his approach drove the discussion into a ditch. In the final analysis, the curve25519 saga and the PQC hybrid wars illustrate a consistent truth: the strongest leverage in cryptography comes from deployed code, not conspiracy theories. DJB's legacy remains monumental, but his late-career battles show how even a legend can "win" every argument and yet gradually lose the room. The code is still running, quietly vindicating his genius; the ranting on mailing lists, meanwhile, will fade into the archives, a footnote to an otherwise stellar career.
Sources
1. NaCl: DJB's new crypto library — rdist
3. Faster TLS 1.3 handshake using optimized X25519 and Ed25519
4. State of the post-quantum Internet in 2025
5. X25519 and zero outputs — curves mailing list
6. What's the Curve25519 clamping all about? — Neil Madden
7. Why not validate Curve25519 public keys could be harmful
8. Appeal — Complaint regarding antitrust violations (Daniel J. Bernstein)
9. cr.yp.to: 2025.10.04: NSA and IETF
10. Response — Appeal regarding threat on the TLS Mailing List (D. J. Bernstein)