Ordinary code is judged on whether it produces the right answer. Cryptographic code is held to a stranger standard: it must produce the right answer in exactly the same amount of time, no matter what the secret data is. Violate that rule and an attacker who can only measure how long your code runs can, given enough samples, recover the key it was protecting. This is why crypto libraries are full of code that looks needlessly convoluted — and why that convolution is the point.
Imagine a function that checks whether a submitted password matches a stored one by comparing them character by character and returning false the instant it finds a mismatch. It's correct. It's also leaking. A comparison that fails on the first character returns faster than one that fails on the tenth. An attacker measuring response times can learn how many leading characters they guessed correctly, turning an exponential brute-force problem into a linear one. The function gives the right answer and still betrays the secret — through time.
This is a timing side channel, and defending against it is the discipline of constant-time programming: writing code whose execution time, memory access pattern, and control flow do not depend on secret values. It's one specific, code-level corner of the broader family of side-channel attacks, and it's the one application developers are most likely to get wrong themselves.
The threat model: an attacker with a stopwatch
The unsettling part of timing attacks is how little the attacker needs. They don't need to read your memory, exploit a buffer overflow, or break the math behind the cipher. They only need to measure something observable — wall-clock response latency over a network, cache behavior on a shared machine, even power draw — and correlate it with secret-dependent work your program does.
Individual measurements are noisy, especially over a network. But statistics defeat noise. In 2003, researchers David Brumley and Dan Boneh demonstrated a practical timing attack that extracted an RSA private key from an OpenSSL-based server over a network connection. The defense — and the reason modern RSA implementations use a technique called blinding — exists precisely because "it's only a few microseconds" is not a safe assumption when an attacker can collect millions of samples.
The core rule: Execution time, branch decisions, and memory access addresses must be independent of secret data. If an attacker measuring any of these can distinguish one secret from another, the secret is leaking — no matter how strong the underlying cipher is.
The three things that leak
Constant-time programming targets three distinct sources of secret-dependent timing variation, and a real implementation has to neutralize all of them.
Secret-dependent branches
Any if statement whose condition depends on a secret can leak, because the two paths take different amounts of time and may prime the CPU's branch predictor differently. The fix is to compute both possibilities and select between them with arithmetic rather than a jump. Instead of "if the bit is set, add X," you compute a mask (all-ones or all-zeros depending on the bit) and AND it with X — the addition always happens, but contributes nothing when the bit is clear.
Secret-dependent memory access
If your code uses a secret value as an index into a table — as naive AES implementations do with S-box lookups — then which memory address you touch depends on the secret. An attacker sharing the same CPU can observe, through the cache, which table entries were accessed, and work backward to the key. Constant-time code either avoids table lookups on secret indices entirely or accesses every entry so the access pattern carries no information. This is why modern CPUs added dedicated AES instructions (AES-NI): they perform the round function in hardware without secret-dependent memory access.
Secret-dependent loop bounds and early exit
The password-comparison example above is this category. A loop that stops early when it finds a difference reveals where the difference is. The constant-time version always examines every byte, accumulating differences into a single value with OR, and only checks that accumulator at the very end. Standard libraries ship vetted versions of this — for example, crypto_memcmp-style functions and language-level helpers like Python's hmac.compare_digest — and you should use them rather than rolling your own equality check on any secret.
A concrete before-and-after
| Leaky pattern | Constant-time replacement |
|---|---|
Return false on first byte mismatch |
OR all byte-differences together; compare the total to zero once at the end |
if secret_bit: result = a else: result = b |
Mask-based select: `result = (mask & a) \ |
Table lookup {% raw %}sbox[secret]
|
Hardware AES instructions, or scan the whole table |
Loop runs secret_length times |
Loop runs a fixed maximum number of times |
Why the compiler is your adversary too
Here's the genuinely hard part: even if you write constant-time source code, an optimizing compiler may quietly undo it. Compilers are designed to make code faster, and a "redundant" full-table scan or a branchless construct that looks like a missed optimization is exactly the kind of thing they rewrite. The C language has no portable notion of "constant time," so there is no standard way to tell the compiler "do not optimize this for timing's sake."
Writing constant-time code in a language that doesn't understand the concept means fighting your own toolchain — and the toolchain doesn't promise to lose.
This is why serious cryptographic code is often written in assembly, generated by specialized tools, or formally verified (projects like HACL* and the assembly in libsodium and BoringSSL exist for this reason). It's also a quiet argument for modern systems languages: ecosystems like Rust's have crates such as subtle that provide constant-time primitives with explicit barriers to discourage the optimizer from collapsing them.
What this means for the software you trust
The practical lesson for anyone evaluating a security product is not that you should audit assembly. It's that cryptography is an implementation discipline, not just a choice of algorithm. "We use AES-256" tells you almost nothing about whether the AES is implemented without timing leaks. Two products can use the identical cipher and have wildly different real-world security depending on whether their developers respected constant-time rules and, crucially, whether they used well-audited libraries instead of writing their own primitives.
That's the rule we follow at Haven, and that anyone building secure software should: don't hand-roll cryptographic primitives. Use vetted, constant-time libraries for the dangerous parts — comparison, key handling, the cipher core — and keep secret-dependent logic out of branches and table indices. The flashy part of cryptography is the math. The part that actually gets broken in the field is almost always the implementation. Constant-time programming is where a surprising amount of that battle is won or lost.
Originally published at havenmessenger.com
Top comments (0)