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?


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.

  • 1
    No, you can't quantify entropy this way. A system needs a minimum entropy input which is its security strength: a quantification of the amount of brute force attacks it must be able to resist against. Once this minimum amount of entropy is available, a cryptographic pseudorandom generator takes care of generating as much random data as needed. – Gilles 'SO- stop being evil' Nov 15 '20 at 10:43
  • Well, my point was made 'in the first instance' which I didn't make clear, however, I was answering within the context that you described: "here I'm concerned about the case where no saved random seed is available, so the RNG is only seeded with entropy sources". Would you disagree that the amount of entropy needs to be enough to initiate the protocol? – brynk Nov 15 '20 at 13:13
  • 1
    The amount of entropy has nothing to do with the communication protocol(s) that the device may use. Typically for users of my software it's determined according to NIST SP 800-90A based on the chosen DRBG algorithm and the desired security level. – Gilles 'SO- stop being evil' Nov 15 '20 at 16:07
  • well thanks for the hint - it is quite clear in the spec that the input to the DRBG has to be at least large enough to meet the demand (s8.4) .. this actually was the point I was trying to make about the protocol, but my answer is poorly written and not clear: I'll update it after giving it some more thought. Incidentally, 800-90A gives you an argument for keeping additional sources, as a "cushion" (pp18-19 s8.6.3) in the event that the strength of a higher-quality source is overestimated. – brynk Nov 15 '20 at 23:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.