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

Ruby Bug: SecureRandom should try /dev/urandom first

bugs.ruby-lang.org

Post reply on HN
Print view View original

21–30 of 138 posts

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#21

Post by zaphar »

viraptor wrote: post #13
nitrogen wrote: post #10

Earlier quoted context omitted.

Why is there such a discrepancy between the prevailing sentiment on HN and the actions of whoever controls the manual? What is preventing one side from convincing the other, apart from stubbornness? Also, why are the Ruby devs so dead set on the manual page?

I have no answer to the first one. Since urandom is periodically reseeded, I believe tptacek and others - at least they provide arguments that justify their position. The other side seems to be just silent. As for "Also, why are the Ruby devs so dead set on the manual page?" - because it makes sense. If I didn't know much about random number generation, I'd rely on manuals and most widely adopted software. That means…

    would you listen to the docs or random-internet-person.
I mean given that scenario as you describe it yes, obviously you go with the docs. But these aren't random-internet people. These are the acknowledged experts in the field. If you are writing crypto related code and aren't familiar with these people then there is far more wrong here than just this bug.

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#22

Post by ryuuchin »

astrodust wrote: post #2

Is there a good random library that's not the giant ball of death that's OpenSSL?

As others have said it depends on your needs[6] and whether or not it has to be a CSPRNG (cryptographically secure). Since you mentioned OpenSSL I'll assume that in this context we are talking about a CSPRNG.

