Tracking issue for stabilizing randomness

[alexcrichton]

Long ago we had std::rand and nowadays we have extern crate rand. This is such core functionality it likely wants to move back into the standard library at some point, and in the meantime this issue serves as a tracking issue for the rand feature in the standard library.

The process for adding this functionality to the standard library will likely look like something along the lines of rust-lang/rfcs#1242.

cc @huonw

[nagisa]

rand is not even sure about algorithms implemented and AFAIR is having a major rewrite in works. I doubt it can go back into libstd anytime soon.

[aturon]

Nominating for discussion at libs meeting: we're not ready to stabilize anything here, but I'd like to discuss the plan.

[alexcrichton]

Unfortunately the libs team didn't get a chance to talk about this in terms of stabilization for 1.8, but I'm going to leave the nominated tag as I think we should chat about this regardless.

[briansmith]

Suggestions:

• Don't expose ChaChaRng through a std:: module. Some systems need to ensure that any cryptographic algorithm in use is certified, and making ChaChaRng part of the standard library would be counterproductive for them.
• Similar to how we can override allocators, provide a way to override the CSPRNG so that (a) the application can swap in a CSRNG that is known to be good according to its standards (see previous item), and (b) so that the applicaiton can swap in a CSPRNG that takes advantage of special knowledge the application has. For example, If the application is only going to be deployed on systems that have the getrandom syscall, then the application may wish to swap in an implementation that avoids the /dev/urandom fallback completely. This is especially the case for an application that wants to use seccomp-bpf to prevent the use of open/read/etc.
• Provide a mechanism separate from the Rng trait to fill a slice with (secure) random bytes. The Rng trait is very badly designed as it mixes all kinds of concerns that most applications don't have. This mixing causes trouble for some applications. For example, Rng has next_f32 and next_f64 methods, which means that it cannot be fully implemented on any system that does not have floating point support and/or which wants to avoid linking in the floating point libraries. This in turn means that such applications cannot use OsRng.

Obviously, I am biased, but I think a better API for a CSPRNG is the very simple one in ring: https://briansmith.org/rustdoc/ring/rand/index.html. This type of interface is sufficient for every use of a CSPRNG I've ever needed. Note that an implementation of an interface like Rng such as OsRng can easily be built on top of such an interface.

[briansmith]

Note that OsRng::gen_range and probably other methods are not generally safe because they don't take into account the fact that such random numbers should be generated without leaking information about the values of the random numbers. In particular, it would be tempting to use OsRng::gen_range to generate keys for public key operations using some bignum class, but AFAICT it wouldn't be safe since the comparison of the lower/upper bounds to the generated value isn't safe from timing side channels.

[briansmith]

More feedback: Currently rand::Rng::fill_bytes is defined to panic if it fails to generate the necessary random values, and there's no way to avoid those panics. Further, the panic behavior of other methods isn't specified but since they also don't use Result as their return type, they also have no choice other than to panic or abort the process.

For some applications, this is unacceptable. The interface should have results returned using Result.

However, it is also the case that some implementations may experience errors that they cannot avoid, so it may be worth allowing an implementation to panic or abort the process if it has no other choice on failure.

[SimonSapin]

However, it is also the case that some implementations may experience errors that they cannot avoid, so it may be worth allowing an implementation to panic or abort the process if it has no other choice on failure.

That’s Result::unwrap, right?

[briansmith]

However, it is also the case that some implementations may experience errors that they cannot avoid, so it may be worth allowing an implementation to panic or abort the process if it has no other choice on failure.
That’s Result::unwrap, right?

I'm assuming that the fill function is changed to return a Result<(), ()>. I'm saying that some implementations of fill might not be able to return Err(()) on failure because the function that they are implemented on top of calls abort on failure. For example, that would be the case if one used BoringSSL's RAND_bytes and an error occurred inside RAND_bytes. (This isn't a concern in ring, though.) It's still a good idea to have it return Result<(), ()> but this is something to consider.

[briansmith]

Just FYI, I outlined what I think such an API should look like at
https://briansmith.org/rustdoc/ring/rand/index.html, particularly https://briansmith.org/rustdoc/ring/rand/struct.SystemRandom.html.

[aneeshusa]

+1 from me on the design of SystemRandom from ring; it has the key property of simplicity which means that it's easy to use, that people will use it, and that it's hard to use incorrectly.

Ideal randomness APIs are infallible, for example OpenBSD's getentropy(2), or Linux's getrandom(2) with a wrapper. It would be nice to have an InfallibleRandom trait as well, where there is a fn fill_infallible or similar with no return value (e.g. always succeeds).