I can see that True Random Number Generators can produce some null bytes, after some megabytes of data, even 2 consecutive null bytes are produced:

$ timeout 0.5 /usr/sbin/haveged -n 0 -f - | xxd -p | grep "^0000"
haveged: command socket is listening at fd 3
Writing unlimited bytes to stdout
haveged: Cannot write data in file: Broken pipe
tot tests(BA8): A:1/1 B:1/1  last entropy estimate 8.0014
fills: 34, generated: 17 M bytes

$ dd if=/dev/random count=17 bs=1048576 | xxd -p | grep "^0000"
17+0 records in
17+0 records out
17825792 bytes (18 MB, 17 MiB) copied, 0.526188 s, 33.9 MB/s

Will these null bytes lead to a security issue when using such True Random Number Generators for generating keys for One-time pads?

  • 2
    $\begingroup$ Any run of any sequence of a particular size, even a run of zeros, has the same chance of occurring as any other run of the same size for outputs of a uniform and truly random generator. However, depending on how the term "true random" is meant, it is possible (even likely: crypto.stackexchange.com/questions/87358/…) that a source of true randomness is not also uniform, and therefore would be biased and not suitable as a one-time pad key. $\endgroup$
    – aiootp
    Jul 28, 2023 at 16:40
  • 1
    $\begingroup$ @aiootp That's why I always hash outputs of TRNGs with a secure and cryptographic hash function for producing keys for encryption, rather than using the TRNG directly for that. I know that output of /dev/random is mixed with the kernel CSPRNG, but kernel has been using CPU jittering since 5.4 and could be considered a form of TRNG (but I always use haveged for my stuff as I'm sure I'm using a TRNG. $\endgroup$
    – alpominth
    Jul 28, 2023 at 18:54

2 Answers 2



They happen naturally. And if they didn't, you should be worried as it would indicate that your generator isn't working properly.

If your generator is really random, all digits have an equal probability of occurring. You're showing hex, so 00 through ff each occurs with an expectation of $\frac{1}{256}$. 256 isn't a lot when compared with a megabyte of data, so that might occur twice consecutively, with an expectation of $\frac{1}{256^2}$. In 17 MB of stuff, you'd expect to see 0000 about 259 times +/- some. And statistics like this form the basis of some randomness tests like gaps and Chi squared.

For scary looking statistics (but not really), look up the run of 6 nines in the decimal expansion of Pi called the Feynman point.


No. Any byte value should have about the same probability, assuming a uniform distribution. If some kind of value, including a "null" byte with all the bits set to zero, is absent then you'd really be in trouble. Assuming a good distribution you'd have a 1/256 chance of hitting a "null" byte and then again a 1/256 chance of hitting another one.

As these bytes can be generated anywhere an attacker won't learn anything about the plaintext. Maybe you'd suspect that an adversary would be able to get some information if a pattern can be discerned. But remember that the XOR of a random byte in the key stream with another plaintext byte can generate the same pattern - or any other pattern for that matter.

If no zero bytes could be generated then you will actually leak data. For any byte that you'd find, you'd know that the plaintext message does not have that same value in that particular location. A non-zero byte in the key stream will always change the value after XOR after all.

If you want to test the distribution of your random number generator then you'd need to use a set of tests specifically designed for that such as the Diehard tests and derivatives. Beware that this won't indicate if the random number generator is secure, it can only indicate issues with the distribution.

  • $\begingroup$ I had to choose the other answer as helpful because there is no way to choose both as helpful, but your answer is great, I understood perfectly. Thank you very much. $\endgroup$
    – alpominth
    Jul 26, 2023 at 0:37
  • 2
    $\begingroup$ and the fact that a letter couldn't map to itself was a rather notable weakness of the Enigma machine $\endgroup$
    – ilkkachu
    Jul 26, 2023 at 12:25
  • 2
    $\begingroup$ Yeah, imagine using an OTP to send either "Yes" or "No!" and an adversary finds an 'N' as first letter. Then it can immediately determine that the message was "Yes". Seems bad enough to me. $\endgroup$
    – Maarten Bodewes
    Jul 26, 2023 at 12:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.