Implement an in-library DRBG (a.k.a. CSPRNG a.k.a. random number generator)

[briansmith]

We should add a CSPRNG implementation to ring:

Support for targets without an operating-system-provided CSPRNG

Sometimes ring is being used on targets that don't have an operating system that provides a high-quality CSPRNG, often because the target doesn't have an operating system at all or ring is being used within the operating system itself. In order to support these targets, we should implement and use our own CSPRNG that requires the system to "only" provide good sources of entropy.

In some cases getrandom supports these targets but not in a way that meets our security requirements, so these targets aren't just ones that getrandom doesn't support. ESPIDF is a good example; see the documentation for its esp_fill_random:

The entropy source enabled during the boot process by the ESP-IDF Second Stage Bootloader seeds the internal RNG state with some entropy. However, the internal hardware RNG state is not large enough to provide a continuous stream of true random numbers. This is why a continuous entropy source must be enabled whenever true random numbers are required.

and

If an application requires a source of true random numbers but it is not possible to permanently enable a hardware entropy source, consider using a strong software DRBG implementation such as the mbedTLS CTR-DRBG or HMAC-DRBG, with an initial seed of entropy from hardware RNG true random numbers.

But when we look at getrandom, as just forwards to esp_fill_random as though it is a CSPRNG.

Performance

In some cases, such as BSDs, the operating system's policy is to explicitly discourage applications from directly using the operating system's CSPRNG, and the operating system CSPRNG isn't designed (performance-wise) to handle such applications. In these cases, getrandom is often using libc's CSPRNG, but we'd rather use a Rust CSPRNG, especially given the other requirements we have. In the case of Linux, the OS doesn't explicitly discourage userspace applications from using getrandom directly, but especially due to SPECTRE mitigations, syscall overhead is too high for some applications' performance needs.

Regulatory requirements

In some cases we need to be able to ensure that the CSPRNG meets certain requirements, e.g. ISO/IEC 19790 and FIPS 140-3. In some cases we may be able to rely on the operating system meeting these requirements but in others we need to meet them ourselves. With this in mind, we should implement our CSPRNG in a way that could be validated to meet these regulatory requirements.