[rustc.git] / vendor / rand / SECURITY.md

# 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 implementating `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 a process fork on Unix, there is an upper-bound on the number of bits
    output by the RNG before the processes diverge, after which outputs from
    each process's RNG are uncorrelated
-   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 signficant 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.7 |  |
| `rand` | 0.5, 0.6 | Jitter |
| `rand` | 0.4 | Jitter, ISAAC |
| `rand_core` | 0.2 - 0.5 | |
| `rand_chacha` | 0.1 - 0.2 | |
| `rand_hc` | 0.1 - 0.2 | |

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](https://burtleburtle.net/bob/rand/isaacafa.html) 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](https://github.com/rust-random/rand/issues/new).
Once the issue is resolved, the vulnerability should be [reported to RustSec](https://github.com/RustSec/advisory-db/blob/master/CONTRIBUTING.md).
Commit	Line	Data
dfeec247 XL	1	# Security Policy
	2
	3	## No guarantees
	4
	5	Support is provided on a best-effort bases only.
	6	No binding guarantees can be provided.
	7
	8	## Security premises
	9
	10	Rand provides the trait `rand_core::CryptoRng` aka `rand::CryptoRng` as a marker
	11	trait. Generators implementating `RngCore` and `CryptoRng`, and given the
	12	additional constraints that:
	13
	14	- Instances of seedable RNGs (those implementing `SeedableRng`) are
	15	constructed with cryptographically secure seed values
	16	- The state (memory) of the RNG and its seed value are not be exposed
	17
	18	are expected to provide the following:
	19
	20	- An attacker can gain no advantage over chance (50% for each bit) in
	21	predicting the RNG output, even with full knowledge of all prior outputs.
	22
	23	For some RNGs, notably `OsRng`, `ThreadRng` and those wrapped by `ReseedingRng`,
	24	we provide limited mitigations against side-channel attacks:
	25
	26	- After a process fork on Unix, there is an upper-bound on the number of bits
	27	output by the RNG before the processes diverge, after which outputs from
	28	each process's RNG are uncorrelated
	29	- After the state (memory) of an RNG is leaked, there is an upper-bound on the
	30	number of bits of output by the RNG before prediction of output by an
	31	observer again becomes computationally-infeasible
	32
	33	Additionally, derivations from such an RNG (including the `Rng` trait,
	34	implementations of the `Distribution` trait, and `seq` algorithms) should not
	35	introduce signficant bias other than that expected from the operation in
	36	question (e.g. bias from a weighted distribution).
	37
	38	## Supported Versions
	39
	40	We will attempt to uphold these premises in the following crate versions,
	41	provided that only the latest patch version is used, and with potential
	42	exceptions for theoretical issues without a known exploit:
	43
	44	\| Crate \| Versions \| Exceptions \|
	45	\| ----- \| -------- \| ---------- \|
	46	\| `rand` \| 0.7 \| \|
	47	\| `rand` \| 0.5, 0.6 \| Jitter \|
	48	\| `rand` \| 0.4 \| Jitter, ISAAC \|
	49	\| `rand_core` \| 0.2 - 0.5 \| \|
	50	\| `rand_chacha` \| 0.1 - 0.2 \| \|
	51	\| `rand_hc` \| 0.1 - 0.2 \| \|
	52
	53	Explanation of exceptions:
	54
	55	- Jitter: `JitterRng` is used as an entropy source when the primary source
	56	fails; this source may not be secure against side-channel attacks, see #699.
	57	- ISAAC: the [ISAAC](https://burtleburtle.net/bob/rand/isaacafa.html) RNG used
	58	to implement `thread_rng` is difficult to analyse and thus cannot provide
	59	strong assertions of security.
	60
	61	## Known issues
	62
	63	In `rand` version 0.3 (0.3.18 and later), if `OsRng` fails, `thread_rng` is
	64	seeded from the system time in an insecure manner.
65
66	## Reporting a Vulnerability
67
68	To report a vulnerability, [open a new issue](https://github.com/rust-random/rand/issues/new).
69	Once the issue is resolved, the vulnerability should be [reported to RustSec](https://github.com/RustSec/advisory-db/blob/master/CONTRIBUTING.md).