Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Myths about /dev/urandom (2014)

2uo.de

Post reply on HN
Print view View original

21–30 of 70 posts

Re: Myths about /dev/urandom (2014)

#21

Post by canhascodez »

Taniwha wrote: post #13
Taniwha wrote: post #5

(disclaimer I sell a HW random number generator) I think both the diagrams here are simplistic - in reality pre 4.8 there were 3 pools (an input pool and 2 output pools, one of which blocked) and post 4.8 where there are 2 pools, an input pool and a blocking pool (urandom now pulls from the input pool thru a CSPRNG). One big downside of the new (post 4.8) architecture is that urandom_min_reseed_secs is ignored - pre-…

BTW - a tiny bit of python to keep /dev/urandom fed post 4.8 - useful if you have a hardware RNG (either an external one or the one in your CPU): #! /usr/bin/python # # OneRNG /dev/urandom tickler # (C) Copyright Paul Campbell Moonbase Otago 2018 # Released under a GPL 3.0 license # import time with open("/dev/random", 'rb') as r: while True: with open("/proc/sys/kernel/random/entropy_avail", 'r') as e: iv = e.read()…

Ruby version:

  #!/usr/bin/env ruby

  source = File.open('/dev/random', 'rb')

  loop do
    source.read(1000) unless File.read('/proc/sys/kernel/random/entropy_avail').to_i

Re: Myths about /dev/urandom (2014)

#22

Post by cuspycode »

Taniwha wrote: post #13
Taniwha wrote: post #5

(disclaimer I sell a HW random number generator) I think both the diagrams here are simplistic - in reality pre 4.8 there were 3 pools (an input pool and 2 output pools, one of which blocked) and post 4.8 where there are 2 pools, an input pool and a blocking pool (urandom now pulls from the input pool thru a CSPRNG). One big downside of the new (post 4.8) architecture is that urandom_min_reseed_secs is ignored - pre-…

BTW - a tiny bit of python to keep /dev/urandom fed post 4.8 - useful if you have a hardware RNG (either an external one or the one in your CPU): #! /usr/bin/python # # OneRNG /dev/urandom tickler # (C) Copyright Paul Campbell Moonbase Otago 2018 # Released under a GPL 3.0 license # import time with open("/dev/random", 'rb') as r: while True: with open("/proc/sys/kernel/random/entropy_avail", 'r') as e: iv = e.read()…

Do you have a gist or similar link for this code? Copy & paste doesn't work due to indentation issues.

Re: Myths about /dev/urandom (2014)

#23

Post by kragormonkey »

Scaevolus wrote: post #17
matbess wrote: post #16

This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here: If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?

Because Theodore Ts'o, a major Linux contributor and maintainer, created and maintains /dev/random and blocks attempts to make it nonblocking like every other cryptographically secure random source. It's a political problem, not a technical one. See https://news.ycombinator.com/item?id=6550256 for a much longer argument about it.

I don't see how this is political. In that link he presents actual problems that have arisen from non-blocking versions. I'd call that a technical justification.

I don't necessarily agree with his justification, but that's also a difference in technical opinion. The only way I'd fault him is if I can come up with a an approach that addresses his concerns yet he still refuses to accept them.

Full disclosure: I've actually interacted with him on a few occasions. IMO calling him risk/change-averse would be an understatement, which partly explains this stance. While at times frustrating for us, this is exactly the quality you want in someone maintaining such a critical part of the kernel.

Re: Myths about /dev/urandom (2014)

#24

Post by acqq »

Taniwha wrote: post #13
Taniwha wrote: post #5

(disclaimer I sell a HW random number generator) I think both the diagrams here are simplistic - in reality pre 4.8 there were 3 pools (an input pool and 2 output pools, one of which blocked) and post 4.8 where there are 2 pools, an input pool and a blocking pool (urandom now pulls from the input pool thru a CSPRNG). One big downside of the new (post 4.8) architecture is that urandom_min_reseed_secs is ignored - pre-…

BTW - a tiny bit of python to keep /dev/urandom fed post 4.8 - useful if you have a hardware RNG (either an external one or the one in your CPU): #! /usr/bin/python # # OneRNG /dev/urandom tickler # (C) Copyright Paul Campbell Moonbase Otago 2018 # Released under a GPL 3.0 license # import time with open("/dev/random", 'rb') as r: while True: with open("/proc/sys/kernel/random/entropy_avail", 'r') as e: iv = e.read()…

GPL 3.0 for a few obvious lines seems to be really an unfitting license.

Non-licensed English language version, containing the same information:

