> 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 are not required to do FIPS level DRBG/CSPRNG this release > It's not because we don't have a requirement that it can be validated, that we should only implement it half. There are reasons for those requirements, and they are valid even if you don't validate it. 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. > 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. > - 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. > 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? All the more reason to revert it. In going from 1.1.0 to 1.1.1, breaking platforms that used to work is just plain wrong. _______________________________________________ openssl-project mailing list firstname.lastname@example.org https://mta.openssl.org/mailman/listinfo/openssl-project