Constant-Time Programming: Why Crypto Code Can't Branch on Secrets

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 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) | (~mask & b)
Table lookup 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.