Once per second, read /proc/sys/kernel/random/entropy_avail and if the resulting number is more than 1500 perform a read of 1000 bytes from /dev/random.

Re: Myths about /dev/urandom (2014)

#25

Post by paavoova »

Taniwha wrote: post #13
Taniwha wrote: post #5

(disclaimer I sell a HW random number generator) I think both the diagrams here are simplistic - in reality pre 4.8 there were 3 pools (an input pool and 2 output pools, one of which blocked) and post 4.8 where there are 2 pools, an input pool and a blocking pool (urandom now pulls from the input pool thru a CSPRNG). One big downside of the new (post 4.8) architecture is that urandom_min_reseed_secs is ignored - pre-…

BTW - a tiny bit of python to keep /dev/urandom fed post 4.8 - useful if you have a hardware RNG (either an external one or the one in your CPU): #! /usr/bin/python # # OneRNG /dev/urandom tickler # (C) Copyright Paul Campbell Moonbase Otago 2018 # Released under a GPL 3.0 license # import time with open("/dev/random", 'rb') as r: while True: with open("/proc/sys/kernel/random/entropy_avail", 'r') as e: iv = e.read()…

entropy_avail returns bits of entropy to a maximum of 4096(?), but this reads 1000 bytes. Why check if it's greater than 1500 if you're going to use it all anyway? Am I missing something here?

Re: Myths about /dev/urandom (2014)

#26

Post by mkup »

matbess wrote: post #16

This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here: If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?

In FreeBSD, /dev/random = /dev/urandom. But in Linux, there's a difference.

Re: Myths about /dev/urandom (2014)

#27

Post by vbezhenar »

matbess wrote: post #16

This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here: If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?

/dev/random is more secure than /dev/urandom because it blocks if there's not enough entropy. So if you want to generate private key, you should use /dev/random or you risk getting weak keys.

Re: Myths about /dev/urandom (2014)

#28

Post by ChrisSD »

Taniwha wrote: post #5

(disclaimer I sell a HW random number generator) I think both the diagrams here are simplistic - in reality pre 4.8 there were 3 pools (an input pool and 2 output pools, one of which blocked) and post 4.8 where there are 2 pools, an input pool and a blocking pool (urandom now pulls from the input pool thru a CSPRNG). One big downside of the new (post 4.8) architecture is that urandom_min_reseed_secs is ignored - pre-…

Does increasing the rate of external entropy risk swamping the system generated entropy? I.e. if the external source is compromised could this also compromise urandom such that the results could become predictable?

Re: Myths about /dev/urandom (2014)

#29

Post by nothrabannosir »

acqq wrote: post #24
Taniwha wrote: post #13

Earlier quoted context omitted.

BTW - a tiny bit of python to keep /dev/urandom fed post 4.8 - useful if you have a hardware RNG (either an external one or the one in your CPU): #! /usr/bin/python # # OneRNG /dev/urandom tickler # (C) Copyright Paul Campbell Moonbase Otago 2018 # Released under a GPL 3.0 license # import time with open("/dev/random", 'rb') as r: while True: with open("/proc/sys/kernel/random/entropy_avail", 'r') as e: iv = e.read()…

GPL 3.0 for a few obvious lines seems to be really an unfitting license. Non-licensed English language version, containing the same information: Once per second, read /proc/sys/kernel/random/entropy_avail and if the resulting number is more than 1500 perform a read of 1000 bytes from /dev/random.

(this is more of a tangential licensing PSA, since we're on the subject)

Not licensing something is, ironically, restrictive. If you want to release to public domain (or equivalent), you have to explicitly mention that. E.g. by licensing under CC0.

Otherwise, default copyright and "all rights reserved" applies.

https://creativecommons.org/share-your-work/public-domain/cc...

(But, IMO, nothing wrong with publicizing use of GPL 3! :) thanks either way to both)

Re: Myths about /dev/urandom (2014)

#30

Post by John_KZ »

Scaevolus wrote: post #17
matbess wrote: post #16

This article naturally leads to a question that I didn’t see addressed, perhaps you can answer it here: If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?

Because Theodore Ts'o, a major Linux contributor and maintainer, created and maintains /dev/random and blocks attempts to make it nonblocking like every other cryptographically secure random source. It's a political problem, not a technical one. See https://news.ycombinator.com/item?id=6550256 for a much longer argument about it.

Why should it be made non-blocking? If you want a large string with little entropy just use /dev/urandom. The political/dogmatic argument is that is should be made non-blocking. The process of acquiring entropy in typical computers is definitely blocking.
Post reply on HN