This module is currently implemented to use the same technique as
libottery (later used by the bsds' arc4random replacement), using
AES-CTR-256 as its underlying stream cipher.  It's backtracking-
resistant immediately after each call, and prediction-resistant
after a while.

Here's how it works:

We generate psuedorandom bytes using AES-CTR-256.  We generate BUFLEN bytes
at a time.  When we do this, we keep the first SEED_LEN bytes as the key
and the IV for our next invocation of AES_CTR, and yield the remaining
BUFLEN - SEED_LEN bytes to the user as they invoke the PRNG.  As we yield
bytes to the user, we clear them from the buffer.

Every RESEED_AFTER times we refill the buffer, we mix in an additional
SEED_LEN bytes from our strong PRNG into the seed.

If the user ever asks for a huge number of bytes at once, we pull SEED_LEN
bytes from the PRNG and use them with our stream cipher to fill the user's
request.

test_crypto.c is pretty big; it wouldn't hurt to split it up some
more before I start adding stuff to the PRNG tests.

This is the second part of refactoring the random-int-in-range code.

Some of the code for getting a random value within a range wants to
be shared between crypto_rand() and the new crypto_fast_rng() code.

I don't know how this got here, but this kind of a wrapper only
belongs in a header file.

Using an anonymous mmap() is a good way to get pages that we can set
kernel-level flags on, like minherit() or madvise() or mlock().
We're going to use that so that we can make uninheritable locked
pages to store PRNG data.

Fixes bug 29169.

(It was added in 0.3.5)

"ours" merge to avoid dropping non-broken changes files after
removal of merged 0.2.9 changes files.

Many of these files cause check-changes to fail, which will be a
long-term problem as we continue to support 0.2.9.

George Kadianakis authored 6 years ago and Nick Mathewson committed 6 years ago

We fix it by disabling the scheduling of actual padding.
Fixes #29122.