Investigate replacing the ISAAC Rng with directly using the operating system, or an eSTREAM Rng (etc.)

[huonw]

Non-exhaustive list of possible candidates:

• operating system (i.e. /dev/urandom or GenCryptRandom)
• eSTREAM family
• ChaCha family
• Salsa20

Important considerations:

• performance
• statistical/cryptographic strength
• how far into the realm of cryptography do we want to go? (Not very far, but implementing an PRNG isn't as hard to get correct/test as other areas of cryptography, since (a) its output can be compared byte-for-byte with a known-correct implementation and (b) RNGs (for the most part) lacks some subtle constraints like constant time equality and other side channel attacks that other cryptographic algorithms require.)

The ISAAC Rng currently implemented in std::rand has some known weaknesses, but is generally accepted as cryptographically secure (although it has not received a huge amount of scrutiny).

[pcwalton]

+1 on just using the OS. With the exception of Colin Percival, cryptographers universally tell us to do this.

[brson]

I don't have a strong opinion about this as long as it remains fast, but there is a consideration here that if we do this the algorithm our CSPRNG uses will be platform-specific. There may be some value in being able to know that "Rust's CSPRNG is ISAAC", etc.

[thestinger]

@pcwalton: The benefit of using a modern stream cipher would be removing the temptation of having non-cryptographic RNG implementations like a Mersenne twister implementation. I don't think it would be good if creating a hash table always required a system call or a lock (for a buffer).

[brson]

Here's an article about the poor multithreaded performance of /dev/urandom on Linux: http://drsnyder.us/2014/04/16/linux-dev-urandom-and-concurrency.html

[JustAPerson]

One interesting comment from that article, by Theodore Ts'o:

Then hopefully curl is using /dev/urandom to initialize its own userspace RNG (many crypto libraries do this; most should do this), so you're not trying to read from /dev/urandom for every single request. /dev/urandom is designed for security, not for speed.

It should be noted that he is the original author of /dev/random

[steveklabnik]

@huonw what do you think of this ticket today? I feel like our RNG story is pretty solid at this point.

[joshtriplett]

Switching to the OS RNG (/dev/urandom) doesn't seem like it provides significant value. However, if Rust wants to consider switching to a platform-specific RNG to gain performance (which seems reasonable if the user hasn't explicitly used a seeded RNG to get reproducible result, such as for a game with replays), then several possibilities seem worth investigating, such as the use of hardware random number generators like rdrand when available. Those would provide a major performance improvement for any high-volume use of randomness.

[aturon]

Closing; this would want an RFC these days, I think.