Talk:Non-physical true random number generator: Difference between revisions

Line 20: Line 20:

:::::One of the big changes in 5.17 and 5.18 is properly implementing fast-key-erasure with ChaCha20. After the entropy pool is mixed with SipHash, it keys ChaCha20. When a request is made to the CSPRNG, one extra block is generated that reseeds the entropy pool, which eventually rekeys ChaCha20. See https://blog.cr.yp.to/20170723-random.html for more info on how that works.

:::::Let me know if you have more questions. I’ve been working on a document that outlines many of the critical changes random.c has made over the years. I’ve downloaded the source code for every kernel version and read random.c directly, if you’re interested. [[User:Atoponce|atoponce]] ([[User talk:Atoponce|talk]]) 18:28, 30 October 2025 (UTC)

::::::I do not understand your reasoning at all. Here is the text that you {{diff|Non-physical_true_random_number_generator|diff=prev|oldid=1319419745|label=have deleted}}: {{tq|For example, in Linux, the /dev/random requires true random seed (and thus can block when it needs to collect more entropy, e.g., at boot time), while /dev/urandom will always provide more bits and is non-blocking.{{sfn | Schindler | 2008 | pp=18-19}}{{sfn | Everspaugh | Zhai | Jellinek | Ristenpart | 2014 | p=560}}}}.

::::::This text does not contain “myths” listed by you:

::::::# {{tq|myths about /dev/random being secure and /dev/urandom being insecure}}. In the deleted text, there is discussion of security of these devices;

::::::# {{tq|To give you a brief history}}. In the deleted text, there was no description of the history. It seems to be irrelevant to the text discussed. I suggest to limit the discussion to the current kernel 6.1x.

::::::Here is the link to the code I would prefer us to discuss: [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v6.18-rc3]. The comments in the header clearly state: {{tq|The high level overview is that there is one input pool, into which various pieces of data are hashed. Prior to initialization, some of that data is then “credited” as having a certain number of bits of entropy. When enough bits of entropy are available, the hash is finalized and handed as a key to a stream cipher that expands it indefinitely for various consumers.}} Comments slightly past the line 100 state that [crng_ready] {{tq|Returns whether or not the input pool has been seeded and thus guaranteed to supply cryptographically secure random numbers}}. Comments slightly past the line 120 state that: [wait_for_random_bytes] {{tq|Wait for the input pool to be seeded and thus guaranteed to supply}}. This function contains a loop that is very clearly blocking, invoking ”wait_event_interruptible_timeout” that puts the caller to sleep.

::::::Getting slightly past the line 1350: {{tq|Reading from /dev/random has the same functionality as calling getrandom(2) with <nowiki>flags=0</nowiki>}} and {{tq|Reading from /dev/urandom has the same functionality as calling getrandom(2) with <nowiki>flags=GRND_INSECURE</nowiki>}} Now looking into the body of getrandom function about 10 lines below these comments, we can clearly see (boldface is mine):

::::::<code>”’if”’ (!”’crng_ready”'() && !(flags & ”’GRND_INSECURE”’)) { … ret=””‘wait_for_random_bytes”'() … }</code>

::::::It seems that the process is exactly by the books: entropy is accumulated and used as a seed to CSPRNG, if dev/random is accessed prior to sufficient entropy obtained, the caller process will be blocked, read from dev/urandom will never block. My text you have deleted does not contradict this <u>at all</u>. Now that we have just established using (in this hard way) that the 2025 publication by <u>very reputable</u> researchers (note [[Joan Daemen]] among the authors above!) indeed does not lie about the modern Linux kernel, can you please restore the text? Thank you in advance!

::::::{{reflist-talk}} [[User:Dimawik|Dimawik]] ([[User talk:Dimawik|talk]]) 08:48, 1 November 2025 (UTC)

@Atoponce: I do not understand this edit. The comment was Linux /dev/random has always been a deterministic CSPRNG, but the /dev/random article talks about entropy pool as part of the design (and as far as I know, the pool in the good old times used to be a NPTRNG). Perhaps, the deleted sourced statement was correct? Dimawik (talk) 08:42, 23 September 2025 (UTC)[reply]

The Linux CSPRNG is not a hardware non-deterministic bit generator. If fed identical input, it will produce the predictable output. In fact, the Linux CSPRNG is problematic on systems with little to no entropy, such as virtual machines and embedded systems. It must be fed entropy from an external source, like an HWRNG in these situations to prevent producing predictable output. atoponce (talk) 12:51, 25 September 2025 (UTC)[reply]

To the best of my knowledge, Linux kernel on a PC scavenges for entropy in a classical NPTRNG fashion. I never bothered to look into the code, but the process is well-documented:

“

In Linux, the ‘random.c’ driver is the main component involved in the generation of random numbers. This driver is responsible for collecting entropy from various sources, such as hardware interrupts, system events, and user input. It then accumulates this entropy into pools, which are used to generate random values

”

see Bouez, Alexandre; Daemen, Joan; Mennink, Bart (2025). “Statistical Evaluation of Entropy Accumulation in Linux”. 2025 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE: 600–612. doi:10.1109/EUROSPW67616.2025.00075. Dimawik (talk) 22:10, 25 September 2025 (UTC)[reply]

No objections for 1 month. Restored. Dimawik (talk) 18:35, 28 October 2025 (UTC)[reply]