The short answer is to just use the OS provided one if available. Linux has /dev/urandom[1] and the getrandom[2] syscall and Windows has RtlGenRandom[3][4] (there's also CryptGenRandom on Windows which is the "official" version but is more awkward to use since it requires a CSP context to use). On Windows this uses AES-256 in CTR mode as specified in NIST 800-90.

Outside of those (if for whatever reason[6] you're not satisfied with just using what the OS provides you) you can also take a look at how BoringSSL does things[5] (and LibreSSL although I'm less familiar with it). It uses a ChaCha20 instance to filter rdrand output (if supported, otherwise it just uses the system CSPRNG directly). The system CSPRNG is used to key the ChaCha20 instance and then for every call to RAND_bytes it uses rdrand output equal to however many bytes you requested and that gets essentially filtered through the ChaCha20 instance. It's fast and pretty simple. I found the code to be pretty easy to understand[5]. I believe LibreSSL does something similar with ChaCha20 although I'm not sure it uses rdrand.

I think there should be a pretty good reason if you're choosing not to use what the OS provides for you.

tl;dr Just use /dev/urandom (or the getrandom syscall) on Linux and RtlGenRandom on Windows.

[1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random...

[2] http://man7.org/linux/man-pages/man2/getrandom.2.html

[3] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

[4] https://boringssl.googlesource.com/boringssl/+/master/crypto... (RtlGenRandom requires slightly special definitions to work).

[5] https://boringssl.googlesource.com/boringssl/+/master/crypto...

[6] There really isn't a "depending on your use case" decision to make. /dev/urandom (or RtlGenRandom) is the correct choice for all cases.

With that being said there may be two small caviats to that. Whether or not it has to be a CSPRNG and whether or not /dev/urandom (or RtlGenRandom) can provide the throughput which you require. In certain cases you may have to expand /dev/urandom with something like ChaCha20 if /dev/urandom is too slow (the BoringSSL devs mentioned that for AES-CBC IV generation on servers this can sometimes be the case, see [5] for the BoringSSL implementation).

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#23

Post by jhall1468 »

viraptor wrote: post #4

So once again, the man page for urandom creates more problems than solutions. ( https://bugzilla.kernel.org/show_bug.cgi?id=71211 )

Well, to be honest, this isn't the man page creating problems; this is the Ruby core team stubbornly refusing to fix a known problem. Using the man page as justification for their refusal is both stupid and weird. Who uses the Linux man page to determine their security?

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#24

Post by netheril96 »

sibrahim wrote: post #19
tptacek wrote: post #11

Earlier quoted context omitted.

It does not depend on your use case. The answer, in all cases, is just to use /dev/urandom.

I had a rather specialized case where it was the pragmatic choice (note, not technically required): running a lottery with potentially litigious losers. If you used a CSPRNG with a seed space smaller than the set of possible lottery outcomes, losers could argue (misleadingly, since we still couldn't feasibly bias the result) that not all outcomes were equally probable and try to get the results thrown out. That is, t…

Then what CSPRNG do you use? Any that has seeds larger than 256-bit?

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#25

Post by mintplant »

zaphar wrote: post #21
viraptor wrote: post #13

Earlier quoted context omitted.

I have no answer to the first one. Since urandom is periodically reseeded, I believe tptacek and others - at least they provide arguments that justify their position. The other side seems to be just silent. As for "Also, why are the Ruby devs so dead set on the manual page?" - because it makes sense. If I didn't know much about random number generation, I'd rely on manuals and most widely adopted software. That means…

would you listen to the docs or random-internet-person. I mean given that scenario as you describe it yes, obviously you go with the docs. But these aren't random-internet people. These are the acknowledged experts in the field. If you are writing crypto related code and aren't familiar with these people then there is far more wrong here than just this bug.

> these people

Which people? Could you please name some of them? Honest question - the only name I can think of right now is tptacek's, but I'm sure there are more.

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#26

Post by ryuuchin »

duaneb wrote: post #20
ryuuchin wrote: post #18

Earlier quoted context omitted.

Obligatory "How To Safely Generate A Random Number" link[1] that I always wind up posting in threads like these. There's also the getrandom syscall[2] which uses the /dev/urandom pool. [1] http://sockpuppet.org/blog/2014/02/25/safely-generate-random... [2] http://man7.org/linux/man-pages/man2/getrandom.2.html

Why are the man pages not so clear?

I'm not sure. I think part of the problem is that Linux still uses entropy estimation. This is also one of the issues I have with the proposed replacement[1][2] for Linux's current CSPRNG implementation since it still retains entropy estimations.

[1] https://lwn.net/Articles/684568/

[2] https://news.ycombinator.com/item?id=11561340 (HN thread for [1])

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#27

Post by Freaky »

JRuby uses Java's java.security.SecureRandom, which (by default on OpenJDK 8) uses /dev/random, mixed with its own SHA1PRNG (this so setSeed() can be guaranteed to actually do something).

Rubinius copies MRI circa 2014 via rubysl - https://github.com/rubysl/rubysl-securerandom

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#28

Post by sibrahim »

netheril96 wrote: post #24
sibrahim wrote: post #19

Earlier quoted context omitted.

I had a rather specialized case where it was the pragmatic choice (note, not technically required): running a lottery with potentially litigious losers. If you used a CSPRNG with a seed space smaller than the set of possible lottery outcomes, losers could argue (misleadingly, since we still couldn't feasibly bias the result) that not all outcomes were equally probable and try to get the results thrown out. That is, t…

Then what CSPRNG do you use? Any that has seeds larger than 256-bit?

Anything that reseeds during operation can qualify. In fact, if the CSPRNG's internal state isn't large enough, you need to periodically reseed or face the same objection.

But a CSPRNG which you need to explicitly seed with random bits as big as your output isn't providing much value (simply whitening) since generating the seed is the same problem you had before adding the CSPRNG. So you end up looking at a TRNG.

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#29

Post by meshko »

Well, I dunno what the man pages say and what some dudes on the internet say, but I know that on CentOS release 6.7 (Final) I need to run with -Djava.security.egd=file:///dev/urandom or else I can't connect to Oracle half the time because Java runs out of entropy. So there must still be some difference between /dev/random and /dev/urandom.

Re: Ruby Bug: SecureRandom should try /dev/urandom first

#30

Post by Perceptes »

This is sad and embarrassing for every involved party. The people leaving rude, entitled, hyperbolic comments in the thread, the Ruby developers who refuse to look into the best practice suggested by experts in the field, and the man page maintainer who refuses to update the man page in accordance with similar information.
Post reply on HN