[openssl-project] Entropy seeding the DRBG

I had not realized that we just increased the “entropy” requirements by 50%, from 256 to 384. The original DRBG submission that I did only required 128 bits. I think that is wrong, and I think the PR that did it (#5503) should be reverted. I am concerned that we are trying to meet

Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

On 03/04/18 15:55, Salz, Rich wrote: > This is one reason why keeping around old assembly code can have a cost. :( Although in this case the code is <2 years old: commit e33826f01bd78af76e0135c8dfab3387927a82bb Author: Andy Polyakov AuthorDate: Sun May 15 17:01:15 2016

Re: [openssl-project] Entropy seeding the DRBG

In message on Tue, 3 Apr 2018 12:52:50 +, "Salz, Rich" said: rsalz> I had not realized that we just increased the “entropy” rsalz> requirements by 50%, from 256 to 384. The original DRBG rsalz> submission that I did only

[openssl-project] OpenSSL version 1.1.1 pre release 4 published

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL version 1.1.1 pre release 4 (beta) === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 4 has now

Re: [openssl-project] Entropy seeding the DRBG

On Tue, Apr 03, 2018 at 12:52:50PM +, Salz, Rich wrote: > I had not realized that we just increased the “entropy” requirements by 50%, > from 256 to 384. The original DRBG submission that I did only required 128 > bits. I think that is wrong, and I think the PR that did it (#5503) should >

Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

I'm less concerned about that access in this specific instance - as if we had a test in place for that function then make test on the platform would have picked up the issue trivially. I don't know that we asked the reporter of the issue as to *how* it was found - that would be interesting

Re: [openssl-project] Entropy seeding the DRBG

>Please note that that 50% extra is only used for instantiating the DRBG. On reseed we it only uses 256 bits. True. And now we're finding that VMS won't work. And I bet there are other systems that will also find this amount excessive. >There is an alternative to that 50%

Re: [openssl-project] Entropy seeding the DRBG

If you say that AES256 needs CSPRNG seeding with 256 bits, then why doesn't RSA 2048 keygen need seed to be seeded with 2048 bits? I am not a cryptographer, but I do not agree with this argument algorithms with a security level of 256 bit in TLS (like AES-256-CTR), so it is necessary

Re: [openssl-project] Entropy seeding the DRBG

Since both pull requests mentioned by Richard were reviewed and approved by me, I would to add a few remarks on those two pull requests: Ad #5401: Switch the DRBGs from AES-128-CTR to AES-256-CTR > The requirement change from 128 to 256 happened with this commit: > > commit

Re: [openssl-project] Entropy seeding the DRBG

Richard wrote: > (I'm tempted to try this with /dev/random only on Unix... do I remember it > right, that it blocks for a while after every 8 byte chunk on some Unixen?) Many but not all /dev/random sources will block to fulfill the requested entropy if sufficient isn't in the gathering pool