Crypto · XB Field Notes

TLS ECDHE keeps sessions forward-secret

Wed, 27 Oct 2027 00:00:00 +0000

Forward secrecy limits the damage from later compromise of a long-term authentication key. For a correctly authenticated ephemeral Diffie-Hellman exchange, that key alone does not reveal earlier session secrets. The claim assumes those ephemeral secrets were not also captured. It does not make a compromised endpoint, key log, or recorded plaintext safe.

Two kinds of keys do different jobs

In ECDHE, each side generates an ephemeral private key and sends its public share. Combining a local private key with the peer’s public share produces the same shared secret at both ends. An observer sees public shares, not the private values needed to reproduce that computation under the algorithm’s security assumptions.

TLS does not simply use the raw ECDH output as an application encryption key. Its key schedule derives distinct handshake and application traffic secrets, binds them to the handshake context, and separates directions and purposes. Fresh exchange material is one ingredient in that larger protocol, not a substitute for the protocol.

A certificate binds an identity to a public key under a trust policy. The corresponding private key signs handshake material; the certificate object does not itself sign anything. In TLS 1.3, CertificateVerify authenticates the handshake transcript in certificate-based handshakes. Without authentication, an active intermediary could replace public shares and establish separate secrets with each side.

An RSA or Ed25519 authentication key can coexist with an ephemeral exchange; the signature algorithm and key-exchange group are separate choices. TLS 1.3 also defines PSK-only resumption, which lacks DHE’s forward-secrecy property, while PSK-with-DHE adds fresh exchange material. Optional early data has weaker guarantees still. Do not infer forward secrecy for every traffic epoch solely from a TLS version or certificate label.

When it breaks

Reusing an exchange private key over long periods weakens the intended compromise boundary. Poor randomness, exposed ephemeral values, crash dumps, or TLS key logging can expose the very secrets that the guarantee assumes remain unavailable. Later disclosure of a traffic secret is a different threat from later disclosure of the certificate’s signing key.

Endpoint compromise during a session can reveal plaintext directly. A stolen authentication key can also support impersonation of future connections when an attacker can intercept them. Forward secrecy protects a particular past-traffic scenario; it does not revoke credentials or repair ongoing compromise.

Erasure is an implementation concern, not a line of reassuring prose. Setting a Go variable to nil is not proof that all copies disappeared from memory, swap, or diagnostics. Keep secrets out of logs and manage credential compromise separately from claims about recorded traffic.

Check it quickly

Save this as ecdhe_probe.go and run go run ecdhe_probe.go with Go 1.23 or newer. It uses standard-library X25519 and Ed25519 operations entirely in memory. The signing public key represents an already trusted identity for this exercise. The signed message is explicitly not a TLS transcript; this is a primitive-level experiment, not a new TLS implementation.

package main

import (
 "bytes"
 "crypto/ecdh"
 "crypto/ed25519"
 "crypto/rand"
 "fmt"
 "runtime"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 identity, signingKey, err := ed25519.GenerateKey(rand.Reader)
 must(err)
 curve := ecdh.X25519()
 var previous []byte
 for round := 1; round <= 2; round++ {
 client, err := curve.GenerateKey(rand.Reader)
 must(err)
 server, err := curve.GenerateKey(rand.Reader)
 must(err)
 message := []byte("ECDH learning probe; not a TLS transcript\x00")
 message = append(message, client.PublicKey().Bytes()...)
 message = append(message, server.PublicKey().Bytes()...)
 signature := ed25519.Sign(signingKey, message)
 check(ed25519.Verify(identity, message, signature), "trusted signature must verify")
 altered := append([]byte(nil), message...)
 altered[len(altered)-1] ^= 1
 check(!ed25519.Verify(identity, altered, signature), "altered share must fail authentication")

 clientSecret, err := client.ECDH(server.PublicKey())
 must(err)
 serverSecret, err := server.ECDH(client.PublicKey())
 must(err)
 check(bytes.Equal(clientSecret, serverSecret), "peers must agree")
 if previous != nil {
 check(!bytes.Equal(previous, clientSecret), "fresh exchange must produce a different observed secret")
 }
 previous = clientSecret
 fmt.Println("round", round, "agrees; altered share fails signature verification")
 }
 _, err = curve.NewPublicKey(make([]byte, 31))
 check(err != nil, "wrong-length X25519 key must fail parsing")
 zero, err := curve.NewPublicKey(make([]byte, 32))
 must(err)
 client, err := curve.GenerateKey(rand.Reader)
 must(err)
 _, err = client.ECDH(zero)
 check(err != nil, "all-zero shared result must be rejected")
 fmt.Println("two fresh exchanges differ with one signing identity; malformed and low-order inputs rejected")
 fmt.Println(runtime.Version())
}

