Every cryptographic key, every nonce, every salt and every temporary value in a key exchange starts life as a random number. If that number is predictable, even the best algorithm in the world becomes useless: the attacker does not need to break AES or RSA, they just need to guess the key. That is why the quality of randomness is one of the least visible, and most important, pillars of cryptography.
Random does not mean "looks random"
A sequence such as 7, 3, 9, 1, 4 may look random, but in cryptography the right question is a different one: can anyone predict the next value, or reconstruct past ones, by observing those they have already seen?
Many number generators built into programming languages produce statistically well-distributed sequences, perfect for simulations and video games. But they are entirely determined by an internal state: by observing enough outputs, that state can be reconstructed and every following value predicted. For a game that is not a problem; for a cryptographic key it is a disaster.
Two families of generators
True generators
A true random number generator (TRNG) draws bits from unpredictable physical phenomena: electronic noise in circuits, tiny variations in execution times, quantum effects. Many modern processors include a hardware generator of this kind. The drawback is that physical phenomena produce bits slowly and not always perfectly uniformly.
Cryptographic pseudorandom generators
A cryptographically secure pseudorandom number generator (CSPRNG) starts from a small, truly random seed and expands it into a large quantity of bits, using constructions based on ciphers or hash functions. The key property is that, without knowing the internal state, its outputs are indistinguishable from truly random bits and do not allow previous or subsequent values to be worked out.
In practice, operating systems combine the two: they collect entropy from various physical sources, mix it into a pool and use it to feed a CSPRNG, which supplies random numbers quickly to every application.
Where to find the right generator
The practical message is simple: use the operating system's cryptographic generator, directly or through the cryptographic library you are already using.
| Environment | Recommended source |
|---|---|
| Linux | The getrandom system call or the /dev/urandom device |
| Windows | The random generation functions of the system cryptographic interface |
| macOS and iOS | The system's secure random generation functions |
| Browser | The crypto.getRandomValues function |
| Programming languages | Modules dedicated to security, not general-purpose random functions |
There is no need, and indeed it is counterproductive, to build your own generator by combining the time of day, the process ID and the mouse position.
When randomness is missing: real cases
Randomness failures have produced some of the most serious cryptographic breakdowns.
- Duplicate keys on devices: research analysing millions of public keys exposed on the Internet found many devices, mainly network and embedded equipment, that shared keys or prime factors. Many generated their keys at first boot, when the system had not yet gathered enough entropy.
- A code change that wiped out randomness: in 2008 it was discovered that in a well-known Linux distribution, because of a change to a cryptographic library, the randomness of generated keys depended almost solely on the process ID. There were only a few tens of thousands of possible keys, and they could all be listed.
- Suspect generators in standards: an elliptic-curve-based generator included in a US standard came under strong suspicion of a possible "back door" linked to its parameters. In 2014 it was withdrawn from the official recommendations.
- Repeated nonces in signatures: several cases of compromised ECDSA signing keys were caused by values that were supposed to be random and unique, but were not.
Risky situations
Some contexts deserve particular attention:
- system start-up: right after power-on entropy can be scarce, especially on simple devices without a keyboard, disk or hardware generator;
- cloned virtual machines: if a virtual machine is cloned with its generator state already initialised, the copies may produce the same values;
- embedded and IoT devices: they have few noise sources and often generate keys at the factory or on first boot.
Modern operating systems have greatly improved how they handle these cases, for example by blocking generation until the generator has been properly initialised.
Randomness for everyone
Randomness matters outside code too. A passphrase chosen "at random" by the human mind tends to follow predictable patterns. Methods such as picking words from a list by rolling dice, or relying on the generator of a good password manager, produce far stronger secrets than the ones we make up ourselves.
In short
- Keys, nonces and salts are secure only if generated with unpredictable randomness.
- The general-purpose random generators in programming languages are not suitable for cryptography.
- Operating systems collect physical entropy and use it to feed a secure cryptographic generator.
- Randomness failures have caused duplicate keys, predictable keys and compromised signatures.
- Always use the system's or library's cryptographic generator, never a home-made one.
