"Not a crypto library" warning is confusing

[dcmiddle]

I've seen a few projects use rand in security sensitive code. A reviewer may eventually point them to this warning in the book: https://github.com/rust-random/book/blame/master/src/guide-rngs.md#L263-L271 Inferring that rand does not provide cryptographically secure prngs and they should use a different random library.

That warning was added ~5 years ago. However in what looks like the same commit there's a section on Cryptographically secure pseudo-random number generators (CSPRNGs). https://github.com/rust-random/book/blame/master/src/guide-rngs.md#L62

Is this warning out of date?

If it is not out of date, should it be interpreted to mean: While this library has CSPRNGs that are in fact cryptographically secure, this is not a general purpose cryptographic library providing other algorithms like encryption and authentication? (And if you want encryption and authentication you should go to the referenced libraries instead of building your own using rand.)

If it is neither out of date nor a warning against rolling your own crypto, then it seems like the rand library documentation should be updated to remove CSPRNG references. https://docs.rs/rand/0.8.5/src/rand/rngs/mod.rs.html#53-62

Example issue: https://github.com/confidential-containers/confidential-containers/issues/44#issuecomment-1224980099

[dhardy]

Cross-posting to the main repo.

This post can stay open: the book probably needs updating eventually.

[vks]

While this library has CSPRNGs that are in fact cryptographically secure, this is not a general purpose cryptographic library providing other algorithms like encryption and authentication? (And if you want encryption and authentication you should go to the referenced libraries instead of building your own using rand.)

I think this is accurate, but we cannot guarantee that our implementations are cryptographically secure. It's more of a best-effort thing, we don't spend the resources in verifying our implementations that a crypto library might.

If you look at crypto libraries, they use getrandom directly to generate keys, and you might want to do something similar if cryptographic security is important.

[Christiaan676]

Was reading the book as I need a secure RNG and this statement confused me. Also the links suggest that the other projects provide a secure RNG. But RustCrypto has no RNG, and Ring only provides an abstraction over the OS RNG.

[vks]

Ring only provides an abstraction over the OS RNG.

This is AFAIK best practice for cryptographic use cases: Don't use a user-space CSPRNG, use the OS directly (i.e. getrandom).

[dhardy]

This section of the book was updated (#61) to clarify what the the crate does and doesn't attempt to provide. Nothing fundamental changes. Any comments?

Note that the book is for documentation; for changes to rand itself see my cross post to the main repo.