Re:Ruby Bug: SecureRandom should try /dev/urandom first
by Thiez on Wednesday May 04, 2016 @02:14AM
(#11626560)
Why not use a hardware rng in that case? Seems a lot safer if you have to deal with litigious people.
Re:Ruby Bug: SecureRandom should try /dev/urandom first
by sibrahim on Wednesday May 04, 2016 @09:49AM
(#11628300)
We did, in a way. One of the sources used was random.org (uses radio receivers tuned to static from atmospheric noise: hardware RNG as a service). I also had less than 3 weeks to take it from proposal to production.
Combining two independent sources obtained by different people and using a cryptographic commitment scheme ensured that 1) no one person could fix the results or make it nonrandom (protection against Eddie Tipton-style attacks), 2) if at least one of the independent sources was random, the result would be.
Re:Ruby Bug: SecureRandom should try /dev/urandom first
by netheril96 on Tuesday May 03, 2016 @10:38PM
(#11625790)
Then what CSPRNG do you use? Any that has seeds larger than 256-bit?
Re:Ruby Bug: SecureRandom should try /dev/urandom first
by sibrahim on Tuesday May 03, 2016 @11:26PM
(#11625941)
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.
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, the fact that there are widespread misconceptions about /dev/random can very rarely be a reason to use it :P
However, I agree that the rule is that you should just use /dev/urandom.