A Billion Random Numbers Can Still Miss Zero

(1 - 1/2^32)^1000000000 ≈ 79%

In other words, missing zero is the more likely outcome.

An average waiting time of roughly 4.3 billion draws is not a deadline. Reaching that count does not guarantee a zero. Previous misses do not make zero more likely on the next independent draw, either. The generator does not owe you one.

That makes **sample size and output width** inseparable. A billion draws without an all-zero 8-bit value would mean something very different from a billion draws without an all-zero 64-bit value.

## Before blaming the chip, inspect the test

“Did it produce zero?” sounds precise. It leaves several questions unanswered.

Are you checking whether the entire 32-bit integer is zero, or whether its lowest eight bits are zero? Under the same uniform model, those eight bits are all zero with probability **1 in 256**. That is a much more frequent event than the entire integer being zero.

Then there is the software between the processor and the number on your screen. It might change the range, discard certain values, or retry whenever it receives zero. A program with that last rule will never display zero, regardless of what the hardware produces.

**Success status** also needs to be distinguished from the returned value. If an interface reports success separately, only successful results belong in the sample. Counting a stale value left after a failed call can distort the analysis.

“Tested on AMD” therefore tells us very little by itself. A reproducible test needs the CPU model, the instruction or interface used, the output width, and the code that handles each result.

## A missing value is not the same as a predictable key

Now suppose careful investigation establishes that a generator really cannot produce zero.

If it promises a uniform distribution across the full bit range, that is a defect: one permitted outcome is missing. Its output does not match its stated behavior.

But that finding alone does not establish that an attacker can predict cryptographic keys. A missing value and a practical prediction attack require separate analysis.

The reverse is just as important. Seeing zero once does not certify a generator as secure. A counter starting at zero passes that test immediately. Everyone can also predict its next output.

Security evaluation has to go further. Are there recurring patterns? Does knowing previous outputs help predict the next one? What happens if the generator’s internal state is exposed?

Hardware adds another distinction: the physical source of randomness and the processing that turns it into usable output. A suspicious number on a screen does not, by itself, identify which stage is responsible.

## What would make the evidence convincing?

Start by calculating how often the observation would occur under the expected behavior. In the 32-bit example, no zeros in a billion draws is common enough that it offers little reason to suspect a defect.

Next, inspect the test code and repeat the experiment under documented conditions. Comparisons across processors need matching output widths and counts of successful draws. Otherwise, the apparent hardware difference may simply be a difference in measurement.

Broader statistical checks can examine the balance of individual bits and relationships between successive outputs. Those tests can reveal problems that waiting for one particular integer would miss. Passing them still does not prove resistance to every prediction attack.

For any claim that AMD hardware cannot produce zero, the decisive details are the interface, the implementation, and reproducible observations. A billion missing zeros sounds dramatic. Until you know how many possible values were competing for those billion draws, it tells you less than you think.