Bug identified as carry-flag misfire, not entropy failure
4 Sep 22 8:02 AM · 1d ago · 2 comments · 1 source · development 4 of 4
A commenter clarifies that RDRAND16 likely produces zero correctly internally, but sets the carry flag (CF) to 0 erroneously when zero emerges, causing retry logic to discard the valid result.
“But it looks like the rdrand16 instruction can produce zeros just fine, it just sets CF=0 erroneously (indicating an error and that the user program should retry).”
0x000xca0xfejstanley Zen 2 CPU owner, bug reproducer0x000xca0xfe Hardware/cryptography developerAMD CPU manufacturer
The whole story articlespostscomments the bright band is this development · numbered dots are the others · click one to jump
What people said 9 voices · verbatim
-
Really interesting and surprising article. As a workaround, if you're skeptical about an RNG you can implement an algorithm using AES-CTR and putting some entropy in by hand, like mashing on the keyboard a lot. (Like, a lot though.) You can then keep encrypting it, returning some of the ciphertext as the "random" values and rekeying with the rest…
-
A
AMD's random number generator (RDSEED, RDRAND) cannot generate a 0. https:// board.flatassembler.net/topic. php?t=24261 # crypto # cryptography
-
Not sure if this finding is new, but the author from FASM Thread apparently has a Zen 2 (He doesn't directly mention anything besides "Ryzen 7", some other poster mentions it is a 4800HS). There were a number of articles about RDRAND being broken on Zen 2 and earlier generations but fixed via Microcode from about 6 years…
-
Another random boundary case: SQLite's RANDOM() won't generate the minimum i64 value, because: i64 MIN: −2⁶³ i64 MAX: 2⁶³-1 Since RANDOM() is used with ABS(), that floor value is lopped off. (Can you imagine if it weren't, and you got a bug 1 in every 2⁶⁴ calls?)
-
I remember setting up a new git CI build server many years ago, which at the time rather quickly started failing build pipelines in a nodejs css frontend build script, turns out there was something funky with the AMD processor's RDRAND. A motherboard BIOS flash update fixed it.
-
AMD's random number generator probably can't generate a 0 ;)Anyways, I think it is good practice to consider the output of any hardware RNG to be biased and to only use it indirectly as a source of entropy. The actual numbers come from a PRNG, secure of not depending on your needs, that have a guaranteed distribution.It can still cause problems if…
-
I wonder if this, or something like it, is the issue:> 32-bit XorShift should usually not be used to produce 32-bit numbers, because it only produces each number once, and never produces zero.(From this page I found while trying to see if this was a common flaw in PRNGs: https://www.pcg-random.org/other-rngs.html )
-
I can reproduce it too with rdrand16 on Zen2.But it looks like the rdrand16 instruction can produce zeros just fine, it just sets CF=0 erroneously (indicating an error and that the user program should retry).So keep that in mind when you try to reproduce it too and use some abstraction that could implement retries internally.
-
If I remember correctly, we had a setting in every Linux server we owned to remove CPU as a RNG seeder for the kernel because of those bugs with AMD CPUs.I.e., we had `random.trust_cpu=off nordrand` in `GRUB_CMDLINE_LINUX`.
All 4 developments of AMD's RDRAND16 instruction can't generate zero on some Zen… →
Hacker NewsNewswiresMastodon