- 63comments
- 11comments
- 410comments
- 114comments
- 101comments
- 65comments
- 245comments
- 344comments
- 20comments
- 51comments
- 284comments
- 273comments
- 61comments
- 30comments
- 329comments
- 84comments
- 11comments
- 3comments
- 1comments
- 8comments
- 66comments
- —discuss
- 36comments
- 10comments
- 23comments
- 38comments
- 61comments
- 63comments
- 41comments
- 489comments
Embarrassing, but probably little practical impact, since these hardware random numbers are typically not used directly and instead seed a CSPRNG.
It is just possible they decided crypto code that uses it was safer to skip zeros. (Whist mathematically it should be no more likely; it is vastly more likely someone will actually try that key).
It is also possible that their code was generating too many zeros and the easiest fix was to discard them all.
this is not how crypto works
The probability of generating a zero is incredibly low if you use the normal distribution curve.
So it is not necessarily that it doesn't generate zero, they did not run enough times to increase the probability of actually generating a zero.
Why would it be a normal distribution?
From what I can see they were trying to generate 16bit integers, so the probability is 1 in 65536 and they were running the test for 11 hours.
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
This also seems to happen for 16 and 32 bit numbers, so you should be able to see zeros easily.
They also write:
I'm getting 16-bit zeros on my Zen 3 chip (+1:3821, 0:3893, -1:3895), I will wait to get some statistically significant samples for the 32-bit values and update the forum thread. Maybe it was fixed after Zen 2?
Well, mathematically speaking, the probability to pick any specific number is exactly 0 (but yes I do see what they mean).
This is not the first RNG bug on Zen 2, I recall after I first got mine that some application or other would quit immediately at startup because rdrand always returned -1, i.e. all 1s. It was fixed with a microcode update.
Do we now learn that they fixed "always generate all 1s" with "never generate all 0s"??
Usually you do "rdrand % <some-number>" anyways, and in that case you will still get zeroes. True, your result might be skewed by 1/(maxint/some-number) but I guess that's not a big problem in practice