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

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.

    return 4 # Determined by fair dice roll.

   $ ./a.out | rg '\b\-?\d\b' | sort -n | uniq -c
   15281 -2
   15192 -1
   15273 0
   15243 1
   15269 2

    #include <immintrin.h>
    
    short rdrand16() {     // gcc -mrdrnd
        short ret;
        while (1 != _rdrand16_step(&ret)) { }    
        return ret;
    }

Basically I'm wondering if it's a bug in the version of the instruction that writes to a 16-bit reg, or a bug in the underlying RNG

To prove it, we'd need to examine the chip and its microcode.

I fail to see why one should either rely on a single random source nor roll their own.

[edit to add]: Also, the bulletin is solely about RDSEED zeros, whereas the OP is also reporting RDRAND zeroes.

" I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction. To quote from the article below:

"By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to insert back doors...."

Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea. "

https://web.archive.org/web/20180611180213/https://plus.goog...

Putting a backdoor into CSPRNG is a favored way to break crypto, for example Dual_EC_DRBG.

"

Weaknesses in the cryptographic security of the algorithm were known and publicly criticised well before the algorithm became part of a formal standard endorsed by the ANSI, ISO, and formerly by the National Institute of Standards and Technology (NIST). One of the weaknesses publicly identified was the potential of the algorithm to harbour a cryptographic backdoor advantageous to those who know about it—the United States government's National Security Agency (NSA)—and no one else. In 2013, The New York Times reported that documents in their possession but never released to the public "appear to confirm" that the backdoor was real, and had been deliberately inserted by the NSA as part of its Bullrun decryption program. In December 2013, a Reuters news article alleged that in 2004, before NIST standardized Dual_EC_DRBG, NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library, which resulted in RSA Security becoming the most important distributor of the insecure algorithm. RSA responded that they "categorically deny" that they had ever knowingly colluded with the NSA to adopt an algorithm that was known to be flawed, but also stated, "We have never kept this relationship [with the NSA] a secret and in fact have openly publicized it."

"

https://en.wikipedia.org/wiki/Dual_EC_DRBG

Anyone from the High-Performance Computing Center Stuttgart willing to play on the 720,320 Zen2 cores?

By your argument, it would not be a problem if the RNG never generated 0. So, it must follow that it would also not be a problem if it never generated {1, 2, 3, ..., 253}.

That means that our RNG now only generates the values 254 and 255. Which of the values is generated is unpredictable on any given call. However, 7 of the 8 output bits are now always fixed and so completely predictable. Can you imagine how an attacker could exploit that?

Failing to generate only the number 0 is a weaker version of the same class of flaw.

See section 7.3.17 of the Intel SDM, and how NIST SP800-90A (which the SDM refers to) defines "random number".

You definitely would expect a roughly equal number of 0s as any other of those numbers since it's uniformly distributed. And definitely not 0

They also write:

> Running the same programs on an Intel processor, and the 0's are there with no problem.

I'm guessing you don't think there are people calling rdrand in a loop and throwing away the output with high probability except when it is 0, but I can't see how else you imagine people would be vastly more likely to use the output when it is 0?