In message <> on Sun, 08 Apr 
2018 19:15:16 +0200, Richard Levitte <> said:

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

Ah, hold on, that was without a DF, but we *are* using a DF by
default, which makes sense since we can't possibly assume that we have
an approved RBG or an entropy source that provides "full entropy",
hence, according to 10.2.1 in SP800-90Ar1:

| The use of the derivation function is optional if either an
| *approved* RBG or an entropy source provides full entropy output
| when entropy input is requested by the DRBG mechanism. Otherwise,
| the derivation function *shall* be used.

This also puts into question the no_df tests in test/drbgtest.c, how
can we possibly, under the diverse conditions we're facing, assume to
know if those tests will succeed or fail?

So I guess I'm still on track with wanting to specify a get_nonce
function for VMS.  Speaking of that, got any ideas on how to hook that
on appropriately, without butchering the current DRBG code?


Richard Levitte
OpenSSL Project
openssl-project mailing list

Reply via email to