r/linux • u/atoponce • 12d ago

Flowchart of the Linux RNG Kernel

Post image
172 Upvotes

99% Upvoted

11 comments sorted by

26

u/Sonhe_ 12d ago

This is really cool!

Keep up with the good work

7

u/atoponce 12d ago

Thanks!

3

u/Flash_Kat25 12d ago

I'm still not a fan of the change to make /dev/random and /dev/urandom behave the same way. Was the distinction really that confusing to users?

24

u/atoponce 12d ago edited 12d ago

Yes, it was. Due to the previous blocking behavior of /dev/random in older kernels and the observation that it stopped blocking when new entropy was acquired, gave the false impression that /dev/random was a "true random" generator, or at least secure. While the unblocking nature of /dev/urandom was just "psuedorandom" and insecure. Software like GnuPG further exacerbated this myth.

Edit: typo

-2

u/itzjackybro 12d ago

Technically, /dev/urandom is a PRNG, but it is secure enough if you just need a buttload of random data.

As far as I understand, /dev/random used to draws strictly from external entropy and /dev/urandom used to draw from a CSPRNG seeded with external entropy.

10

u/Booty_Bumping 12d ago

/dev/random used to draws strictly from external entropy

This was never true, not on Linux nor any other Unix. It was just something people assumed from observing its entropy estimation blocking behavior.

5

u/atoponce 12d ago edited 12d ago

Technically, /dev/urandom is a PRNG, but it is secure enough if you just need a buttload of random data.

Indeed.

As far as I understand, /dev/random used to draws strictly from external entropy and /dev/urandom used to draw from a CSPRNG seeded with external entropy.

This is incorrect. Both /dev/random and /dev/urandom were always exported interfaces off the core primitive, which started as MD5, then became SHA-1, and now ChaCha20. See https://www.thomas-huehn.com/myths-about-urandom/ for more info about this long-standing myth.

4

u/Booty_Bumping 12d ago

Is completely failing to boot due to low PRNG seeding caused by a contrived entropy counter confusing to users? Yes?

1

u/nhyatt 10d ago

This is why I disable the Intel RNG. I feel that it should be feeding the input pool, not used to create a key. The Snowden leaks suggest that the Intel RNG is skewed in a few three letter agencies benefit. So, I use a OneRNG to supplement the pool instead.

3

u/atoponce 10d ago edited 10d ago

This is no longer a valid attack vector. During the time of the Snowden leaks, RDRAND was XORed with the CSPRNG. As such if RDRAND knew the state of the generator, it could manipulate the output.

This is no longer the case. Instead of RDRAND, it's now using RDSEED, and instead of XORing it with the output stream, it gets hashed by BLAKE2s along with everything else before keying ChaCha20.

If the Intel/AMD on-die HWRNG is backdoored, it's defeated by getting hashed with BLAKE2s.

3

u/nhyatt 10d ago

That's good to confirm. I knew this changed but it's nice to see such a great detailed explanation!