Fork protection / reseeding / pub-priv generators

[dhardy]

Amazon's 2sn RNG uses three layers of protection to prevent leaking private-key values when forking a process and copying generators:

1. Use extra entropy from RDRAND for each generated value
2. Use two separate generators: one for public-keys and one for private-keys
3. Use WIPEONFORK to force reseeding RNGs after process fork

We don't necessarily need to use all the same protections, but it would be good to use at least one.

Mentioned: dhardy#22 (comment)
Replaces: dhardy#59

[dhardy]

Reseeding for thread-rng currently has a large generation threshold of 32 MiB; in practice this will mean very little or no reseeding for most processes. One use of reseeding is as a basic protection mechanism for forks (admittedly a poor one, but currently the only one we have I think). @pitdicker do you think it would be acceptable to reduce the reseeding threshold?

[pitdicker]

To be honest reducing the reseeding threshold to 32 KiB (what it was before) will still allow on average 16 KiB to be used. So it makes for a very poor defence.

A quick test in the benchmarks show setting the threshold that low reduces performance by 25%.

But isn't it so that the standard library is not prepared for forking a process, so forking is already something that is not supported?

[dhardy]

Given that the primary benefit of reseeding is to limit the potential damage of side-channel attacks in long-running processes, it makes sense to me that reseeding doesn't wait unnecessarily long, e.g. choose a threshold such that the performance overhead is 1-2%.

[pitdicker]

For fork protection (on Unix) we could use pthread_atfork or __register_atfork to set a global static, and check that on every use of the RNG. Or on every BlockRngCore::generate. And as discussed in dhardy#59 this may combine nicely with the functionality of ReseedingRng, because after a fork it will need to be 'reseeded'.

LibreSSL can be an example of how to implement such functionality. And WIPEONFORK on recent Linux versions could be an even better approach.

[dhardy]

@pitdicker added basic fork protection in #466. Since Rust does not notify when moving values we cannot rely on the memory of a ReseedingRng remaining in the same place, so I don't believe we can do any better (except by checking for fork before returning every value, but this adds significant overhead for little benefit).

We may revisit using multiple generators (see #463), but #466 is enough to solve this issue.