cubes full of ones and zeros

Security Highlight: When Random Isn’t Random—Understanding RDSEED Bias on AMD

Randomness is a fundamental building block of security: keys, nonces, session tickets, and seeds all depend on it. AMD’s recent disclosure of a bias in the 16- and 32-bit variants of RDSEED on Zen 5 processors is notable because it illustrates how easily low-level assumptions about entropy can fail silently. While the 64-bit variant behaves correctly, the smaller forms — used more often in legacy and embedded contexts — can return an all-zero output while incorrectly reporting success. This creates subtle but real downstream risks for systems that rely directly on hardware-generated entropy.

How Small Entropy Bugs Break Security

RDSEED is an x86 instruction that provides fresh, high-quality entropy for seeding cryptographic random number generators. Software such as OS entropy pools, TLS libraries, and bootloaders may call it directly when available. Per the specification, RDSEED should return a random value and set the carry flag CF=1 when sufficient entropy is available; otherwise, it should set CF=0 so the caller can retry.

On Zen 5, researchers observed that the 16-bit and 32-bit variants may return zero while still setting CF=1 at a probability greater than 10% — far above what true randomness would suggest. “This was reproduced reliably by launching 2-threads per available core, 1-thread per for hamming on RDSEED, and 1-thread per core collectively eating and hammering on ~90% of memory,” according to the Linux Kernel mailing list. The 64-bit variant, which is the one many 64-bit OSes and libraries use by default, is not affected.

It may seem less severe than, for example, arbitrary code execution, but it can fully break protections provided by cryptography, for instance, leading to an adversary decrypting a TLS session. One real-world example is the Debian SSH key issue that occurred in 2006–2008. A Debian developer removed a critical part of the entropy-gathering code in OpenSSL after misinterpreting it as uninitialized-memory misuse, leaving the pseudo-random number generator (PRNG) effectively dependent on the process ID, with about 2¹⁶ possible values. As a result, every SSH, SSL, and OpenVPN key generated with the affected OpenSSL packages on Debian-based systems during that period came from a small, predictable keyspace. Attackers could precompute all possible keys for each algorithm and bit-length, then simply match a victim’s public key to recover the private key. The vulnerability was subtle (keys “looked random”) but severe, illustrating how easily entropy assumptions can collapse and why random number generator (RNG) modifications require extreme caution, thorough review, and continuous validation.

How Hardware RNGs Work

Modern hardware RNG subsystems generally combine two components:

The TRNG produces non-deterministic bits; the DRNG “stretches” those bits into a larger stream while smoothing out small biases. Intel’s implementation (for context) uses an AES-CTR DRBG defined in NIST SP 800-90A, seeded from a health-tested noise source.

To ensure the TRNG doesn’t silently collapse, standards like FIPS 140-2/140-3 and BSI AIS-31 define continuous, run-time health checks: repetition counts, run-length limits, stuck-bit detection, and other simple statistical checks. These catch gross failures (for example, a source stuck at zero), but they are not sophisticated tests; they aim for prompt detection, not deep statistical assurance. Considering that the AMD RNG failed under a particular system load, it is plausible that this would not be detected under normal test scenarios.

Despite these protections, RNG output cannot be fully validated by statistical tests alone. For example, AES-CTR with a fixed secret key will output a stream that passes randomness tests. If you don’t know the fixed key, the output looks random enough, even though it is fully predictable to an adversary who does know the key. This illustrates a key point: valid-looking output does not prove real entropy.

Impact and Practical Risk

Affected products include Zen 5-based Ryzen, Threadripper, EPYC, and Ryzen AI families. Applications most exposed are those that:

Modern operating systems already mix multiple inputs (timers, interrupts, RDRAND/RDSEED, device noise), so most user-space applications are indirectly protected. The main risk lies in components that assume “RDSEED always returns high-entropy values” and do not cross-check or combine other sources.

This is not an immediate remote-exploitation scenario, but a trust-erosion issue: any key or secret generated using the biased platforms may have had reduced entropy. Shannon’s entropy formula yields about 14.9 and 29.3 bits of remaining entropy, respectively, for the 16- and 32-bit versions of RDSEED. Long-lived secrets (SSH keys, TLS certificates, disk-encryption keys) generated on unpatched systems may warrant regeneration if the software used the affected instruction forms.

Mitigations

AMD has released microcode fixes distributed through firmware (AGESA) updates, and OS vendors are also rolling out patches.

Practical mitigations include:

The Broader Lesson

This incident reinforces a long-standing principle: RNGs deserve the same engineering and verification rigor as cryptographic algorithms themselves. Hardware entropy sources can degrade, microcode and firmware can contain subtle logic bugs, and no amount of post-hoc statistical testing can conclusively demonstrate “true” randomness.

A resilient design:

Related Posts

limit
3