Crypto · XB Field Notes

The forward-secrecy boundary of TLS ECDHE

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.

Fresh agreement, authentication and key derivation are separate jobs. Forward secrecy limits a specific later-signing-key compromise scenario; it does not protect exposed session secrets or compromised endpoints.

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.

The retained article reports that all assertions passed with Go 1.27.0 on macOS; this review did not rerun the Go fixture. 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

Linux applications normally obtain cryptographic randomness from a kernel generator, rather than consuming one newly collected physical bit for every output bit. Initialization and state reuse still matter. A busy machine is not automatically safe, and a quiet machine is not automatically broken. Diagnose the interface, kernel version, and boot or cloning process before deciding that a counter proves a security failure.

Separate collection from output

The Linux 6.12 implementation mixes inputs into a BLAKE2s-based pool and uses ChaCha20 for output. These are implementation details of that version, not an eternal interface contract. Hardware sources, interrupt timing, and bootloader input contribute under platform-specific trust rules. Supplying bytes and crediting them toward initialization are separate operations; the kernel cannot assume arbitrary user-supplied bytes contain fresh unpredictability.

In that implementation, both poolsize and the initialized entropy counter reach 256 bits. Reads do not spend that counter like fuel. A historical manual’s 4096-bit description therefore should not become a universal alert threshold. Record the running kernel and inspect its behavior instead of claiming that every Linux version exposes identical counters or that a small number proves weak output.

Choose an initialization-aware interface

Default getrandom waits until initialization. GRND_NONBLOCK instead reports EAGAIN while initialization is incomplete, allowing an application to report the condition without hanging. Once initialized, a default-source request of at most 256 bytes has the documented full-read and signal guarantees; callers should still check errors and returned length. Larger requests need normal handling of partial results and interruptions.

The random device’s behavior changed in Linux 5.6: it no longer blocks for entropy depletion after initialization. In the inspected Linux 6.12 code, GRND_RANDOM does not select a separately depleting output pool. Some manual descriptions retain older behavior, so avoid combining their historical limits with current-kernel claims. Direct urandom reads can precede initialization; prefer the supported initialization-aware interface for early-boot key generation.

When it breaks

Early boot can still lack sufficient credited input. Missing device nodes in a container are a separate interface problem: getrandom does not require a device pathname, and ordinary containers share their host’s kernel. A blocked operation deserves an explicit startup failure or waiting policy, rather than replacing cryptographic randomness with timestamps, predictable seeds, or insecure fallback output.

A saved seed can improve the next boot, but writing a file back to urandom does not itself credit entropy. Neither a 32-byte file nor the mere presence of a hardware device proves immediate readiness. Use the distribution’s seed-management mechanism and its documented trust policy. Protect seed files, avoid shipping a common saved seed in cloned images, and keep any bootloader-specific seed handling aligned with the operating system.

Disk-image cloning and restoring a running virtual machine are different hazards. The first can copy seed files or already-generated host keys; the second can duplicate live generator state. Fresh inputs and VM-generation-ID handling can separate subsequent state. Identical future output is a risk to investigate, not an inevitable consequence of every clone. A seed shared by two machines alone does not establish that their entire generator states match.

Input crediting, initialization and output are separate. Only the labeled Linux 6.18.44 results are retained historical observations; no new random request was made.

Check it quickly

Run this Python 3 script on Linux. It reads counters and makes one nonblocking 32-byte request without printing random material, reading private keys, changing seed files, or requiring administrator access:

from pathlib import Path
import json
import os
import platform

def counters():
 result = {}
 for name in ("entropy_avail", "poolsize"):
 try:
 result[name] = int(Path("/proc/sys/kernel/random", name).read_text())
 except OSError as error:
 result[name] = type(error).__name__
 return result

before = counters()
try:
 sample = os.getrandom(32, os.GRND_NONBLOCK)
except BlockingIOError:
 print(json.dumps({"kernel": platform.release(), "ready": False,
 "counters": before}))
else:
 assert len(sample) == 32
 print(json.dumps({"kernel": platform.release(), "ready": True,
 "bytes_returned": len(sample), "before": before,
 "after": counters()}))

