Cryptographic randomness

The idea

Cryptographic systems need randomness that is appropriate for security use. Ordinary simulation-oriented pseudorandom generators are not suitable substitutes. Operating systems and maintained libraries provide cryptographically secure generation interfaces. Requirements differ: a secret key must be unpredictable, while some nonces must be unique under a key. Know the construction’s exact rule and handle failures explicitly. Weak initialization or repeated values can undermine strong algorithms.

In practice

An application uses its platform’s cryptographic API to generate a session token rather than deriving it from a timestamp and a user name.

A common misunderstanding

A value that looks random is not necessarily unpredictable, and “random” does not replace a uniqueness requirement.

Check your understanding

Why distinguish nonce uniqueness from secret unpredictability?

Think it through: Different cryptographic constructions depend on different properties, and violating either requirement can be harmful.

Appearance does not establish unpredictability

A fictional account service generates recovery links. A long string made from a timestamp and account number may look complicated while remaining predictable to someone who knows the format. The requirement is not visual randomness; it is that an unauthorized party cannot feasibly guess the credential under the intended conditions.

Use the platform's cryptographic generation facility through a maintained API. A simulation generator is designed for different purposes and can be reproducible from its state. Avoid replacing a supported secure interface with a homemade mixture of clocks, process identifiers, and user information. Handle generation failure according to the API rather than silently falling back to a weaker source.

Uniqueness is a related but distinct requirement. Some cryptographic constructions require a nonce not to repeat under a particular key, even though the nonce need not be secret. A random selection strategy has collision considerations, while a counter strategy has persistence and concurrency considerations. Follow the construction's specified approach rather than treating all nonces as generic passwords.

State the property before choosing the generator

For a learning exercise, list a session credential, a public record identifier, and an encryption nonce. Write whether each needs unpredictability, uniqueness, secrecy, or some combination under the hypothetical design. Explain why the same generator or storage rule may not satisfy every role.

Test application behavior when generation fails and when several requests run concurrently. Do not infer quality by counting how varied a few sample strings look. A secure design relies on supported generation mechanisms and explicit lifecycle rules, with enough documentation to explain why each value has the properties its consumer requires.

Keep exploring

• Key management
• Sessions and cookies
• AES