[openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Kurt Roeckx]

On Sun, Apr 08, 2018 at 07:15:16PM +0200, Richard Levitte wrote:
> 
> 
> Kurt Roeckx <kurt at roeckx.be> skrev: (8 april 2018 17:36:27 CEST)
> >On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
> >> On Sat, Apr 07, 2018 at 05:55:14PM +0000, Salz, Rich wrote:
> >> >     > Because
> >> >     > 	- It is not clear we need to do so
> >> >     
> >> > >    That we need to do what?
> >> > 
> >> > Do FIPS compliant random numbers in this release.
> >> 
> >> We will never have that in any release by default, like I already
> >> stated a few times.
> >> 
> >> > Everything is a trade-off.  Please explain why you want AES256-CTR
> >with a nonce, and why AES128-CTR with personalization (and/or a DF) is
> >not sufficient.
> >> 
> >> RAND_DRBG_set() takes 2 parameters: type and flags.
> >> 
> >> Type can be:
> >> - NID_aes_128_ctr
> >> - NID_aes_192_ctr
> >> - NID_aes_256_ctr
> >> 
> >> The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
> >> is required. When not using a DF the nonce is not used.
> >> 
> >> We always use a personalization string.
> >> 
> >> The requirements for not using a DF means that you need to use
> >> "full entropy", which is even more strict then when using a DF.
> >> Since we don't have a "full entropy" source, we can generate it
> >> ourself, but it would require the double amount of entropy, so 512
> >> bit. We have no code currently to do this, but there is an open
> >> issue about it.
> >
> >This is actually wrong. When not using a DF, the seed length = 384
> >for NID_aes_256_ctr. So we would need 768 bits of entropy if we
> >don't have access to full entropy.
> 
> Wait what? This sounds nuts... Can you refer to something that backs your claim? 

The 384 comes straight out of SP800-90A, see the table 10.2.1.
It's also in the code where we do:
    drbg->seedlen = keylen + 16;
[...]
    if ((drbg->flags & RAND_DRBG_FLAG_CTR_NO_DF) == 0) {
[...]
    } else {
        drbg->min_entropylen = drbg->seedlen;

(With keylen == 32)

You'll also see that when not using a DF "full entropy" is needed,
when using a DF it's not required.

A DRBG can only generate "full entropy" for the first security
strength / 2 bits it generates after a reseed. This is at least
covered in SP800-90C 10.4, but there are other places that mention
this too. So you need to pull the double amount of entropy from
your entropy source if it doesn't provide full entropy. This also
requires to use of prediction resistance.


Kurt