DRBG without derivative function and full entropy

[kroeckx]

The NIST standards talk about requiring full entropy when not using the df version. In NIST SP800-90C they have a General_DRBG_Generate that's a wrapper around DRBG_Generate that adds an extra full_entropy_request parameter. I was planning to just add that extra parameter to our generate function, but then I don't see how we would internally ever call it with that parameter set unless we have functions like get_entropy() also have that parameter. I currently don't see an other way to implement those requirements.

[richsalz]

It's good to record this, but 1.1.1 is not the FIPS release :) What we have is much much better than what we used to have.

[kroeckx]

The problem is that we support not using a DF, but the FIPS standard will only allow it for the current code with the master DRBG and with the callbacks changed. It will not work for a DRBG that uses an other DRBG as entropy source without changing the API.

@mspncp: Do you have any opinion on this?

[paulidale]

My first thought is do we even need to support the full entropy request at all? I've a recollection that it might be permissible to not have but if you do, you get the rest of the baggage. Memory is fallible of course.

I'm even less sure about the DF part. A question for the validation lab is the usual result.

My head always hurts when reading the 800-90's :(

[mspncp]

My opionion to your specific question

As stated already in the review thread #5461 (review), it is legal to disable the derivation function if one has a true random source with full entropy.

Assuming I have a hardware RNG device then I could replace the callbacks entirely and seed the DRBG using no_df. Same holds when I do external conditioning. So no_df is not useful for us at the moment but might be useful for others.

The RAND_DRBG is a building block for implementing a CSPRNG. In order to work correctly, it is necessary to obey the rules in the NIST standard. Of course it is possible for a programmer to misuse the API to create a non-cryptographically-secure random generator. For example the programmer could disable the derivation function without having a full entropy random source. But is our code able to detect this? Should we even attempt to detect it? There are thousands of places in our library where a programmer could misuse the OpenSSL API to produce lousy cryptography. But it is not possible and not feasible to check all cases. In the end, we have to trust the programmer to know what he is doing.

So it's perfectly ok to offer the no_df df flag without having a full entropy source yet. Because the developer might have one (e.g., a hardware TRNG).

My general opinion

We should take a break now from discussing DRBG issues and work with all our capacities on the 1.1.1 release. A lot of questions you are bringing up are related to a future FIPS evaluation. But the first and most important question is: What are the requirements of the FIPS certification? The NIST SP 800-90 documents provide recommendations, but it is not stated that all presented features need to be implemented. For example, the standard allows that a DRBG does not support prediction resistance. But if it supports it, it must follow the rules in NIST SP 800-90C. And there are many more features that might not be a must-have for FIPS certification.

I have never participated in a FIPS evaluation, so I know nothing about the procedure. I just know that the two Steve's who were involved in it are gone now. So who will figure out the precise requirements? Who answers questions like:

• Is it required to support prediction resistance?
• Is it required to provide a full entropy random output?
• Is it required to offer the NRBG construction (Section 9 NIST SP 800-90C) which effictively turns a 'normal' DRBG into a full entropy random generator?

Will we just guess what is necessary and wait for the critics of the auditors? Or will we blindly implement every thinkable feature? Before starting to gallop we should be clear in our mind about the right direction. So we should pause for a few weeks to give everybody time to reread NIST SP 800-90A-C, and then start with a general discussion on openssl-dev. And not with very specific, narrowly focused pull requests.

[mspncp]

Of course I meant 'openssl-project', not 'openssl-dev'.

[richsalz]

I really like what you wrote, @mspncp

[nhorman]

@kroeckx is this still an issue worth addressing?

[paulidale]

I don't think this is worth keeping open. We have the capability of using the derivation function or not (via OSSL_PARAMS) and it is enabled by default.

Closing.