A questions about SP 800-90A DRBG additional input

Question

There is four inputs in SP 800-90A DRBG that is entropy sources, nonce, personailisation string, additional input.

I noticed the soundness of entropy_sources is most important thing for DRBG security and then nonce and last is personalisation string.

I am wonder why additional input is needed? because entropy source is the key for security.

Here is my question

1. please give me an example of additional input for software cryptographic library (for linux, windows, anything..)

2. Is additional input is crucial to DRBG security?

Answer 1

Some (hopefully) useful information to what you ask can be found in sections 7.2 Other Inputs and section 8.7.2 Additional Input of the SP 800-90A Rev. 1 June 2015 Recommendation for Random Number Generation Using Deterministic Random Bit Generators standard at http://dx.doi.org/10.6028/NIST.SP.800-90Ar1.

I copied and pasted a couple of points which I hope will shed some light, but I would recommend reading those sections in full.

7.2: Other information may be obtained by a DRBG mechanism as input. This information may or may not be required to be kept secret by a consuming application; however, the security of the DRBG itself does not rely on the secrecy of this information. ... Additional input may also be provided during reseeding and when pseudorandom bits are requested. See Section 8.7.2 for a discussion of this input.

8.7.2: Additional input may optionally be provided to the reseed and generate functions during requests. The additional input may be obtained from inside or outside a cryptographic module, and may include secret or public information. Note that a DRBG does not rely on additional input to provide entropy, even though entropy could be provided in the additional input, and knowledge of the additional input by an adversary does not degrade the security strength of a DRBG.

I'm not sure of real world examples.

Answer 2

1.please give me an example of additional input for software cryptographic library

Here is one example of a use for it; suppose you are generating DSA (or ECDSA) signatures, and you don't know if you have good entropy. Now, the first thing the DSA signature algorithm does is select a random value $k$; if our random generator gives us the same value of $k$ twice, and we sign two different messages, someone looking at the signatures (and the messages being signed) can deduce our private DSA key (which is bad).

The concern is if we start our program, sign a message (which gets a value $k$ from our rng), then restart our program (with the same entropy), sign a different message (getting the same value $k$ from the same rng), and that'd leak the DSA private key.

Now, having bad entropy breaks a bunch of security things, but few as bad as this; it'd be nice if we had extra protection against this.

One approach is to do this: when we sign a message, we hash it, and provide it as additional input when we access the rng for the value $k$. If we have good entropy, this is harmless; if we have bad entropy, and are signing two different messages, the different additional inputs will give us unrelated values of $k$, and so we're safe; if we have bad entropy, and are signing two identical messages, we'll get the same value of $k$; however that does not leak the DSA private key (as the signatures will be precisely identical).

Now, this isn't the only way to protect ourselves from bad entropy breaking our DSA signatures (there is RFC6979 by our own Thomas Pornin); however it is an example of a reason you could plausibly use additional input.

And, for your other question:

2.Is additional input is crucial to DRBG security?

Of course not, if it was crucial, it wouldn't be optional. Instead, it is provided as a capability that the application can use, in case they suspect that the RNG state might have inferior entropy (as above), or it might have been compromised.