In message <83ae9015-a766-4497-a71d-d537837cf...@openssl.org> on Sun, 08 Apr 2018 19:15:16 +0200, Richard Levitte <levi...@openssl.org> said:
levitte> levitte> levitte> Kurt Roeckx <k...@roeckx.be> 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> 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? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project