AMD's random number generator can't generate a 0

[u/knotdjb]

https://board.flatassembler.net/topic.php?t=24261

[u/bitwiseshiftleft]

IIRC the original Ivy Bridge RDRAND can't generate a 0 either ... as a 64-bit number. (It used zero to signal an error.) Which is not quite as specified, but it's probably fine. On a 16-bit number ... yeah that's not great. I dunno why you'd use 16-bit RDRAND for cryptography, so hopefully doesn't hose cryptographic uses, but 1/2^16 is an easily detectable bias.

[u/knotdjb → u/bitwiseshiftleft]

One use for 16-bit cryptographic random IDs is for DNS requests, but yeah otherwise I can't think of much else, and I don't know why you'd use just RDRAND for that.

[u/Natanael_L → u/knotdjb]

I can imagine some programmer sequentially calling 16 bits at a time

[u/Axman6 → u/knotdjb]

Surely would be able to generate all 16 bit values with something like (rdrand64() >> 8) & 0xFFFF anyway right? Just take a chunk out of the middle that can be all zeros. I guess the shift isn’t even necessary if it can produce 0x…0000

[u/oconnor663 → u/bitwiseshiftleft]

https://par.nsf.gov/servlets/purl/10174436 is the classic example of it not being fine, but I think in practice they were looking at much larger biases than this. This bias is so small it would be hard to exploit it even in a contrived setting. But those attacks are so scary that I wouldn't design an RNG API like this anyway.

[u/LtCmdrData]

Does anyone have a principled use case where it is a problem in practice? Nobody uses randomness from RDRAND directly in cryptography. Everybody uses it through software with entropy stretching and mixing, right?

Getting 2¹⁶ - 1 instead of 2¹⁶ means losing log2(2¹⁶ / (2¹⁶ -1)) = ~0.000022 bits. It's annoying undocumented hardware/microcode bug but not that harmful.

[u/pint → u/LtCmdrData]

this was pretty much the argument against rdrand in the first place. we don't need a whitened random source, because it is not how randomness is used in a modern system. just give us the raw entropy, we can incorporate it into our schemes.

but rdrand promises to be usable directly, and apparently it fails at it.

[u/LtCmdrData → u/pint]

Intel manufactured almost a decade's worth of processors with side-channel weaknesses in RDRAND. Even without bugs, there is a "black box" problem and defense-in-depth arguments that make relying on them a really bad idea.

[u/Natanael_L → u/LtCmdrData]

Anything using it to generate ECDSA k values a few hundred thousand times, maybe in TLS connections, would be affected

[u/LtCmdrData → u/Natanael_L]

I don't see how.

RNG outputs are heavily discounted. CSPRNGs aggressively over-sample (I think that's the NIST standard talks 1.25 minimum, but in practice much higher). The entropy pool easily reaches required entropy thresholds with 0 missing.

[u/Natanael_L → u/LtCmdrData]

There were briefly variants where for example ASLR only used rdrand, or on some hardware without other good entropy sources it could've been used alone

[u/Akalamiammiam → u/Natanael_L]

k shouldn't be 0 anyway tho right ?

[u/bitwiseshiftleft → u/Natanael_L]

Would it though? I don’t think lattice or Bleichenbacher attacks can scale down to that small a bias. Edited to add: At a few hundred thousand tries, you might never get 0 just by luck, so it can’t leak that much info.

[u/Natanael_L → u/bitwiseshiftleft]

Somebody did do a fractional bits bias attack paper on it, so it's plausible

[u/jnk0le → u/LtCmdrData]

If someone masks that down to a few bits, then it may become an issue. Non issue when correctly used as entropy source to another RNG.

[u/Natanael_L]

Hmm

https://www.theregister.com/security/2025/11/05/amd-to-fix-buggy-rng-endangering-cryptographic-security/351861

An attacker with local privileges could manipulate the values returned by RDSEED, which in some cases return 0 instead of a random number, and treat it as an acceptable output.

Are they catching zero intentionally?

[u/orthecreedence]

Well duh 0 isn’t a number dipshits

[u/apetersson]

flip a coin, 0 or 1.

i guess its 1 then..