Remove automatic (delayed) reseed-on-fork (#1379 )

* benches/generators.rs: standardize thread_rng benchmarks
* Remove cfgs from examples
* Remove ReadRng
* Add ThreadRng::reseed and doc to use
* Remove fork protection from ReseedingRng; remove libc dep
* Enable ReseedingRng without std
* Move ReseedingRng up; remove module rand::rngs::adapter

2024-03-18 17:41:15 +00:00

2.6 KiB

Raw Blame History

Security Policy

No guarantees

Support is provided on a best-effort bases only. No binding guarantees can be provided.

Security premises

Rand provides the trait rand_core::CryptoRng aka rand::CryptoRng as a marker trait. Generators implementing RngCore and CryptoRng, and given the additional constraints that:

Instances of seedable RNGs (those implementing SeedableRng) are constructed with cryptographically secure seed values
The state (memory) of the RNG and its seed value are not be exposed

are expected to provide the following:

An attacker can gain no advantage over chance (50% for each bit) in predicting the RNG output, even with full knowledge of all prior outputs.

For some RNGs, notably OsRng, ThreadRng and those wrapped by ReseedingRng, we provide limited mitigations against side-channel attacks:

After the state (memory) of an RNG is leaked, there is an upper-bound on the number of bits of output by the RNG before prediction of output by an observer again becomes computationally-infeasible

Additionally, derivations from such an RNG (including the Rng trait, implementations of the Distribution trait, and seq algorithms) should not introduce significant bias other than that expected from the operation in question (e.g. bias from a weighted distribution).

Supported Versions

We will attempt to uphold these premises in the following crate versions, provided that only the latest patch version is used, and with potential exceptions for theoretical issues without a known exploit:

Crate	Versions	Exceptions
`rand`	0.8
`rand`	0.7
`rand`	0.5, 0.6	Jitter
`rand`	0.4	Jitter, ISAAC
`rand_core`	0.2 - 0.6
`rand_chacha`	0.1 - 0.3

Explanation of exceptions:

Jitter: JitterRng is used as an entropy source when the primary source fails; this source may not be secure against side-channel attacks, see #699.
ISAAC: the ISAAC RNG used to implement thread_rng is difficult to analyse and thus cannot provide strong assertions of security.

Known issues

In rand version 0.3 (0.3.18 and later), if OsRng fails, thread_rng is seeded from the system time in an insecure manner.

Reporting a Vulnerability

To report a vulnerability, open a new issue. Once the issue is resolved, the vulnerability should be reported to RustSec.

2.6 KiB Raw Blame History