[openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)
levitte at openssl.org
Sun Apr 8 21:30:56 UTC 2018
In message <83AE9015-A766-4497-A71D-D537837CF04A at openssl.org> on Sun, 08 Apr 2018 19:15:16 +0200, Richard Levitte <levitte at openssl.org> said:
levitte> Kurt Roeckx <kurt at 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> >> We will never have that in any release by default, like I already
levitte> >> stated a few times.
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> >> RAND_DRBG_set() takes 2 parameters: type and flags.
levitte> >> Type can be:
levitte> >> - NID_aes_128_ctr
levitte> >> - NID_aes_192_ctr
levitte> >> - NID_aes_256_ctr
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> >> We always use a personalization string.
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> >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 levitte at openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
More information about the openssl-project