Multiple entropy source handling

[paulidale]

This is a follow on from #4328

The current entropy gathering scheme is to attempt configured sources in order and to short circuit the remainder once the requested entropy have been gathered. This has both advantages and disadvantages. The main culprit is in rand_unix.c due to the necessary flexibility present.

• Multiple sources are better from a security viewpoint.
• We allow the user to configure multiple sources.
• By specifying a source the user is indicating that they trust the source, we shouldn't attempt to second guess this.
• Some sources are blocking, should they still block if the requested entropy has already been gathered?

How can we provide the user with finer control over the entropy gathering?

[paulidale]

@mspncp suggested in #4328 :

Add an API to register your own acquire_entropy((RAND_POOL * pool) callbacks and provide

1. a default implementation of this callback, and
2. a toolbox of standard implementations like RAND_POOL_acquire_entropy_getrandom() which the user can call from his callback.

This seems reasonable and might allow the removal of the configuration time options selecting entropy sources. Or could the configuration time option set the enabled sources?

It seems like individual control over each available source is required. The question is what control is required. Several options come to mind:

• Enable/disable sources. It is possible to argue that all sources should be disabled by default and only enabled explicitly. In this case, there need be no disable capability.
• Source quality. Essentially, applying a scaling factor to the entropy estimate returned by each source. Any default setting would be either zero or one.
• Source sufficiency. If enough entropy is gathered from this source, should we continue with other sources?
• Blocking. If this source would block, should we skip it and continue?
• Source ordering. Should we permit the user to specify the order sources are queried?

[kroeckx]

At least one other question I have is what to do when the received data is not the same size as that we requested. It now seems to be ignored and we move to the next source.

[p-steuer]

Some thoughts on this (from my mainframe-perspective):

The main culprit is in rand_unix.c due to the necessary flexibility present. [...]

• We allow the user to configure multiple sources.
• By specifying a source the user is indicating that they trust the source, we shouldn't attempt to second guess this.

I agree. Users should be able to chose an (entropy source, drbg)-pair which meets their needs (the situation here is quite different from cipher suites, which must be negotiated with a client): Which sources/drbgs do they trust (some users actually dont trust trngs, others do)? Which source/drbg performs best on their platform? Ist fips/nist compliance required or not? ...

• Multiple sources are better from a security viewpoint.

This is true when considering failing entropy sources, but not right when looking at malicious sources as well (see e.g. [1] or paper 6 of [2]). I argue that managing the set of entropy sources should be user's responsibility.

It would be nice to have appropriate APIs, but i see this choice as "system wide" in most cases rather than "per application", so also adding built-time options makes sense.

In the field, openssl is shipped as a pre-configured package with a distro. For users, it is very rarely an option to use a custom built openssl. Therefore, it would be useful to make these settings also customizable via openssl.cnf. Unfortunately, I see many applications ignoring the config file, and im wondering if reading it should be made the default here..

[1] https://blog.cr.yp.to/20140205-entropy.html
[2] https://defuse.ca/files2/poc/pocorgtfo03.pdf

[paulidale]

Earlier today I came across this in SP 800-90B:

3.1.6 Additional Noise Sources
In this Recommendation, it is assumed that the entropy sources have a unique primary noise source that is responsible to generate randomness. It should be noted that multiple copies of the same physical noise source are considered as a single noise source (e.g., a source with eight ring oscillators, where the sampled bits are concatenated to get an eight-bit output, or where the samples bits are XORed together).

In addition to the primary noise source outputs, outputs of other noise sources may be available to the entropy source, and their outputs may be used to increase security. However, the joint entropy of these outputs may be hard to estimate, especially when there are dependencies between the sources (e.g., packet arrival times in a communication network and hard drive access times).

This Recommendation allows one to concatenate the outputs of the additional noise sources to the primary noise source to generate input to the conditioning component. In such cases, vetted conditioning components shall be used. No entropy is credited from the outputs of the additional noise sources.

While the second paragraph acknowledges that more than one entropy source will increase the entropy available, the third paragraph is quite explicit that no credit is given beyond the first source.