1

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
000010aa8070250869b3727f3f30cf87ae9554207180928e3e638bb58efe
0000677b49156973346bd9d9e358ca920755a519230a0e2f3d6b439f71d9
0000ed51605a0e206446bd737457001211fc6a814f8832332b88469cb3c7
0000ae23e86df2bf0f03ace1118d856ee8fd0a7463fab6cbdcd8e3d099b6
00001edb399387ff591f7a420ee82a8751867e5c8edf2125e05d2d5d250e
0000f87db11a116804f89a35a189d195da50c759c1f4e4a03a9ce6468b18
00000c6ba62c31b71e7b15d1bf304925f685d3b30360470d505c9420f2bd
0000602f9e6c806d23ad022ab17df08acd11d73944eec624a671876d9fc6
0000572a7354b3a70f585555f2182f8c6cddde3acc4c3c947b1d2ec382a2
000095da4783a1f05aabc15bf8b5c79975d25e7377309ef597d8b3f6a49e
0000dba25749bbd71dcf5c95500178a33dbdbb9aba4c6ede09426fdc4dfd
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
Terminated

$ dd if=/dev/random count=17 bs=1048576 | xxd -p | grep "^0000"
0000326e441a952ef9de3542b18c008c65b151cf1641e3b792cbb77cd3ef
0000c242f1595a6ce38a9777e2990a6fd0d71af9ada4fdffd3cb2820ee52
0000fdb5a2f36d85a0cd1ba9274de0c2b670abfe3ed2d0c5e4c671352bcf
000037827ad0a6c44b07579546fc88c6284ab401bbc0931346e8d501c3a6
000096003d2ad58a468c872251685f476fea267836bed4e09ea94fb8816a
0000dbb9d26482c9cfa9af1e7839495cc347a69efaa75dc3e46bc1d53cca
00006e038b645e4628f1417edaf324d457a3d08fa663724fa406283160e7
0000774a1a0f2c461d409472adc492bc523cb2859b1eadd04d3f30b65e8a
0000936f8e7607e20dafc5abe806e9b206322adac48c2bf5c7774cb93baf
000008d7d3971bb556907d7b2f4b5292cf72415c075056a8f31cf3d36343
00005f6feac2673599e0f5ee12c6f713fdaaeeccb40efda12d4d918a70d7
0000869eba5fe865c6dcd84e5c835bf05820499511e6b762652a0dc3aaac
0000b4e4fea5ab9d736661dc57028aad7717a02808ae04d84ae3fc34ed1d
0000b930406298421322f7fa683b055a151485ddd524a9d7662263c6f369
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?

alpominth
  • 393
  • 2
  • 10
  • 2
    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: https://crypto.stackexchange.com/questions/87358/radioactive-decay-gaussian-or-uniform#comment191761_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. – aiootp Jul 28 '23 at 16:40
  • 1
    @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. – alpominth Jul 28 '23 at 18:54

2 Answers2

7

Nope.

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.

Paul Uszak
  • 15,390
  • 2
  • 28
  • 77
4

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.

DannyNiu
  • 9,207
  • 2
  • 24
  • 57
Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • 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. – alpominth Jul 26 '23 at 00:37
  • 2
    and the fact that a letter couldn't map to itself was a rather notable weakness of the Enigma machine – ilkkachu Jul 26 '23 at 12:25
  • 2
    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. – Maarten Bodewes Jul 26 '23 at 12:31