README: rand is not a crypto library #1514
Conversation
|
I think it's worth to explicitly state that |
| /// - Not to leak internal state through [`Debug`] or serialization | ||
| /// implementations. | ||
| /// - No further protections exist to in-memory state. In particular, the | ||
| /// implementation is not required to zero memory on exit (of the process or |
There was a problem hiding this comment.
Just curious.. is that because it's onerous to implement or causes a performance hit or something else?
There was a problem hiding this comment.
zeroize? It's just not been done (so far). It has been implemented by the chacha20 crate, so we gain this feature when we switch (with a little adjustment to ThreadRng).
Co-authored-by: Dan <[email protected]>
Co-authored-by: Dan <[email protected]>
|
Thanks for the review! |
| [`zeroize`](https://crates.io/crates/zeroize) used buffers and generators. | ||
| We do not automatically reseed on fork (see | ||
| [`ThreadRng`](https://docs.rs/rand/latest/rand/rngs/struct.ThreadRng.html)). | ||
| Rand cannot provide any guarantees of security. |
There was a problem hiding this comment.
Maybe we can recommend using getrandom directly if you need guarantees? Most crypto applications don't need a userspace CSPRNG, and I think this is what crypto libraries like ring do.
Closes #1358 by documenting what Rand is not.