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

[Kurt Roeckx]

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.

There are other reasons we want to use the DF by default:
- We might have entropy sources that provide less than 8 bit of
  entropy per byte.
- We still want to support RAND_add()

The reason for the 256 bit version is that there are people that
want more than the 128 bit security level. In fact, our default
cipher order has aes-256 first. And I still read current
recommendations to use aes-256. I also read that the aes_128_ctr
DRBG might not even provide the 128 bit level, but something
much lower.


> > But I think there is at least
>     enough code in there that you can write something so that the DRBG
>     can be validated.
>    
> But that wasn't a goal.  It *is* a goal of our next release.

So because it's not a goal to provide SM2/SM3/SM4, we don't care
that it's actually implemented properly? It's enough to just have
that name, and might do something totally different?

You also argue that because we agreed to TLS 1.3, that AES must
also be properly implemented? Doesn't it also require a proper
RNG? Or can we just call rand()?

>     > 	- It is probably not appropriate in an API/ABI compatible release
>     > 	- It is not appropriate for a "silent change"
>     
>     I'm not sure what you're talking about with the last 2 items. What
>     changes are you talking about?
> 
> The fact that 384 bits of seed are needed, when before it was 128.

The previous release was 256, not 128.

> >    getrandom() when available avoids this a little. But glibc in
>     Debian stable is only at glibc 2.24 while 2.25 is needed. I think
>     we should consider having support for the syscall ourself. We
>     should probably also add support for such functions on *BSD.
>   
> So this is now a break change for debian stable?

Stable has 1.1.0 (and 1.0.2) and will most likely stay on 1.1.0.
But people will want to use TLS 1.3, so I will at least provide it
in backports. And unless we add support for the syscall, it will
probably come with some warning.

>  All the more reason to revert it.

You mean remove the whole DRBG? Or the reseeding?

(The 384 vs 256 really doesn't have any effect on /dev/urandom not
being in a chroot.)

> In going from 1.1.0 to 1.1.1, breaking platforms that used to work is just plain wrong.

So then I suggest we support the syscalls on all platforms that
provide it.


Kurt