@Atoponce: Let’s discuss the sources on this page instead of reverting the changes (I waited for a month for you to respond before proceeding). Your comment to the last revert does not appear to be correct: the kernel documentation clearly states that dev/random does wait for entropy and can block, see any random(4) documentation, my source listed above, or the one in the article. Please provide some source for your claim. Dimawik (talk) 23:12, 29 October 2025 (UTC)[reply]

@Dimawik:First, regarding the myths about /dev/random being secure and /dev/urandom being insecure, this post was written back in 2014 to remove the myths about the two: https://www.2uo.de/myths-about-urandom/. See also this post by security researcher Thomas Ptacek: https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/.

To give you a brief history, Linux introduced random.c to the world with version 1.3 in 1994 and used MD5 as the core primitive for the CSPRNG. Both /dev/random and /dev/urandom got data from MD5, the only difference being that /dev/random would stop reading when the estimation of available entropy was less than the read request. Entropy was collected via interrupt events (network, keyboard, mouse, disk, etc). Entropy was then mixed with an LCG then hashed with MD5. In version 2.1, MD5 was replaced with SHA-1, but the core behavior with entropy collection and /dev/random and /dev/urandom remained the same. SHA-1 was replaced with ChaCha20 in 4.8, again preserving the behavior of blocking /dev/random and /dev/urandom. The LCG mixer was replaced with a number of different approaches, including an implementation of Skein by Bruce Schneier. Now it’s SipHash.

It’s important to understand though that both devices always pulled from the CSPRNG. /dev/random’s blocking behavior gave the false idea that it was a “true random number generator” and that /dev/urandom was an “insecure pseudorandom number generator” when neither were true. Since 1.3, both are valid implementations of a cryptographically secure pseudorandom number generator producing data indistinguishable from white noise.

Second, regarding removing the blocking pool from the CSPRNG, Linux Weekly News was the first to report on it https://lwn.net/Articles/808575/. The commit was made to remove this behavior landed in in version 5.6: https://lore.kernel.org/lkml/20200131204924.GA455123@mit.edu/. You can test this yourself. On a Linux system with a kernel newer than 5.6, execute “xxd /dev/random” and watch it provide an endless supply of data. Get on an earlier system, and watch the exact command block. IE, version 5.6 and later no longer blocks.

Finally, kernel developer Jason Donenfeld introduced a lot of new improvements with versions 5.17 and 5.18, including reworking the entropy pool and how the CSPRNG is keyed. Not only is the blocking behavior gone, but now the entropy is always 256 bits. Execute “cat /proc/sys/kernel/random/entropy_avail” on any system 5.19 or newer (I currently have 6.16 installed). No matter how many calls you make to /dev/random, that estimation will never drop. See https://www.zx2c4.com/projects/linux-rng-5.17-5.18/.

One of the big changes in 5.17 and 5.18 is properly implementing fast-key-erasure with ChaCha20. After the entropy pool is mixed with SipHash, it keys ChaCha20. When a request is made to the CSPRNG, one extra block is generated that reseeds the entropy pool, which eventually rekeys ChaCha20. See https://blog.cr.yp.to/20170723-random.html for more info on how that works.

Let me know if you have more questions. I’ve been working on a document that outlines many of the critical changes random.c has made over the years. I’ve downloaded the source code for every kernel version and read random.c directly, if you’re interested. atoponce (talk) 18:28, 30 October 2025 (UTC)[reply]

I do not understand your reasoning at all. Here is the text that you have deleted: For example, in Linux, the /dev/random requires true random seed (and thus can block when it needs to collect more entropy, e.g., at boot time), while /dev/urandom will always provide more bits and is non-blocking..

This text does not contain “myths” listed by you:

myths about /dev/random being secure and /dev/urandom being insecure. In the deleted text, there is discussion of security of these devices;
To give you a brief history. In the deleted text, there was no description of the history. It seems to be irrelevant to the text discussed. I suggest to limit the discussion to the current kernel 6.1x.

Here is the link to the code I would prefer us to discuss: [1]. The comments in the header clearly state: The high level overview is that there is one input pool, into which various pieces of data are hashed. Prior to initialization, some of that data is then “credited” as having a certain number of bits of entropy. When enough bits of entropy are available, the hash is finalized and handed as a key to a stream cipher that expands it indefinitely for various consumers. Comments slightly past the line 100 state that [crng_ready] Returns whether or not the input pool has been seeded and thus guaranteed to supply cryptographically secure random numbers. Comments slightly past the line 120 state that: [wait_for_random_bytes] Wait for the input pool to be seeded and thus guaranteed to supply. This function contains a loop that is very clearly blocking, invoking wait_event_interruptible_timeout that puts the caller to sleep.

Getting slightly past the line 1350: Reading from /dev/random has the same functionality as calling getrandom(2) with flags=0 and Reading from /dev/urandom has the same functionality as calling getrandom(2) with flags=GRND_INSECURE Now looking into the body of getrandom function about 10 lines below these comments, we can clearly see (boldface is mine):

if (!crng_ready() && !(flags & GRND_INSECURE)) { ... ret = wait_for_random_bytes() ... }

It seems that the process is exactly by the books: entropy is accumulated and used as a seed to CSPRNG, if dev/random is accessed prior to sufficient entropy obtained, the caller process will be blocked, read from dev/urandom will never block. My text you have deleted does not contradict this at all. Now that we have just established using (in this hard way) that the 2025 publication by very reputable researchers (note Joan Daemen among the authors above!) indeed does not lie about the modern Linux kernel, can you please restore the text? Thank you in advance!

References

Dimawik (talk) 08:48, 1 November 2025 (UTC)[reply]

Must Read

Leave a Comment Cancel Reply

Leave a Comment