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 requirements
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 required 128 bits. I think that is
rsalz> wrong, and I think the PR t
-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
The repo is unfrozen (thawed?).
The release is done. Thanks to Richard again for all his help.
Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
This is one reason why keeping around old assembly code can have a cost. :(
https://github.com/openssl/openssl/pull/5320
Andy and Tim: Still waiting for your response to my question in that PR …
--- Begin Message ---
OpenSSL bugs, TLSv1.3 latest, Cloud Crypto Logging and a free 14-day trial of
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 +0200
Commit: An
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:
So? It's code that we do not test, and have not tested in years. And guess
what? Critical CVE.
And it should have a test - which has nothing to do with ASM and everything
to do with improving test coverage.
Bugs are bugs - and any form of meaningful test would have caught this.
For the majority of the ASM code - the algorithm implementations we have
tests that cover things in a decent mann
While I totally agree with the direction Tim is taking on this, we
need to remember that there's another condition as well: access to the
platform in question, either directly by one of us, or through someone
in the community. Otherwise, we can have as many tests as we want, it
still won't test *t
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
>
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 informat
>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% extra
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 a
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 32bda2b2e4900308c
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 tha
> -Ursprüngliche Nachricht-
> Von: openssl-project Im Auftrag von
> Salz, Rich
> Gesendet: Mittwoch, 4. April 2018 02:59
> An: openssl-project@openssl.org
> Betreff: Re: [openssl-project] Entropy seeding the DRBG
>
> If you say that AES256 needs CSPRNG seeding with 256 bits, then why doe
16 matches
Mail list logo
