-
-
Notifications
You must be signed in to change notification settings - Fork 434
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
Changes from 6 commits
495cbd1
100e0d1
205b0ee
513012f
91c1437
8c940fb
2539af5
3b88d6b
5dc74ac
5ef64a9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -41,16 +41,36 @@ const THREAD_RNG_RESEED_THRESHOLD: u64 = 1024 * 64; | |
/// A reference to the thread-local generator | ||
/// | ||
/// This type is a reference to a lazily-initialized thread-local generator. | ||
/// An instance can be obtained via [`rand::rng()`][crate::rng())] or via | ||
/// `ThreadRng::default()`. | ||
/// An instance can be obtained via [`rand::rng()`][crate::rng()] or via | ||
/// [`ThreadRng::default()`]. | ||
/// The handle cannot be passed between threads (is not `Send` or `Sync`). | ||
/// | ||
/// `ThreadRng` uses the same CSPRNG as [`StdRng`], ChaCha12. As with | ||
/// [`StdRng`], the algorithm may be changed, subject to reasonable expectations | ||
/// of security and performance. | ||
/// # Security | ||
/// | ||
/// `ThreadRng` is automatically seeded from [`OsRng`] with periodic reseeding | ||
/// (every 64 kiB — see [`ReseedingRng`] documentation for details). | ||
/// Security must be considered relative to a threat model and validation | ||
/// requirements. The Rand project can provide no guarantee of fitness for | ||
/// purpose. The design criteria for `ThreadRng` are as follows: | ||
/// | ||
/// - Automatic seeding via [`OsRng`] and periodically thereafter (see | ||
/// ([`ReseedingRng`] documentation). Limitation: there is no automatic | ||
/// reseeding on process fork (see [below](#fork)). | ||
/// - A rigorusly analyzed, unpredictable (cryptographic) pseudo-random generator | ||
/// (see [the book on security](https://rust-random.github.io/book/guide-rngs.html#security)). | ||
/// The currently selected algorithm is ChaCha (12-rounds). | ||
/// See also [`StdRng`] documentation. | ||
/// - 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. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
/// thread). (This may change in the future.) | ||
/// - Be fast enough for general-purpose usage. Note in particular that | ||
/// `ThreadRng` is designed to be a "fast, reasonably secure generator" | ||
/// (where "reasonably secure" implies the above criteria). | ||
/// | ||
/// We leave it to the user to determine whether this generator meets their | ||
/// security requirements. For an alternative, see [`OsRng`]. | ||
/// | ||
/// # Fork | ||
/// | ||
/// `ThreadRng` is not automatically reseeded on fork. It is recommended to | ||
/// explicitly call [`ThreadRng::reseed`] immediately after a fork, for example: | ||
|
@@ -68,13 +88,6 @@ const THREAD_RNG_RESEED_THRESHOLD: u64 = 1024 * 64; | |
/// from an interrupt (e.g. a fork handler) unless it can be guaranteed that no | ||
/// other method on the same `ThreadRng` is currently executing. | ||
/// | ||
/// Security must be considered relative to a threat model and validation | ||
/// requirements. `ThreadRng` attempts to meet basic security considerations | ||
/// for producing unpredictable random numbers: use a CSPRNG, use a | ||
/// recommended platform-specific seed ([`OsRng`]), and avoid | ||
/// leaking internal secrets e.g. via [`Debug`] implementation or serialization. | ||
/// Memory is not zeroized on drop. | ||
/// | ||
/// [`ReseedingRng`]: crate::rngs::ReseedingRng | ||
/// [`StdRng`]: crate::rngs::StdRng | ||
#[derive(Clone)] | ||
|
@@ -115,9 +128,9 @@ thread_local!( | |
} | ||
); | ||
|
||
/// Access a local, pre-initialized generator | ||
/// Access a fast, pre-initialized generator | ||
/// | ||
/// This is a reasonably fast unpredictable thread-local instance of [`ThreadRng`]. | ||
/// This is a handle to the local [`ThreadRng`]. | ||
/// | ||
/// See also [`crate::rngs`] for alternatives. | ||
/// | ||
|
@@ -139,6 +152,10 @@ thread_local!( | |
/// println!("A simulated die roll: {}", rng.random_range(1..=6)); | ||
/// # } | ||
/// ``` | ||
/// | ||
/// # Security | ||
/// | ||
/// Refer to [`ThreadRng#Security`]. | ||
pub fn rng() -> ThreadRng { | ||
let rng = THREAD_RNG_KEY.with(|t| t.clone()); | ||
ThreadRng { rng } | ||
|
There was a problem hiding this comment.
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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
There was a problem hiding this comment.
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:
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.