May 04, 2025·8 min
DJB and Security-by-Construction: qmail to Curve25519
A practical look at Daniel J. Bernstein’s security-by-construction ideas—qmail to Curve25519—and what “simple, verifiable crypto” means in practice.
A practical look at Daniel J. Bernstein’s security-by-construction ideas—qmail to Curve25519—and what “simple, verifiable crypto” means in practice.
Security-by-construction means building a system so that common mistakes are hard to make—and the damage from unavoidable mistakes is limited. Instead of relying on a long checklist (“remember to validate X, sanitize Y, configure Z…”), you design the software so the safest path is also the easiest path.
Think of it like childproof packaging: it doesn’t assume everyone will be perfectly careful; it assumes humans are tired, busy, and sometimes wrong. Good design reduces how much “perfect behavior” you need from developers, operators, and users.
Security problems often hide in complexity: too many features, too many options, too many interactions between components. Every extra knob can create a new failure mode—an unexpected way for the system to break or be misused.
Simplicity helps in two practical ways:
This isn’t about minimalism for its own sake. It’s about keeping the set of behaviors small enough that you can actually understand it, test it, and reason about what happens when something goes wrong.
This post uses Daniel J. Bernstein’s work as a set of concrete examples of security-by-construction: how qmail aimed to reduce failure modes, how constant-time thinking avoids invisible leaks, and how Curve25519/X25519 and NaCl push toward crypto that’s harder to misuse.
What it will not do: provide a full history of cryptography, prove algorithms secure, or claim there’s a single “best” library for every product. And it won’t pretend good primitives solve everything—real systems still fail due to key handling, integration mistakes, and operational gaps.
The goal is simple: show design patterns that make secure outcomes more likely, even when you’re not a cryptography specialist.
Daniel J. Bernstein (often “DJB”) is a mathematician and computer scientist whose work shows up repeatedly in practical security engineering: email systems (qmail), cryptographic primitives and protocols (notably Curve25519/X25519), and libraries that package crypto for real-world use (NaCl).
People cite DJB not because he wrote the only “right” way to do security, but because his projects share a consistent set of engineering instincts that reduce the number of ways things can go wrong.
A recurring theme is smaller, tighter interfaces. If a system exposes fewer entry points and fewer configuration choices, it’s easier to review, easier to test, and harder to accidentally misuse.
Another theme is explicit assumptions. Security failures often come from unspoken expectations—about randomness, timing behavior, error handling, or how keys are stored. DJB’s writing and implementations tend to make the threat model concrete: what is protected, from whom, and under what conditions.
Finally, there’s a bias toward safer defaults and boring correctness. Many designs in this tradition try to eliminate sharp edges that lead to subtle bugs: ambiguous parameters, optional modes, and performance shortcuts that leak information.
This article isn’t a life story or a debate about personalities. It’s an engineering read: what patterns you can observe in qmail, constant-time thinking, Curve25519/X25519, and NaCl, and how those patterns map to building systems that are simpler to verify and less fragile in production.
qmail was built to solve a very unglamorous problem: deliver email reliably while treating the mail server as a high-value target. Mail systems sit on the internet, accept hostile input all day, and touch sensitive data (messages, credentials, routing rules). Historically, one bug in a monolithic mail daemon could mean a full system compromise—or silent message loss that nobody notices until it’s too late.
A defining idea in qmail is to break “mail delivery” into small programs that do one job each: receiving, queueing, local delivery, remote delivery, etc. Each piece has a narrow interface and limited responsibilities.
That separation matters because failures become local:
This is security-by-construction in a practical form: design the system so that “one mistake” is less likely to become “total failure.”
qmail also models habits that translate well beyond email:
The takeaway isn’t “use qmail.” It’s that you can often get big security wins by redesigning around fewer failure modes—before you write more code or add more knobs.
“Attack surface” is the sum of all the places where your system can be poked, prodded, or tricked into doing the wrong thing. A helpful analogy is a house: every door, window, garage opener, spare key, and delivery slot is a potential entry point. You can install better locks, but you also get safer by having fewer entry points in the first place.
Software is the same. Every port you open, file format you accept, admin endpoint you expose, configuration knob you add, and plugin hook you support increases the number of ways things can fail.
A “tight interface” is an API that does less, accepts less variation, and refuses ambiguous input. This often feels restrictive—but it’s easier to secure because there are fewer code paths to audit and fewer surprising interactions.
Consider two designs:
The second design reduces what attackers can manipulate. It also reduces what your team can accidentally misconfigure.
Options multiply testing. If you support 10 toggles, you don’t have 10 behaviors—you have combinations. Many security bugs live in those seams: “this flag disables a check,” “this mode skips validation,” “this legacy setting bypasses rate limits.” Tight interfaces turn “choose-your-own-adventure security” into one well-lit path.
Use this to spot attack surface that grows quietly:
When you can’t shrink the interface, make it strict: validate early, reject unknown fields, and keep “power features” behind separate, clearly scoped endpoints.
“Constant-time” behavior means a computation takes (roughly) the same amount of time regardless of secret values like private keys, nonces, or intermediate bits. The goal isn’t to be fast; it’s to be boring: if an attacker can’t correlate runtime with secrets, they have a much harder time extracting those secrets by observation.
Timing leaks matter because attackers don’t always need to break the math. If they can run the same operation many times (or watch it run on shared hardware), tiny differences—microseconds, nanoseconds, even cache effects—can reveal patterns that accumulate into key recovery.
Even “normal” code can behave differently depending on data:
if (secret_bit) { ... } changes control flow and often runtime.You don’t need to read assembly to get value from an audit:
if statements, array indices, loops with secret-based termination, and “fast path/slow path” logic.Constant-time thinking is less about heroics and more about discipline: design code so secrets can’t steer timing in the first place.
Elliptic-curve key exchange is a way for two devices to create the same shared secret even though they only ever send “public” messages across the network. Each side generates a private value (kept secret) and a corresponding public value (safe to send). After exchanging public values, both sides combine their own private value with the other side’s public value to arrive at an identical shared secret. An eavesdropper sees the public values but can’t feasibly reconstruct the shared secret, so the two parties can then derive encryption keys and talk privately.
Curve25519 is the underlying curve; X25519 is the standardized, “do this specific thing” key-exchange function built on top of it. Their appeal is largely security-by-construction: fewer foot-guns, fewer parameter choices, and fewer ways to accidentally pick an unsafe setting.
They’re also fast across a wide range of hardware, which matters for servers handling many connections and for phones trying to save battery. And the design encourages implementations that are easier to keep constant-time (helping resist timing attacks), which reduces the risk that a clever attacker can extract secrets by measuring tiny performance differences.
X25519 gives you key agreement: it helps two parties derive a shared secret for symmetric encryption.
It does not provide authentication by itself. If you run X25519 without also verifying who you’re talking to (for example, with certificates, signatures, or a pre-shared key), you can still be tricked into securely talking to the wrong party. In other words: X25519 helps prevent eavesdropping, but it doesn’t stop impersonation on its own.
NaCl (the “Networking and Cryptography library”) was built around a simple goal: make it hard for application developers to accidentally assemble insecure cryptography. Instead of offering a buffet of algorithms, modes, padding rules, and configuration knobs, NaCl pushes you toward a small set of high-level operations that are already wired together in safe ways.
NaCl’s APIs are named after what you want to do, not which primitives you want to stitch together.
crypto_box (“box”): public-key authenticated encryption. You give it your private key, the recipient’s public key, a nonce, and a message. You get a ciphertext that (a) hides the message and (b) proves it came from someone who knows the right key.crypto_secretbox (“secretbox”): shared-key authenticated encryption. Same idea, but with a single shared secret key.The key benefit is that you don’t separately choose “encryption mode” and “MAC algorithm” and then hope you combined them correctly. NaCl’s defaults enforce modern, misuse-resistant compositions (encrypt-then-authenticate), so common failure modes—like forgetting integrity checks—are much less likely.
NaCl’s strictness can feel limiting if you need compatibility with legacy protocols, specialized formats, or regulatory-mandated algorithms. You’re trading “I can tune every parameter” for “I can ship something secure without becoming a cryptography expert.”
For many products, that’s exactly the point: constrain the design space so fewer bugs can exist in the first place. If you truly need customization, you can drop to lower-level primitives—but you’re opting back into the sharp edges.
“Secure by default” means the safest, most reasonable option is what you get when you do nothing. If a developer installs a library, copies a quick example, or uses framework defaults, the result should be hard to misuse and hard to accidentally weaken.
Defaults matter because most real systems run with them. Teams move quickly, documentation gets skimmed, and configuration grows organically. If the default is “flexible,” that often translates to “easy to misconfigure.”
Crypto failures aren’t always caused by “bad math.” They’re often caused by picking a dangerous setting because it was available, familiar, or easy.
Common default traps include:
Prefer stacks that make the secure path the easiest path: vetted primitives, conservative parameters, and APIs that don’t ask you to make fragile decisions. If a library forces you to choose between ten algorithms, five modes, and multiple encodings, you’re being asked to do security engineering by configuration.
When you can, choose libraries and designs that:
Security-by-construction is, in part, refusing to turn every decision into a dropdown.
“Verifiable” doesn’t mean “formally proven” in most product teams. It means you can build confidence quickly, repeatedly, and with fewer opportunities to misunderstand what the code is doing.
A codebase becomes more verifiable when:
Every branch, mode, and optional feature multiplies what reviewers must reason about. Simpler interfaces narrow the set of possible states, which improves review quality in two ways:
Keep it boring and repeatable:
This combination won’t replace expert review, but it raises the floor: fewer surprises, faster detection, and code you can actually reason about.
Even if you pick well-regarded primitives like X25519 or a minimal API like NaCl-style “box”/“secretbox,” systems still break in the messy parts: integration, encoding, and operations. Most real-world incidents aren’t “math was wrong,” but “the math was used wrong.”
Key handling mistakes are common: reusing long-term keys where an ephemeral key is expected, storing keys in source control, or mixing up “public key” and “secret key” byte strings because they’re both just arrays.
Nonce misuse is a repeat offender. Many authenticated-encryption schemes require a unique nonce per key. Duplicate a nonce (often via counter resets, multi-process races, or “random enough” assumptions), and you can lose confidentiality or integrity.
Encoding and parsing problems create silent failures: base64 vs hex confusion, dropping leading zeros, inconsistent endianness, or accepting multiple encodings that compare differently. These bugs can turn “verified signature” into “verified something else.”
Error handling can be dangerous in both directions: returning detailed errors that help attackers, or ignoring verification failures and continuing anyway.
Secrets leak through logs, crash reports, analytics, and “debug” endpoints. Keys also end up in backups, VM images, and environment variables shared too broadly. Meanwhile, dependency updates (or lack of them) can strand you on a vulnerable implementation even if the design was sound.
Good primitives don’t automatically produce a secure product. The more choices you expose—modes, paddings, encodings, custom “tweaks”—the more ways teams can accidentally build something brittle. A security-by-construction approach starts by picking an engineering path that reduces decision points.
Use a high-level library (one-shot APIs like “encrypt this message for that recipient”) when:
Compose lower-level primitives (AEADs, hashes, key exchange) only when:
A useful rule: if your design doc contains “we’ll pick the mode later” or “we’ll just be careful with nonces,” you’re already paying for too many knobs.
Ask for concrete answers, not marketing language:
Treat crypto like safety-critical code: keep the API surface small, pin versions, add known-answer tests, and run fuzzing on parsing/serialization. Document what you will not support (algorithms, legacy formats), and build migrations rather than “compatibility switches” that linger forever.
Security-by-construction isn’t a new tool you buy—it’s a set of habits that make whole categories of bugs harder to create. The common thread across DJB-style engineering is: keep things simple enough to reason about, make interfaces tight enough to constrain misuse, write code that behaves the same way even under attack, and choose defaults that fail safe.
If you want a structured checklist for these steps, consider adding an internal “crypto inventory” page alongside your security docs (e.g., /security).
These ideas aren’t limited to crypto libraries—they apply to how you build and ship software. If you’re using a vibe-coding workflow (for example, Koder.ai, where you create web/server/mobile apps via chat), the same principles show up as product constraints: keeping a small number of supported stacks (React on the web, Go + PostgreSQL on the backend, Flutter on mobile), emphasizing planning before generating changes, and making rollback cheap.
In practice, features like planning mode, snapshots and rollback, and source code export help reduce the “blast radius” of mistakes: you can review intent before changes land, revert quickly when something goes wrong, and verify what’s running matches what was generated. That’s the same security-by-construction instinct as qmail’s compartmentalization—applied to modern delivery pipelines.
Security-by-construction is designing software so the safest path is also the easiest path. Instead of relying on people to remember long checklists, you constrain the system so common mistakes are hard to make and inevitable mistakes have limited impact (smaller “blast radius”).
Complexity creates hidden interactions and edge cases that are hard to test and easy to misconfigure.
Practical wins from simplicity include:
A tight interface does less and accepts less variation. It avoids ambiguous inputs and reduces optional modes that create “security by configuration.”
A practical approach is to:
qmail splits mail handling into small programs (receive, queue, deliver, etc.) with narrow responsibilities. This reduces failure modes because:
Constant-time behavior aims to make runtime (and often memory access patterns) independent of secret values. That matters because attackers can sometimes infer secrets by measuring timing, cache effects, or “fast path vs slow path” differences across many trials.
It’s about preventing “invisible leaks,” not just choosing strong algorithms.
Start by identifying what’s secret (private keys, shared secrets, MAC keys, authentication tags), then look for places where secrets influence control flow or memory access.
Red flags to search for:
if branches on secret dataAlso verify your crypto dependency explicitly claims constant-time behavior for the operations you rely on.
X25519 is a specific, standardized key-agreement function built on Curve25519. It’s popular because it reduces foot-guns: fewer parameters to choose, strong performance, and a design that supports constant-time implementations.
It’s best thought of as a safer “default lane” for key exchange—provided you still handle authentication and key management correctly.
No. X25519 provides key agreement (a shared secret) but does not prove who you’re talking to.
To prevent impersonation, pair it with authentication such as:
Without authentication, you can still end up “securely” talking to the wrong party.
NaCl reduces mistakes by offering high-level operations that are already composed safely, instead of exposing a buffet of algorithms and modes.
Two common building blocks:
crypto_box: public-key authenticated encryption (you + recipient keys + nonce → ciphertext)crypto_secretbox: shared-key authenticated encryptionThe practical benefit is avoiding common composition errors (like encrypting without integrity protection).
Good primitives still fail when integration and operations are sloppy. Common pitfalls include:
Mitigations: