-
Notifications
You must be signed in to change notification settings - Fork 428
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
Policy: "not a crypto library"? #1358
Comments
It may be worth to additionally mention that CSPRNGs like
Usually we have (disabled by default) feature which enables zeroization of sensitive structs. It makes sense to add such feature to
I don't think it's a particularly useful addition. |
Thanks for the quick responses to the issue! I've pointed a few colleagues here in the hopes that they might help contribute patches to address documented improvement ideas like Similarly if there's more to be said about "It's more of a best-effort thing, we don't spend the resources in verifying our implementations that a crypto library might."[1] it may be possible to recruit those resources from security organizations.. but only if that's a relevant goal for the project. |
FYI this just came up: #1362. It appears to me that fork reseeding works exactly as advertised, but that someone mis-understood what those advertisements are. To recap:
Does this mean that a compromise is worse than not having fork-detection at all? Should we just remove all documentation of this capability? This argument could be taken further: periodic reseeding (without fork) might be a useful feature in some contexts, but from a security point of view it means almost nothing: if the seeds were ever insecure or state was ever leaked then the system may already be compromised. So, should:
It seems to be a slippery slope all the way (even from the initial position of "not a crypto library" due to mis-usages), thus perhaps the only logical solution is to put security first. However this is currently just a community volunteer project; from this position we cannot offer any form of guarantees. |
I'm not going to lie... I was planning on mis-using
If there is a common desire to become a "crypto library," I think the first step would be to create a |
Thanks for the feedback @nstilt1.
To avoid unnecessary copies? I think changing
Good plan. But before jumping to that, my main concerns at this point are:
I've been pondering this over the last couple of weeks, and while we likely should clarify docs I'm less sure about other changes. But, I would like to hear others' opinions, especially that of frequent contributors or reviewers (but also of users). |
I will note that @RustCrypto definitely stands behind our crates like The |
Yes #1362 is a helpful issue for considering this one. As a user voice...
Especially for new rust developers, rand is going to be the first place they go for a random regardless of the usage. I don't think rand can cede (very intentional pun) secure usages.
To live in the gray area more effectively, I'd recommend making the warning more prominent. Moving "not a crypto library" into "what The wording you see when you first encounter the crate includes words like secure, cryptographic, and correctness. https://docs.rs/rand/0.8.5/src/rand/rngs/mod.rs.html#53-62
As someone getting something for free, yes! :-D Volunteers: If someone has spare time to help out would it be better to direct that effort to rand or ring? Funding: There are organizations that sponsor security work. In this case I don't know what would be material, |
Since I've been working on ChaCha, I've noticed that one of the rustdoc comments was incorrect because of some security/performance choices that split away from Of the choices, there was The Edit: Well, it turns out that it is fairly difficult to make a variable-sized buffer at runtime for x86/x86_64 instead of compile time. |
thread_rngFork protectionQuite likely the best option here is to not attempt to provide any fork protection at all (or at least to remove mention of this in the docs). See Zeroize
Usage of Thus, while it may still be worth adding a Mini-conclusion (thread_rng)The best solution may be to stay roughly where we are already: a fast unpredictable Secure sub-set?
If we did, then according to the above conclusion,
This would require a significant effort — but potentially that effort could be covered through grants, sponsorship and/or support contracts, assuming a suitable company is interested in taking on this role. Should we take any steps in this direction? I'm not really sure what the outcomes would be. Security review of |
I added a tracker to the top of this post. The book has been updated to clarify what I don't think we should track @newpavlov mentioned:
We briefly mention forward secrecy in the book; namely that none of our RNGs provide it (except
Without persuasion to the contrary, my answer to both of the above is no. My conclusion: we can close this issue now; #934 already tracks the only remaining change I'd like to see. |
@dhardy I agree with the points above. Basically, If you only need random bytes for cryptography, you probably don't need to depend on If you want secure random bytes with acceptable performance, you can call
All of these are essentially identical, and all protect against forking and state exposure (by having no state). If you want a faster userspace CSPRNG, use the external |
I think it's reasonable for users to use |
@newpavlov I would say that it depends on requirements: if forward secrecy or minimal risk of exposed state is a requirement, then it's probably better to use Some people might expect that a CSPRNG is forward-secure; none of our generators are designed with this requirement in mind (nor is |
Yes, but my point is that in many cases (e.g. for nonce generation) forward secrecy is not important and it's fine to use |
The current state of affairs is several crypto libraries document usage examples which use |
For the original post see below the line. Deliverables tracker:
zeroize
feature?Cross-posting from here for visibility — the book may document policy, but it affects the whole project.
Well,
SeedableRng::from_entropy
,OsRng
and thegetrandom
crate attempt to offer strong seeding from an external sourceCryptoRng
andCryptoBlockRng
are type-level documentation that implementers are supposed to be cryptographically secure (unpredictable given past outputs), but don't require any direct protection of their state (e.g. I don't think our implementations attempt to zero their state on destruction)ThreadRng
builds on the above and includes periodic reseeding and periodic fork-detection, but this may be insufficient in some cases (e.g. perhaps we should add a method to force immediate fork-detection for use before key-generation or even allow bypassing its buffer for when secrecy is more important than performance).Not really; we don't have a formal policy.
Instead Rand attempts to choose reasonable compromises between performance, security and usability for a general audience. It is not marketed as a cryptographic product, but is hopefully good enough not to be a major security flaw in case it is (mis)used as one.
I'm not sure if Rand should go beyond this, unless it were to move from a volunteer project to a professional one. That said, I do have some possible ideas for improvements:
zeroize
aroundThreadRng
statefn rand::secret_rng
to access the inner RNG (bypassThreadRng
's cache)See also #543, #882, #463
CC @vks @newpavlov @josephlr @joshlf @tarcieri
The text was updated successfully, but these errors were encountered: