Are weak entropy sources worth it?

Question

I maintain an operating system that can be deployed to embedded devices with highly diverse capabilities. One of the aspects of porting the OS to a device is declaring the available entropy sources (including, but not limited to, dedicated TRNG peripherals) which will be used to seed the CSPRNG. The security goal of this part of the software is to ensure that the CSPRNG is seeded with sufficient entropy after each instantiation. (There may also be a way to save a random seed across reboots, but here I'm concerned about the case where no saved random seed is available, so the RNG is only seeded with entropy sources.)

The configuration mechanism allows sources that are considered “weak”. Weak sources are mixed into the entropy pool, but their contribution counts for nothing: they don't increase the counter that measures available entropy. The documentation suggests declaring the current time at micro- or nano-second resolution as a weak entropy source.

I'm considering removing the concept of weak entropy sources, and only recommending strong entropy sources. I can see qualitative arguments in both directions, but I don't know how to weigh those arguments.

• Pro: even weak sources may be useful. If the adversary doesn't have access to the initialization time of the device, a fine-grained clock value could add maybe 30 bits of entropy, which is insufficient on its own but could help compensate a source that is a proper TRNG, but is not as strong as it should be (e.g. due to suboptimal temperature or voltage).
• Pro: since the system expects the same amount of entropy from strong sources whether weak sources are present or not, there is no direct loss of security from including weak sources, so we may as well include them.
• Con: any feature is added complexity, so for security the default choice should be not to have a feature. But in terms of system design, the cost is practically zero: a weak source is just a source that systematically returns an estimated 0 bits of entropy, whereas a strong source is one that normally returns 1 or more bits each time.
• Con: Weak sources reduce testability. It's easy to detect if a system has no entropy by instantiating it twice and checking that get_random() returns different values. If a system has both a weak entropy source and a strong source, and the strong source is misbehaving, this is hard to detect by testing. For example, the infamous Debian OpenSSL PRNG seeding bug would have been discovered a lot faster if the PRNG had only been seeded from /dev/urandom, and not from the process ID as well.

Are there other important arguments that I've missed? On balance, are weak entropy sources worth it, or are they counterproductive?

Answer 1

You haven't clarified the device requirement for entropy, so I'll assume that it's to participate in some sort of secure exchange over an otherwise open channel.

I think you have actually hinted at a way of quantifying things in your question, where you mentioned that a high-resolution clock could contribute up to 30 bits of CS-entropy, but this not being enough.

We'll, if you know what protocol you're participating in (assume TLS 1.3), then you know the requirement exists for at least 32+32 (for the ephemeral client key and the client randomness contribution) and then another 12 bytes of high-quality entropy (for the nonce in the ChaCha20Poly1305 symmetric cipher).

(Visit Michael Driscoll's very helpful breakdown of TLS 1.3 https://tls13.ulfheim.net/ for more info.)

... so an observation in support of an argument for including weak sources: in the absence of a high-quality source of randomness, the device client can't contribute to the shared entropy in any protocol like TLS, that has some sort of randomised IV or forward-secrecy.