Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

README: rand is not a crypto library #1514

Merged
merged 10 commits into from
Oct 28, 2024
Merged

Conversation

dhardy
Copy link
Member

@dhardy dhardy commented Oct 16, 2024

Closes #1358 by documenting what Rand is not.

@dhardy dhardy mentioned this pull request Oct 16, 2024
5 tasks
@newpavlov
Copy link
Member

newpavlov commented Oct 16, 2024

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
Copy link
Member Author

dhardy commented Oct 17, 2024

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?

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
/// - 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious.. is that because it's onerous to implement or causes a performance hit or something else?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

@dcmiddle dcmiddle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are useful clarifications that address the substance of #1358. Thanks for working through these.

dhardy and others added 2 commits October 17, 2024 17:17
Co-authored-by: Dan <[email protected]>
@dhardy
Copy link
Member Author

dhardy commented Oct 17, 2024

Thanks for the review!

README.md Outdated
[`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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Copy link
Member

@newpavlov newpavlov Oct 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current text is broken:

Rand cannot provide any guarantees of security. which retrieves random data from (operating) system sources without a local memory buffer.

Also you already stated that "Rand is not a cryptographic library and cannot provide guarantees of security" in the first sentence of this paragraph, so here you have a needless duplication.

@benjamin-lieser
Copy link
Collaborator

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

@dhardy dhardy requested a review from newpavlov October 23, 2024 14:12
Copy link
Member

@newpavlov newpavlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wording is a bit too conservative for my taste, but I guess it's fine.

Maybe we could move ThreadRng into a separate crate and use slightly less scary wording in it? This also could help cryptographic crates that would like to use ThreadRng, but do not want to pull the whole rand for it.

README.md Outdated
[`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.
Copy link
Member

@newpavlov newpavlov Oct 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current text is broken:

Rand cannot provide any guarantees of security. which retrieves random data from (operating) system sources without a local memory buffer.

Also you already stated that "Rand is not a cryptographic library and cannot provide guarantees of security" in the first sentence of this paragraph, so here you have a needless duplication.

@dhardy
Copy link
Member Author

dhardy commented Oct 23, 2024

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
Copy link
Member

newpavlov commented Oct 23, 2024

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
Copy link
Member Author

dhardy commented Oct 24, 2024

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
Copy link
Collaborator

vks commented Oct 25, 2024

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
Copy link

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

@newpavlov
Copy link
Member

@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
Copy link
Member Author

dhardy commented Oct 28, 2024

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

@dhardy dhardy merged commit 24b9cc3 into rust-random:master Oct 28, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Policy: "not a crypto library"?
6 participants