3 ms·

This article fails to explain why someone should explicitly reach for an RNG over PRNG. It also suggests os.urandom as a Python RNG which (as the name suggests

by wepple 3y ago

This article fails to explain why someone should explicitly reach for an RNG over PRNG. It also suggests os.urandom as a Python RNG which (as the name suggests) uses /dev/urandom or the getrandom() syscall, both of which are PRNGs

deleted 3y ago
[deleted]
gregmac 3y ago
What do you mean by just "RNG"? Hardware ("true")?
cbsmith 3y ago
> This article fails to explain why someone should explicitly reach for an RNG over PRNG. There aren't a lot of cases where you need to explicitly reach for a non-PRNG over a PRNG, and if you do need it, you most likely know it. What does often make a lot of sense is using a PRNG that is seeded from a non-PRNG. > It also suggests os.urandom as a Python RNG which (as the name suggests) uses /dev/urandom or the getrandom() syscall, both of which are PRNGs So, that's not ENTIRELY accurate. At least on Linux, while /dev/urandom uses a PRNG, but it is fed from the entropy pool. So unless you consume the entropy pool of a system, it has all the randomness of /dev/random. The difference is that /dev/random blocks when you run out of entropy, while /dev/urandom will just keep feeding output generated purely from the PRNG until more entropy becomes available. There are some notable exceptions, but in most cases pulling from /dev/urandom is the right choice.
- wepple 3y ago
  Sure, I maybe should’ve noted that. But my key point is that the article tells you that you should use an RNG (without reason) rather than a PRNG, but then ends up listing something that is an (RNG-initialized) PRNG in the RNG section. TL;DR he article has glaring inconsistencies and shouldn’t be regarded reliable
  - cbsmith 3y ago
    It was indeed a little... bizarre.
- tptacek 3y ago
  I don't think this "PRNG" vs. "RNG" distinction is doing us much good. There's no meaningful difference in the mechanics of how urandom and random serve unpredictable bits. There is also no such thing as "running out of entropy".
  - cbsmith 3y ago
    What do you interpret the output of `cat /proc/sys/kernel/random/entropy_avail` to mean?
    - tptacek 3y ago
      Nothing.
  - cryptonector 3y ago
    > There is also no such thing as "running out of entropy". Hear hear. There is, indeed, no such thing as running out of entropy in a modern PRNG's state. > I don't think this "PRNG" vs. "RNG" distinction is doing us much good. But it's still nice to seed and periodically reseed a PRNG w/ entropy from an RNG. So there is a distinction between PRNG and RNG to be made, and we should make it. What we really want is to always have an RNG-seeded PRNG, and to always use the PRNG not the RNG.
    - cbsmith 3y ago
      > Hear hear. There is, indeed, no such thing as running out of entropy in a modern PRNG's state. Yes, of course. PRNG's are about producing random data from a seed. But /dev/random & /dev/urandom isn't just a PRNG. > What we really want is to always have an RNG-seeded PRNG, and to always use the PRNG not the RNG. Which is effectively what is going on with /dev/random & /dev/urandom
      - tptacek 3y ago
        At the point where you're simply equating /dev/random and /dev/urandom, you're no longer really disagreeing with anybody here. The only difference between the two is that /dev/random keeps a metric on how many bits its vended, and blocks waiting for rekeying when that metric gets too high. That's more or less a nonsensical thing to do.
- jameswryan 3y ago
  /dev/random does not block when 'out of entropy'. 'Running out of entropy' isn't something that can happen, and /dev/random will only block if the RNG hasn't been initialized (short enough after boot to not matter). See Jason Donenfeld's authoritative talk on the Linux RNG for details: https://youtu.be/-_yzaSp2xtY https://youtu.be/-_yzaSp2xtY
  - cbsmith 3y ago
    I'll have to look at the talk, but I've had first hand experience with that behaviour from /dev/random. Perhaps it has changed over time.
  - cbsmith 3y ago
    I just checked the source code, and it appears that the entropy pool is alive and well and that /dev/random still waits for enough entropy to collect in the pool before providing more data for consumption. https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fad8606bee38f724594dc/drivers/char/random.c#L69 https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fa... The "wait_for_random_bytes" function is still there: https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fad8606bee38f724594dc/drivers/char/random.c#L132 https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fa...

by wepple 3y ago

deleted 3y ago

[deleted]

gregmac 3y ago

What do you mean by just "RNG"? Hardware ("true")?

cbsmith 3y ago

> This article fails to explain why someone should explicitly reach for an RNG over PRNG. There aren't a lot of cases where you need to explicitly reach for a non-PRNG over a PRNG, and if you do need it, you most likely know it. What does often make a lot of sense is using a PRNG that is seeded from a non-PRNG. > It also suggests os.urandom as a Python RNG which (as the name suggests) uses /dev/urandom or the getrandom() syscall, both of which are PRNGs So, that's not ENTIRELY accurate. At least on Linux, while /dev/urandom uses a PRNG, but it is fed from the entropy pool. So unless you consume the entropy pool of a system, it has all the randomness of /dev/random. The difference is that /dev/random blocks when you run out of entropy, while /dev/urandom will just keep feeding output generated purely from the PRNG until more entropy becomes available. There are some notable exceptions, but in most cases pulling from /dev/urandom is the right choice.

wepple 3y ago
Sure, I maybe should’ve noted that. But my key point is that the article tells you that you should use an RNG (without reason) rather than a PRNG, but then ends up listing something that is an (RNG-initialized) PRNG in the RNG section. TL;DR he article has glaring inconsistencies and shouldn’t be regarded reliable
- cbsmith 3y ago
  It was indeed a little... bizarre.
tptacek 3y ago
I don't think this "PRNG" vs. "RNG" distinction is doing us much good. There's no meaningful difference in the mechanics of how urandom and random serve unpredictable bits. There is also no such thing as "running out of entropy".
- cbsmith 3y ago
  What do you interpret the output of `cat /proc/sys/kernel/random/entropy_avail` to mean?
  - tptacek 3y ago
    Nothing.
- cryptonector 3y ago
  > There is also no such thing as "running out of entropy". Hear hear. There is, indeed, no such thing as running out of entropy in a modern PRNG's state. > I don't think this "PRNG" vs. "RNG" distinction is doing us much good. But it's still nice to seed and periodically reseed a PRNG w/ entropy from an RNG. So there is a distinction between PRNG and RNG to be made, and we should make it. What we really want is to always have an RNG-seeded PRNG, and to always use the PRNG not the RNG.
  - cbsmith 3y ago
    > Hear hear. There is, indeed, no such thing as running out of entropy in a modern PRNG's state. Yes, of course. PRNG's are about producing random data from a seed. But /dev/random & /dev/urandom isn't just a PRNG. > What we really want is to always have an RNG-seeded PRNG, and to always use the PRNG not the RNG. Which is effectively what is going on with /dev/random & /dev/urandom
    - tptacek 3y ago
      At the point where you're simply equating /dev/random and /dev/urandom, you're no longer really disagreeing with anybody here. The only difference between the two is that /dev/random keeps a metric on how many bits its vended, and blocks waiting for rekeying when that metric gets too high. That's more or less a nonsensical thing to do.
jameswryan 3y ago
/dev/random does not block when 'out of entropy'. 'Running out of entropy' isn't something that can happen, and /dev/random will only block if the RNG hasn't been initialized (short enough after boot to not matter). See Jason Donenfeld's authoritative talk on the Linux RNG for details: https://youtu.be/-_yzaSp2xtY https://youtu.be/-_yzaSp2xtY
- cbsmith 3y ago
  I'll have to look at the talk, but I've had first hand experience with that behaviour from /dev/random. Perhaps it has changed over time.
- cbsmith 3y ago
  I just checked the source code, and it appears that the entropy pool is alive and well and that /dev/random still waits for enough entropy to collect in the pool before providing more data for consumption. https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fad8606bee38f724594dc/drivers/char/random.c#L69 https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fa... The "wait_for_random_bytes" function is still there: https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fad8606bee38f724594dc/drivers/char/random.c#L132 https://github.com/torvalds/linux/blob/48b1320a674e1ff5de2fa...