Each round produces matching secrets at both participants, and the two fresh rounds produce different observed secrets while retaining one signing identity. Changing a byte of the signed public-share message fails signature verification. A thirty-one-byte X25519 public key fails parsing; a length-correct all-zero input parses but fails ECDH’s all-zero-result check.

All assertions passed with Go 1.27.0 on macOS. Only result labels are printed. The example deliberately retains the previous shared secret for comparison, so it demonstrates no secure-erasure property. It also does not prove cryptographic hardness by exhausting possible keys.

The experiment isolates agreement, freshness, authentication, and invalid-input handling. It does not exercise a real TLS transcript, certificate chain, traffic-key derivation, packet encryption, resumption, or production key disposal. Use a maintained TLS implementation for those duties and verify the actual negotiated mode; assembling these primitives is not sufficient to build a secure transport.

Sources

RFC 8446: TLS 1.3, CertificateVerify, the key schedule, PSK modes, and forward-secrecy boundaries, checked 2026-09-09.
Go crypto/ecdh, X25519 agreement and invalid public-key behavior, checked 2026-09-09.
Go crypto/ed25519, signing and verification operations, checked 2026-09-09.

Kernel entropy turns device noise into keys

Fri, 22 Oct 2027 00:00:00 +0000

Even a quiet server seeds its generator before it needs it, so the randomness failures that still happen are not shortages. They are replays: a seed baked into an image, a snapshot resumed, a state restored from before the last reseed. The kernel does not drip entropy at you; it concentrates a little device noise into a generator, then produces keystream indefinitely.

That inversion is why most of the operational folklore around entropy is now wrong: watching entropy_avail, reading /dev/random for keys, and installing an entropy daemon all address a scarcity the kernel stopped having, while the thing that genuinely breaks keys, an identical seed on two machines, is invisible to all of them.

A pool goes in, a generator comes out

The kernel mixes physical noise, including interrupt timing jitter, device latencies, hardware RNGs where available, and CPU-based jitterentropy, and extracts it with BLAKE2s into an entropy pool. That pool seeds a set of ChaCha20 CRNGs, and the CRNGs are what actually produce bytes. Collection continues and the generator is periodically reseeded, but the strength of a byte you already emitted is fixed by the state it came from.

Once initialized, the output is keystream, not a finite resource. entropy_avail sits at 256 bits, the size of a ChaCha20 key, and it does not fall when you read; a megabyte read consumes no pool credit at all. random(4) still describes entropy_avail as a value in the range 0 to 4096 and poolsize as 4096 bits on Linux 2.6 and later: documentation that keeps a stale alert alive.

/dev/random stopped being the careful choice

Since Linux 5.6, /dev/random no longer blocks outside early boot, and O_NONBLOCK is ignored on it. The separate blocking pool is gone; the same generator now sits behind a legacy name. getrandom(2), added in Linux 3.17, draws from the urandom source by default and blocks only while that source is uninitialized. GRND_NONBLOCK turns that block into EAGAIN, and GRND_RANDOM selects the random source instead, the one that can still block without an upper bound.

random(7) is blunt: unless you are doing long-term key generation, and probably not even then, avoid /dev/random and GRND_RANDOM. Once initialized, a read of up to 256 bytes always returns in full and is not interrupted by signals. The price of the safer interface is a call that can hang indefinitely.

Boot is the only window that matters

The real failure lives in the moments before initialization, which the kernel announces with a crng init done line. A machine with no saved seed has to accumulate one from device noise; a machine with a seed file, a virtio-rng device or RDRAND has it immediately. random(4)’s recipe remains the cheapest fix: at shutdown, dd 512 bytes from /dev/urandom into a mode-600 seed file, and at boot cat it back before anything asks for a key.

The asymmetry is stark: a 32-byte seed file or a single virtio-rng read reaches the 256-bit threshold instantly, while an interrupt-only boot accumulates thousands of samples first. Whether a key is minted before or after crng init done is a configuration decision, not luck.

When it breaks

The first failure is a first-boot key that blocks. A unit minting a TLS key or a token secret during its first start can call getrandom() before initialization and sit there with nothing useful in the log. Diskless machines, small routers, virtual machines restored from a frozen filesystem and containers with no entropy device are the usual victims. Compare the key file’s mtime against the crng init done line: a key older than that line came from an uninitialized generator.

