Why Your Random Number Generator Is Probably Leaking Your Private Keys

TLDR: Cryptographic systems rely on entropy that is often assumed to be perfect, but real-world implementations frequently fail to provide sufficient randomness. This talk demonstrates how weak PRNGs allow attackers to recover private keys and perform passive eavesdropping on TLS traffic. By moving to Multi-Party Computation (MPC), developers can distribute trust and eliminate the single point of failure inherent in traditional key generation and signing processes.

Randomness is the bedrock of modern cryptography. If your entropy source is predictable, your entire security model collapses, regardless of how strong your algorithms are. We often treat the output of a Pseudo-Random Number Generator (PRNG) as a black box that just works, but recent research confirms that when that box is compromised, the results are catastrophic.

The Anatomy of a Perfect Crime

A perfect crime in cybersecurity is one that is both lethal and undetectable. When a PRNG fails, it is often silent. You do not get an error message when your entropy is low; you just get a private key that is slightly less random than it should be. In the context of Bitcoin or Ethereum, a private key is the absolute authority over your funds. If an attacker can guess or brute-force that key because the PRNG was seeded with a low-entropy value, they don't need to bypass your firewall or phish your credentials. They simply derive the key and drain the wallet.

The problem is that we have no way to verify if a number is truly random after the fact. We only see the output. If a system generates a key using a flawed PRNG, that key is effectively public knowledge to anyone who can replicate the generator's state. This is not just a theoretical risk. We have seen real-world instances where Bitcoin wallets generated before 2016 were compromised because the underlying JavaScript PRNG lacked sufficient entropy, as detailed in recent reporting on wallet vulnerabilities.

Exploiting the TLS Handshake

The impact of bad randomness extends far beyond static keys. It fundamentally breaks the dynamic security of protocols like TLS. During a TLS handshake, both the client and the server contribute random values to establish a session key. If an attacker can predict or force these random values, they can perform a passive man-in-the-middle attack.

The Reductor malware is a prime example of this in the wild. By patching the PRNG functions within common libraries like nss3.dll or crypt32.dll, the malware forces the system to use a predictable value instead of true randomness. Once the client's random value is known, the attacker can decrypt the traffic without ever needing to compromise the server's private key. This is a masterclass in stealth. The victim continues to browse the web, seeing the familiar padlock icon, completely unaware that their encrypted traffic is being intercepted and read in real-time.

For those interested in the mechanics of how these keys are recovered, the TLS Masterkey Recovery tool provides a clear look at how an attacker can use the known random values from a packet capture to derive the session keys.

Moving Beyond Single Points of Failure

Defending against these attacks requires us to stop treating the PRNG as a local, monolithic component. If your entire security posture depends on a single piece of hardware or a single software library to provide entropy, you have a single point of failure.

Multi-Party Computation (MPC) offers a way out. By distributing the key generation and signing process across multiple independent parties, you ensure that no single entity—or single compromised PRNG—can control the outcome. Even if one party's entropy source is weak or malicious, the final key remains secure because the other parties contribute their own independent randomness.

For developers looking to implement these patterns, the Gotham City repository offers a practical implementation of MPC for ECDSA. This approach effectively mitigates the risk of a single compromised PRNG because the final signature is only valid if the honest parties maintain their integrity.

Practical Steps for Pentesters

When you are on an engagement, stop assuming the crypto is "just fine." If you are auditing a client's application that handles sensitive keys, look at how they seed their PRNG. Are they using human-generated passphrases? As the Bitcoin Wiki notes, humans are notoriously bad sources of entropy. If you see a "brain wallet" implementation, you have already found your path to exploitation.

Furthermore, when analyzing network traffic, look for patterns in the random fields of the TLS ClientHello. If you see the same values or patterns across multiple sessions, you are likely looking at a broken PRNG. This is a high-impact finding that often gets overlooked because it doesn't look like a traditional injection or buffer overflow.

Security researchers should continue to push for the adoption of deterministic nonces in ECDSA implementations. By deriving the nonce from the private key and the message itself, we remove the reliance on a local PRNG during the signing process, which is a massive win for robustness. We need to stop building systems that require perfect local randomness and start building systems that are resilient to the inevitable failure of any single component.