• You want to use your own private DRBG instances. Multiple DRBG instances which are accessed only by a single thread provide additional security (because their internal states are independent) and better scalability in multithreaded applications (because they don't need to be locked).

• You need to integrate a previously unsupported entropy source.

• You need to change the default settings of the standard OpenSSL RAND implementation to meet specific requirements.

CHAINING

A DRBG instance can be used as the entropy source of another DRBG instance, provided it has itself access to a valid entropy source. The DRBG instance which acts as entropy source is called the parent DRBG, the other instance the child DRBG.

This is called chaining. A chained DRBG instance is created by passing a pointer to the parent DRBG as argument to the RAND_DRBG_new() call. It is possible to create chains of more than two DRBG in a row.

THE THREE SHARED DRBG INSTANCES

Currently, there are three shared DRBG instances, the <master>, <public>, and <private> DRBG. While the <master> DRBG is a single global instance, the <public> and <private> DRBG are created per thread and accessed through thread-local storage.

Pointers to these DRBG instances can be obtained using RAND_DRBG_get0_master(), RAND_DRBG_get0_public(), and RAND_DRBG_get0_private(), respectively. Note that it is not allowed to store a pointer to one of the thread-local DRBG instances in a variable or other memory location where it will be accessed and used by multiple threads.

All other DRBG instances created by an application don't support locking, because they are intended to be used by a single thread. Instead of accessing a single DRBG instance concurrently from different threads, it is recommended to instantiate a separate DRBG instance per thread. Using the <master> DRBG as entropy source for multiple DRBG instances on different threads is thread-safe, because the DRBG instance will lock the <master> DRBG automatically for obtaining random input.

THE OVERALL PICTURE

The following picture gives an overview over how the DRBG instances work together and are being used.

               +--------------------+
               | os entropy sources |
               +--------------------+
                        |
                        v           +-----------------------------+
      RAND_add() ==> <master>     <-| shared DRBG (with locking)  |
                      /   \         +-----------------------------+
                     /     \              +---------------------------+
              <public>     <private>   <- | per-thread DRBG instances |
                 |             |          +---------------------------+
                 v             v
               RAND_bytes()   RAND_priv_bytes()
                    |               ^
                    |               |
    +------------------+      +------------------------------------+
    | general purpose  |      | used for secrets like session keys |
    | random generator |      | and private keys for certificates  |
    +------------------+      +------------------------------------+

The following two sections describe the reseeding process of the master DRBG, depending on whether automatic reseeding is available or not.

Reseeding the master DRBG with automatic seeding enabled

Calling RAND_poll() or RAND_add() is not necessary, because the DRBG pulls the necessary entropy from its source automatically. However, both calls are permitted, and do reseed the RNG.

RAND_add() can be used to add both kinds of random input, depending on the value of the randomness argument:

randomness == 0:

The random bytes are mixed as additional input into the current state of the DRBG. Mixing in additional input is not considered a full reseeding, hence the reseed counter is not reset.

randomness > 0:

The random bytes are used as entropy input for a full reseeding (resp. reinstantiation) if the DRBG is instantiated (resp. uninstantiated or in an error state). The number of random bits required for reseeding is determined by the security strength of the DRBG. Currently it defaults to 256 bits (32 bytes). It is possible to provide less randomness than required. In this case the missing randomness will be obtained by pulling random input from the trusted entropy sources.