The second failure is silent: nothing blocks and every dashboard looks healthy. Snapshot a virtual machine, roll it back, or stamp ten cloud instances from one golden image, and each copy resumes with the same generator state and the same seed file. They then emit identical SSH host keys, duplicate UUIDs from /proc/sys/kernel/random/uuid, and overlapping TLS session tickets, so one instance’s output predicts its siblings. Ten clones sharing one baked-in seed produced a single distinct fingerprint; ten reseeded clones produced ten.

Check it quickly

Four commands, in this order:

dmesg | grep -i "crng init done"
cat /proc/sys/kernel/random/entropy_avail /proc/sys/kernel/random/poolsize
python3 -c 'import os; print(os.getrandom(8, os.GRND_NONBLOCK).hex())'
stat -c '%y %n' /etc/ssh/ssh_host_ed25519_key /var/lib/random-seed

On a modern kernel the counter reads 256 and poolsize reads 4096: the first number is a key size, not a fuel gauge, so a low reading is not a problem to fix. The getrandom call should return eight hex bytes immediately; BlockingIOError means the source is uninitialized and a blocking call would stall. The stat output is the real check, because a host key older than the crng init done line came from an uninitialized generator and should be rotated.

Sources

Linux random(4) device, /dev/random and /dev/urandom semantics, entropy_avail and poolsize, plus the seed-file recipe, checked 2026-09-16.
Linux getrandom(2), GRND_NONBLOCK and GRND_RANDOM, and blocking until the urandom source is initialized, checked 2026-09-16.
Linux random(7), the interface comparison table and when not to use GRND_RANDOM, checked 2026-09-16.
ArchWiki: random number generation, BLAKE2s extraction seeding ChaCha20 CRNGs, and why entropy_avail stays at 256, checked 2026-09-16.

Password hashes need a slow cost

Thu, 10 Jun 2027 00:00:00 +0000

You do not choose a hash for the database; you choose it for the attacker who reads the database. Dedicated password hashes trade speed for resilience so a leak does not become a password factory.

Fast is the wrong goal

Speed is the enemy here. General-purpose hashes like SHA or MD5 run in nanoseconds and are intentionally fast, which is exactly what an offline attacker wants — they can churn through billions of guesses per second. Purpose-built password algorithms (bcrypt, scrypt, Argon2id) add a tunable cost factor plus per-user salt, so each guess costs real work (say 100ms-1s) and each account produces a different result even with a shared password. The slowness is the feature; it is what converts an instantly-downloadable hash file into a long, expensive grind. Choose an algorithm that is memory-hard where feasible, and pick a cost that stays high yet tolerable on the hardware that has to verify every login.

Design for the day the copy leaks

Design for the day the hash file leaks, because that day eventually comes. If the hashes were fast and unsalted, the attacker cracks the whole file in minutes — every weak password in the batch is gone at once. With slow, salted hashes, the same leak yields only a small fraction of the weakest passwords after real effort; the salt means identical plaintexts have different digests, so the attacker cannot amortize one guess across many accounts. Slowness plus salt and unique randomness per account is the resilience that survives the leak; there is no way back once the file is out, so the defense has to be in the stored form.

Agility when costs change

Keep the choice in one function you can change, and plan for cost to drift upward. When you raise the work factor or move to a beefier scheme, the stored hashes carry an older cost; the pattern is to rehash on the next successful login and update the record. That keeps every account’s cost current without requiring every user to reset a password, and it means your scheme can track hardware and algorithm advances over years. The permission model of ‘verify with latest, refresh on login, downgrade never’ should be explicit in the code, and the transition path (verified old hash -> new hash) must be a code path, not a manual migration.

When it breaks

A single fast digest is the classic failure. SHA-256 or MD5 verifies in microseconds, so after a dump the attacker replays billions of guesses per second per GPU; weak passwords fall in hours and the whole table falls together because no per-guess cost remains. Missing salt makes it worse: identical passwords share one digest, so a single guess breaks every account that chose it, prebuilt tables transfer across breaches, and equality itself leaks who shares a password. A global salt only blocks prebuilt tables while still letting one guess test the entire file at once.

A frozen cost factor is the quieter failure. Bcrypt cost 04 or PBKDF2 with a few thousand iterations may have been reasonable years ago, but hardware moved on while stored values did not. Comparison and availability break next. A plain equality check can exit on the first differing byte and expose an online timing oracle, so verification must use constant-time comparison. In the other direction, unbounded cost on the login path turns each bogus attempt into CPU you pay for; cap the maximum work, rate-limit logins, and watch for silent truncation such as the bcrypt 72-byte limit or encoding mismatches that let different inputs verify identically.

