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

131–138 of 138 posts

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

#131

Post by lmm »

tptacek wrote: post #115
lmm wrote: post #105

Earlier quoted context omitted.

It must be possible for a computer to simply not have an adequate supply of randomness though, no? Sure, urandom will use hardware sources of randomness if they're available - but what if they're not?

No, this is a misconception. Once the LRNG is seeded , it can generate a more or less unbounded amount of high-quality random bytes from that seed. Entropy can't be "depleted".

Then how can a 4096-byte key be meaningfully safer than a 1024-byte key? Couldn't you just use the 1024-byte key to seed a RNG, generate a 4096-byte key from that, and have 4096-byte safety?

(Also what if the linux RNG isn't seeded e.g. in a VM scenario? Or is the answer just "don't do that"?)

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

#132

Post by forgotpwtomain »

dchest wrote: post #97
forgotpwtomain wrote: post #80

Earlier quoted context omitted.

Do you have a citation you can provide? I don't know of any research that has shown a significant weakness in ISAAC.

Why would you use a PRNG with unknown cryptographic properties, not designed by a cryptographer, as opposed to one of the NIST's DRBG or a good stream cipher, such as ChaCha? Weakness: https://eprint.iacr.org/2006/438 — "huge subsets of internal states which induce a strongly non-uniform distribution in the 8192 first bits produced" Finally, why is deterministic PRNG suggested as a replacement for OpenSSL's random nu…

> as opposed to one of the NIST's DRBG

I certainly wouldn't go anywhere near another NIST DRBG..

> https://eprint.iacr.org/2006/438

From my brief understanding Aumasson's paper uses a different seeding routine from the example provided in the c implementation which allows the weaker states to be produced - indeed it's mentioned on the author's website.

> Finally, why is deterministic PRNG suggested as a replacement for OpenSSL's random number generator? In general, the advice to write your own userspace PRNG replacement for OpenSSL is not a good advice, because many people are not competent enough to do it.

If you read my above post I clearly do not suggest this.

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

#133

Post by ryuuchin »

caf wrote: post #79
derefr wrote: post #69

Earlier quoted context omitted.

I'm surprised there's no talk of essentially making reads from /dev/urandom occur via a VDSO that grabs a seed for each process from the common pool, and then runs entropy generation from then on in the process's address space.

You really want a separate instance of the CSPRNG per thread, not per process.

You can also use the hw rng if supported (e.g. rdrand) for fork/VM duplication safety. /dev/urandom should be fork safe though so long as you're not buffering data from it.

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

#134

Post by dchest »

forgotpwtomain wrote: post #132
dchest wrote: post #97

Earlier quoted context omitted.

Why would you use a PRNG with unknown cryptographic properties, not designed by a cryptographer, as opposed to one of the NIST's DRBG or a good stream cipher, such as ChaCha? Weakness: https://eprint.iacr.org/2006/438 — "huge subsets of internal states which induce a strongly non-uniform distribution in the 8192 first bits produced" Finally, why is deterministic PRNG suggested as a replacement for OpenSSL's random nu…

> as opposed to one of the NIST's DRBG I certainly wouldn't go anywhere near another NIST DRBG.. > https://eprint.iacr.org/2006/438 From my brief understanding Aumasson's paper uses a different seeding routine from the example provided in the c implementation which allows the weaker states to be produced - indeed it's mentioned on the author's website. > Finally, why is deterministic PRNG suggested as a replacement f…

> I certainly wouldn't go anywhere near another NIST DRBG..

OK, this is an instant red-flag to me to get out of the conversation.

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

#135

Post by lmm »

cwyers wrote: post #110
lmm wrote: post #85

Earlier quoted context omitted.

I think it would be entirely reasonable for the person maintaining a Ruby binding for sqlite to follow the sqlite documentation and close any bugs telling them to go against that documentation, yes.

It goes against the Linux kernel documentation, yes. As has been pointed out to them, it doesn't go against the documentation on OS X or any of the BSDs. But they engage in the same behavior on those systems.

Well, perfectly reasonable to take the intersection of capabilities rather than special-case each platform. AIUI the behaviour of /dev/urandom and /dev/random is the same on OSX and *BSD, so there's no problem with their behaviour there.

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

#136

Post by forgotpwtomain »

dchest wrote: post #134
forgotpwtomain wrote: post #132

Earlier quoted context omitted.

> as opposed to one of the NIST's DRBG I certainly wouldn't go anywhere near another NIST DRBG.. > https://eprint.iacr.org/2006/438 From my brief understanding Aumasson's paper uses a different seeding routine from the example provided in the c implementation which allows the weaker states to be produced - indeed it's mentioned on the author's website. > Finally, why is deterministic PRNG suggested as a replacement f…

> I certainly wouldn't go anywhere near another NIST DRBG.. OK, this is an instant red-flag to me to get out of the conversation.

> OK, this is an instant red-flag to me to get out of the conversation.

Perhaps you are unfamiliar with? https://en.wikipedia.org/wiki/Dual_EC_DRBG

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

#137

Post by dchest »

forgotpwtomain wrote: post #136
dchest wrote: post #134

Earlier quoted context omitted.

> I certainly wouldn't go anywhere near another NIST DRBG.. OK, this is an instant red-flag to me to get out of the conversation.

> OK, this is an instant red-flag to me to get out of the conversation. Perhaps you are unfamiliar with? https://en.wikipedia.org/wiki/Dual_EC_DRBG

I'm familiar with it. CTR DRBG, Hash DRBG, HMAC DRBG are all fairly solid designs.

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

#138

Post by meshko »

ascorbic wrote: post #63
meshko wrote: post #29

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.

Nobody's claiming there's no difference between /dev/random and /dev/urandom. They're just saying you should always use /dev/urandom.

Not sure what up with all the downvotes. I'm just saying that Java defaults to /dev/random and Java is kind of a big and important and all that, so not sure why everyone is giving crap to poor little Ruby about this.
Post reply on HN