Ruby Bug: SecureRandom should try /dev/urandom first

Re:Ruby Bug: SecureRandom should try /dev/urandom first by caf on Wednesday May 04, 2016 @01:27AM (#11626406)

/dev/urandom is a shared resource across all processes, and that implies locking/synchronization that can run you into scalability issues if you are trying to generate a large volume of random numbers in parallel on multiple cores.

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by ryuuchin on Wednesday May 04, 2016 @01:41AM (#11626464)

> trying to generate a large volume of random numbers in parallel on multiple cores

You may be better off just using rdrand directly in this case depending on the throughput required. AFAIK you should be able to saturate all logical threads generating random numbers with rdrand and the DRNG (digital RNG) still won't run out of entropy.

Or as I also suggested look into expanding /dev/urandom output using a ChaCha20 instance like what BoringSSL does (which also combines it with rdrand since it's fast).

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by derefr on Wednesday May 04, 2016 @03:43AM (#11626832)

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.

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by caf on Wednesday May 04, 2016 @05:59AM (#11627279)

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

[ Parent | on HN ]

Re:Ruby Bug: SecureRandom should try /dev/urandom first by ryuuchin on Thursday May 05, 2016 @05:12PM (#11639697)

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.

[ Parent | on HN ]