Entropy collection and Random Generation

Random generators, like the CTR-DRBG module, require a source of entropy to kick-start and refresh their own internal entropy state. mbed TLS includes the Entropy Collection module to provide a central pool of entropy to extract entropy from. In a single threaded application, both the entropy pool and the random generator exist within the same thread context. In case of a multi-threaded application, there is a choice of using a central entropy pool and / or random generator or using thread-specific versions.

How does entropy collection work?

The entropy collector works by gathering entropy from multiple sources and integrating them into its internal entropy state. Each time entropy is collected the internal state gets better. Unless additional entropy sources have been added to the default entropy collector sources, mostly OS dependent random sources are used. Each time the entropy collector gathers entropy from the system, this extracts and reduces the entropy in the system.

Random generators and entropy

The random generators themselves, like CTR-DRBG, do not require new entropy every time they are called. Instead they expand the available entropy to produce random without compromising the original entropy and being secure as long as not too much random is generated from one state. Therefore the random generators occasionally gather entropy from the entropy collector to refresh their state.

Advice for threaded environments

Regarding entropy, our advice is to use a central entropy collector. Initialize once. This makes sure that the entropy collector gets the best entropy from its sources as it does not have to share with sibling entropy collectors. (With PolarSSL 1.2.x, you'll need to wrap entropy_func() with locks to make it thread-safe. Starting from the 1.3 branch, this is done if the threading layer is enabled, see "Thread Safety and Multi Threading".)

Then you have two options:

  1. For each thread, use a separate CTR-DRBG or HMAC-DRBG random generator using a thread-specific value (like the thread-id) for the custom personalization string. Provide the DRBG with mbedtls_entropy_func() as its entropy callback. This makes sure that the random generators between the different threads have the least amount of correlation possible and can thus be considered as independent as possible.

  2. Use a central CTR-DRBG or HMAC-DRBG context initialized once in the main thread, and share in across threads. With the 1.3 branch and earlier, you will need to manually handle locks around your DRBG functions; starting from mbed TLS 2.0.0, this is done automatically if the threading layer is enabled, see "Thread Safety and Multi Threading".

Did this help?