Check it quickly

Save the following as hash_cost_demo.py in a scratch directory and run python3 hash_cost_demo.py. It uses only the standard library (hashlib, hmac, os, time), makes no network calls, and writes nothing to disk. The script contrasts fast digests against PBKDF2-HMAC-SHA256 stretching, shows two random salts give different digests for one password, and checks verification with constant-time comparison.

"""Fast digest vs stretched password hash (stdlib only)."""
import hashlib
import hmac
import os
import time


def check(ok, message):
 if not ok:
 raise AssertionError(message)


def main():
 password = b"correct-horse-123"
 wrong = b"correct-horse-124"

 # 1. Fast hashes are cheap: time thousands of single SHA-256 digests.
 rounds = 5000
 start = time.perf_counter()
 for _ in range(rounds):
 hashlib.sha256(password).digest()
 fast_secs = time.perf_counter() - start
 print(f"fast: {rounds}x SHA-256 in {fast_secs*1000:.2f} ms")

 # 2. Stretching adds a tunable cost: one PBKDF2-HMAC-SHA256 derivation.
 # Demo uses 100k iterations so it finishes instantly; production
 # guidance asks for much more (see OWASP Password Storage).
 salt1 = os.urandom(16)
 salt2 = os.urandom(16)
 check(salt1 != salt2, "salts must differ")
 start = time.perf_counter()
 stored = hashlib.pbkdf2_hmac("sha256", password, salt1, 100_000)
 slow_secs = time.perf_counter() - start
 print(f"slow: 1x PBKDF2-HMAC-SHA256(100k) in {slow_secs*1000:.2f} ms")

 # 3. Random per-user salt: same password, different salts, different digests.
 other = hashlib.pbkdf2_hmac("sha256", password, salt2, 100_000)
 check(stored != other, "random salts must separate identical passwords")
 print(f"salt separates: {stored.hex()[:16]}... != {other.hex()[:16]}...")

 # 4. Negative control: a global salt keeps identical passwords identical.
 global_salt = b"site-wide-salt-01!"
 alice = hashlib.pbkdf2_hmac("sha256", password, global_salt, 100_000)
 bob = hashlib.pbkdf2_hmac("sha256", password, global_salt, 100_000)
 check(alice == bob, "global salt must link identical passwords")
 print("global salt links identical passwords (do not do this)")

 # 5. Verify by re-deriving with the stored salt, using constant-time compare.
 again = hashlib.pbkdf2_hmac("sha256", password, salt1, 100_000)
 check(hmac.compare_digest(stored, again), "same password+salt must verify")
 bad = hashlib.pbkdf2_hmac("sha256", wrong, salt1, 100_000)
 check(not hmac.compare_digest(stored, bad), "wrong password must not verify")
 check(hmac.compare_digest(stored, stored), "compare_digest self-check")
 check(not hmac.compare_digest(stored, other), "compare_digest mismatch-check")
 print("verify: correct password passes, wrong password fails")

 print(f"ratio: one stretched hash costs ~{(slow_secs / (fast_secs / rounds)):.0f}x one fast digest")
 print("PASS: slow salted stretching beats a single fast digest")


if __name__ == "__main__":
 main()

The output reports microseconds for thousands of fast hashes against milliseconds for one stretched hash, then confirms re-derivation with the same salt reproduces the stored value while a wrong password fails. The assertions passed with Python 3.12 on macOS; timings vary by machine. The demo uses reduced iterations so it finishes instantly and does not prove Argon2id tuning, GPU cost, or production rate limiting. Re-check your verifier with its documented cost parameter and a login flood budget before raising work factors.

Sources

OWASP: password storage, slow, salted hash choices, checked 2027-06-08.
OWASP: cryptographic storage, hashing vs encryption, checked 2027-06-08.
OpenSSL: digest tool, how digests are computed, checked 2027-06-08.

Crypto · XB Field Notes

TLS ECDHE keeps sessions forward-secret

Two kinds of keys do different jobs

When it breaks

Check it quickly

Further reading

Sources

Kernel entropy turns device noise into keys

A pool goes in, a generator comes out

/dev/random stopped being the careful choice

Boot is the only window that matters

When it breaks

Check it quickly

Sources

Password hashes need a slow cost

Fast is the wrong goal

Design for the day the copy leaks

Agility when costs change

When it breaks

Check it quickly

Sources