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?