Retained audit output from Linux 6.18.44 with Python 3.12.14 reported ready=true, bytes_returned=32, and 256 for both counters before and after. These are observations from an already-initialized host, not a test of early boot, hardware quality, or restored virtual machines. For EAGAIN the program reports ready=false; that branch was not reproduced. This source-only review made no random request. Other syscall errors propagate rather than becoming an initialization verdict.

A successful call establishes that this interface supplied the requested bytes at this moment. It is not a statistical or cryptographic proof of unpredictability, and comparing two samples cannot provide that proof either. Restricted proc access may leave counter error names while the syscall still succeeds. Treat those outcomes separately instead of turning unavailable diagnostics into a claim of entropy failure.

Investigate identity reuse with direct evidence

A key’s modification time cannot prove which random source generated it. Files survive reboots, copying preserves timestamps, and clocks can move. Likewise, an inaccessible or missing initialization log is not proof of failed initialization. Inspect image preparation, key-generation code, boot policy, and duplicate public-key fingerprints. Rotate identities when actual duplication or exposure is established; do not infer compromised keys solely from a timestamp comparison.

Sources

Linux 6.12 random implementation, initialization accounting, getrandom, sysctls, and VM-fork reseeding, checked 2026-10-15.
Linux getrandom(2), initialization-aware calls, small reads, and errors; historical GRND_RANDOM details require version context, checked 2026-10-15.
Linux random(4), uncredited writes and the Linux 5.6 blocking change; historical pool-size text is not current-kernel evidence, checked 2026-10-15.
systemd 256 random-seed service, seed lifecycle, entropy-credit policy, and image preparation, checked 2026-10-15.

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 to increase the cost of offline guessing after a leak.

Salt separates work; cost slows each guess. Verify with the stored parameters first, and consider a stronger rehash only after successful authentication. Weak passwords and server availability still set limits.

Fast is the wrong goal

Speed is the enemy here. General-purpose hashes such as SHA-256 are intentionally fast, allowing offline attackers to test guesses efficiently; actual rates depend on algorithm and hardware. Purpose-built password algorithms (bcrypt, scrypt, Argon2id) add a tunable cost factor plus per-user salt, so guesses require deliberate work and independently salted accounts have different stored values even with a shared password. The added per-guess work is the feature; its benefit still depends on the selected parameters and password strength. 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

Treat database disclosure as a threat to plan for, not an event with a predictable cracking deadline. Weak passwords may still fall quickly under a strong scheme; strong passwords are not automatically recovered merely because a fast hash was used. Unique random salts prevent reuse of precomputed tables and require separate per-salt work. They are public inputs stored with the verifier, not encryption keys or additional password entropy. Hashing slows guesses; it does not make a breached database safe or replace incident response.

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 updates returning accounts without requiring every user to reset a password immediately, and it means your scheme can track hardware and algorithm advances over years. Verify with the algorithm, salt, and parameters stored in the existing record. Only after successful verification should a policy check trigger rehashing with current parameters. Preserve that distinction: verifying an old hash with new parameters would reject a legitimate password. Accounts that never log in still need an explicit migration or reset plan.

When it breaks

A single fast digest makes each offline guess inexpensive; the recovered fraction still depends on password strength and the attacker’s resources. 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. Use the password library’s verifier, or a suitable timing-resistant comparison for derived values; ordinary equality is not a cryptographic timing guarantee. 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 a reduced 100k iterations for a short exercise; 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: per-salt derivation, global-salt control, and password verification checks")


if __name__ == "__main__":
 main()

The output reports milliseconds for both the fast-hash batch and one stretched derivation, then confirms re-derivation with the same salt reproduces the stored value while a wrong password fails. The earlier macOS run is historical; both exact examples passed on Python 3.12.14 in this review. Timings vary by machine. The demo uses reduced iterations 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, algorithm selection, salts and work-factor upgrades, checked 2026-10-15.
Python hashlib, PBKDF2 parameters and key derivation, checked 2026-10-15.
Python hmac, compare_digest behavior and timing caveats, checked 2026-10-15.

Crypto · XB Field Notes

The forward-secrecy boundary of TLS ECDHE

Two kinds of keys do different jobs

When it breaks

Check it quickly

Further reading

Sources

Kernel entropy turns device noise into keys

Separate collection from output

Choose an initialization-aware interface

When it breaks

Check it quickly

Investigate identity reuse with direct evidence

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