[openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)
Richard Levitte
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>
levitte>
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> >>
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 levitte at openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
More information about the openssl-project
mailing list