Cybersecurity

Rob Behnke

September 1st, 2022

In order to understand what a random number generator attack is, we’re going to dive into a short lesson on cryptography, random numbers, and why predictability is overrated. Let’s jump in.

From the WWII-era Enigma machine to the Bitcoin blockchain, cryptography – the science of encrypting and decrypting information – is here to stay. But regardless of era, the security of these systems depends on secret data that is known only to authorized parties and unknown and unpredictable to all others. For this unpredictability to occur, these systems often require the frequent generation of random quantities.

These random numbers often take the form key generation, nonces and salts (applicable to certain signature schemes). Key generation is a common use case especially as it pertains to digital wallets, where salts are often used in generating secure passwords. A nonce (from the moniker n+once) is an arbitrary number used only a single time to sign a cryptographic communication.

There are many examples of nonce usage in cryptography, such as in an authentication protocol where a nonce is generated to ensure that old communications cannot be reused in replay attacks. They are also used for generating keys for encryption or TLS sessions and initialization vectors in block cipher modes of operation.

Unsurprisingly, humans alone are quite bad at random number generation, instead relying on programmatic random number generators. But these generators too have varying degrees of randomness based on the amount of entropy used.

Low-quality pseudo random number generators (PRNG) are deterministic algorithms that use a starting value that outputs numbers which look random, but actually have a statistical relationship to the original or “seed” value.

While it is programmatically faster to use a PRNG (typically used for simulations, gaming and cryptography), these PRNGs, such as Python’s random.random(), have a statistical relationship between their outputs, offering a non-zero degree of predictability and randomness. These utilize low entropy and are thus more vulnerable to attack.

Cryptographically secure pseudo random number generators (CSPRNG), on the other hand, offer more security since they output statistically uncorrelated numbers but are more difficult to implement efficiently. CSPRNGs use entropy obtained from a high-quality source, generally the operating system’s randomness API to extract randomness from a running system. These are high-entropy but more process intensive.

In summary, high-entropy random number generation (RNG) is a prerequisite for the security of important systems, while low-entropy RNG creates a whole host of cryptographic compromises.

As you may have guessed from this lead-up, there are more than a few attack vectors where random number generators are concerned. Here’s an example of hacking the Mersenne Twister, a general-purpose PRNG. In this instance, a hacker can query a server an arbitrary number of times, attaining outputs by logging in and out but recording the session token each time.

Since these tokens are non-random, they have a relationship to the original seed value. This means the attacker can work backward to view each shift in the relationship (using each session token) and then essentially clone the original PRNG. This then allows them to take over any future sessions by generating the next seed output and thus the session token.

While this is one example of a specific attack vector, there are also more generalized buckets.

**State compromise extension attacks** happen when a hacker is able to obtain the internal secret state of an RNG and use this to either recover previous outputs or even predict future outputs.

**Input-based attacks** modify the RNG input, changing the output to become less random and more known.

Last but not least, **direct cryptanalytic attacks** happen when hackers are able to distinguish an RNG output from a truly random stream.

Interested in learning about potential security vulnerabilities and how to stop them before they occur? Connect with our security experts at halborn@protonmail.com.