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 _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
