search

rust-random / rand

A Rust library for random number generation.
https://crates.io/crates/rand
Other
1.67k stars 432 forks source link

README: rand is not a crypto library #1514

Closed dhardy closed 3 weeks ago

dhardy commented 1 month ago

Closes #1358 by documenting what Rand is not.

newpavlov commented 1 month ago

I think it's worth to explicitly state that ThreadRng is suitable for generation of cryptographic material (keys, nonces, salts, seeds, etc.), but users should account for the listed security caveats and use OsRng when in doubt. It's also worth to add that ThreadRng does not provide forward secrecy guarantees in time between re-seedings.

dhardy commented 1 month ago

Updated.

Ultimately, I'm not comfortable with saying definitively that it is is suitable for XYZ. I attempted to document things such that users get the right message and can decide for themselves.

@tarcieri and @dcmiddle may have comments?

dhardy commented 1 month ago

Thanks for the review!

benjamin-lieser commented 1 month ago

In any case we should not forget to also update or remove the Security.md

dhardy commented 4 weeks ago

Are there specific cases where the wording is too conservative (besides the "cannot provide guarantees of security" disclaimer)?

We discussed moving ThreadRng to a different crate in the past and decided against it. Besides which, cryptographic libraries may benefit from things like low-bias range sampling.

newpavlov commented 4 weeks ago

besides the "cannot provide guarantees of security" disclaimer

It's a big disclaimer. Users may (rightfully) interpret it as "rand should not be used in cryptographic code".

Besides which, cryptographic libraries may benefit from things like low-bias range sampling.

I don't think so, at very least, I can not name a cryptographic library that depends on rand for this. In cryptographic code RNGs are primarily used to generate "raw bytes". Even when we need to generate random numbers (e.g. when working with elliptic curves), cryptographic libraries usually implement their own specialized sampling (e.g. see crypto_bigint::Random).

dhardy commented 4 weeks ago

Moving ThreadRng to its own crate is #716. Do you want to re-open it? At a glance, this new crate would need ReseedingRng and to depend on rand_core and whichever crate provides ChaCha, which is all reasonable enough. I'm still not convinced it's a very useful separation though.

Yes, it is a big disclaimer. Updated.

vks commented 4 weeks ago

In cryptographic code RNGs are primarily used to generate "raw bytes".

To my understanding, APIs like getrandom are used for this. Does anyone prefer a userspace CSPRNG for this use case? I guess I don't really see why Rand would be used in this context.

tarcieri commented 3 weeks ago

@vks though I generally prefer getrandom-style APIs, there are sometimes cases where the performance is inadequate

newpavlov commented 3 weeks ago

@vks Cost of syscall may be noticeable in some cases, e.g. while frequently generating less critical cryptographic material such as nonces or salts. It's also more convenient to work with infallible "stateless" RNGs.

dhardy commented 3 weeks ago

So we're okay with this as-is? I updated again after @newpavlov's last comment on the disclaimer.