Archivecryptography
Randomness Failures Are Silent Until They Are Fatal
Weak RNGs do not throw errors. They produce keys that look fine and are shared with everyone.
- Published
- Reading time
- 1 min read
Cryptographic randomness fails quietly. A weak generator still returns bytes; the keys still work. The damage appears later as duplicate keys, predictable nonces, or recoverable signatures.
Recurring failures
- Boot-time entropy: embedded devices generating keys before the pool is seeded. Two devices booting the same image produce the same key (the classic "shared SSH host key" scans).
- VM snapshots: cloning a running VM duplicates the RNG state; both clones then emit the same stream.
- Forked processes: children inheriting parent state and producing identical nonces.
- Home-grown PRNGs:
rand()seeded with time.
Defenses
- Use the OS CSPRNG (
getrandom,BCryptGenRandom) and never reimplement it. - Reseed after fork; modern libraries do this, but check.
- Prefer deterministic nonces for signatures (Ed25519) so RNG failure cannot leak the key.
- Health-test entropy at provisioning and fail closed.
Takeaway: the RNG is a security boundary. Assume it can fail and design so the failure is detectable rather than silent.