Re: [openssl-project] Entropy seeding the DRBG

[Salz, Rich]

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 that the random generator provides this level of
security.

But if it is true, an AES128-CTR DRBG is still sufficient for generating keys.  
For the same reason that it is sufficient for generating Ed4418 or RSA2048 keys.

>The use of the nonce is mandated by section 10.2.1.3.2 of Nist SP 
> 800-90Ar1:
  
We are not going for FIPS validation here.  This might be a nice to have, but 
it is *NOT* a requirement for this release.  Especially if it puts the seeding 
requirement beyond the reach of some of our supported platforms.



___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Dr. Matthias St. Pierre]

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 32bda2b2e4900308cb025020d8c8692e1d3c2ba9
> Author: Kurt Roeckx 
> Date:   Sun Feb 18 19:16:13 2018 +0100
> 
> Switch the DRBGs from AES-128-CTR to AES-256-CTR
> 
> Reviewed-by: Dr. Matthias St. Pierre

> GH: #5401

At first I was reluctant whether this increase was really necessary,
because AFAIK a security level of 128 bit is still considered sufficient
for most use cases. But Kurt argumented that OpenSSL supports encryption
algorithms with a security level of 256 bit in TLS (like AES-256-CTR),
so it is necessary that the random generator provides this level of
security. This sounded reasonable and after checking that the Linux
Random Number Generator was seeded with 256 bits of entropy
, I followed his arguments.

My original intention was to have the security strength configurable
with an option like --with-rand-strength=[128,192,256]. One could even
have chosen different defaults for different platforms. But this
approach was in conflict with Kurts argument above, stating that TLS
can't support 256 bit encryption algorithms if the underlying random
generator does not support this security level. So my TODO was dropped
in the above commit, see
.

IMHO there is no alternative to commit
32bda2b2e4900308cb025020d8c8692e1d3c2ba9, unless we say we only support
128 bit encryption algorithms.

Ad #5503:  Make sure we use a nonce when a nonce is required

> And then there's this one, which did the added 50%:
>
> commit 2a70d65b99e1f2376be705d18bca88703b7e774a
> Author: Kurt Roeckx 
> AuthorDate: Sat Mar 3 23:19:03 2018 +0100
> Commit: Kurt Roeckx 
> CommitDate: Sun Apr 1 21:11:26 2018 +0200
> 
> Make sure we use a nonce when a nonce is required
> 
> If a nonce is required and the get_nonce callback is NULL,
request 50%
> more entropy following NIST SP800-90Ar1 section 9.1.
> 
> Reviewed-by: Dr. Matthias St. Pierre

> GH: #5503

This pull request started initially when Kurt noticed that the NIST
standard requires the use of a nonce during instantiation, when a
derivation function is used, and that we were not providing
get_nonce()/cleanup_nonce() callbacks ourselves 
.

The use of the nonce is mandated by section 10.2.1.3.2 of Nist SP 800-90Ar1:

>10.2.1.3.2 Instantiation When a Derivation Function is Used
>When instantiation is performed using this method, the entropy
input may or may not have full entropy; in either case, a nonce is required

In Section 8.6.7 verious methods to obtain a nonce are discussed, see
also :

>8.6.7 Nonce
>
>A nonce may be required in the construction of a seed during
instantiation in order to provide a security cushion to block certain
attacks. The nonce shall be either:
>  a. A value with at least (security_strength/2) bits of entropy, or
>  b. A value that is expected to repeat no more often than a
(security_strength/2)-bit random string would be expected to repeat.
>
>A nonce may be composed of one (or more) of the following
components (other components may also be appropriate):
>
>1. A random value that is generated anew for each nonce, using an
approved random bit generator.
>2. A timestamp of sufficient resolution (detail) so that it is
different each time it is used.
>3. A monotonically increasing sequence number, or
>4. A combination of a timestamp and a monotonically increasing
sequence number, such that the sequence number is reset when and only
when the timestamp changes. For example, a timestamp may show the date
but not the time of day, so a sequence number is appended that will not
repeat during a particular day.
>
> For case 1 above, the random value could be acquired from the same
source and at the same time as the entropy input. In this case, the seed
could be considered to be constructed from an “extra strong” entropy
input and the optional personalization string, where the entropy for the
entropy input is equal to or greater than (3/2 security_strength) bits.

I argued for using variant 4
,
while Kurt favoured variant 1
.
And he is still convinced that variant 1 is the best 

Re: [openssl-project] Entropy seeding the DRBG

[Paul Dale]

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 already.  (it's not quite 
that simple but that's the gist of it).  Some but not most  /dev/urandom 
sources will do the same.  Later kernels are better than older ones in general. 
 I'm not aware of a kernel that limits reads to 8 bytes at a time, although 
there usually is a single read size maximum.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-Original Message-
From: Richard Levitte [mailto:levi...@openssl.org] 
Sent: Tuesday, 3 April 2018 11:29 PM
To: openssl-project@openssl.org
Subject: 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 required 128 bits.  I think that is 
rsalz> wrong, and I think the PR that did it (#5503) should be reverted.
rsalz> 
rsalz> I am concerned that we are trying to meet requirements that we 
rsalz> really don't have.  The original code was a huge improvement.
rsalz> 
rsalz> Requiring 384 bits of random seed is silly.  I think it is 
rsalz> ridiculous.  One way or another we HAVE to fix that before the 
rsalz> release.
rsalz> 
rsalz> Thoughts?

FYI, here's the magic number that lies behind this:

: ; git grep RAND_DRBG_STRENGTH
...
include/openssl/rand_drbg.h:# define RAND_DRBG_STRENGTH 256

The requirement change from 128 to 256 happened with this commit:

commit 32bda2b2e4900308cb025020d8c8692e1d3c2ba9
Author: Kurt Roeckx 
Date:   Sun Feb 18 19:16:13 2018 +0100

Switch the DRBGs from AES-128-CTR to AES-256-CTR

Reviewed-by: Dr. Matthias St. Pierre 
GH: #5401

And then there's this one, which did the added 50%:

commit 2a70d65b99e1f2376be705d18bca88703b7e774a
Author: Kurt Roeckx 
AuthorDate: Sat Mar 3 23:19:03 2018 +0100
Commit: Kurt Roeckx 
CommitDate: Sun Apr 1 21:11:26 2018 +0200

Make sure we use a nonce when a nonce is required

If a nonce is required and the get_nonce callback is NULL, request 50%
more entropy following NIST SP800-90Ar1 section 9.1.

Reviewed-by: Dr. Matthias St. Pierre 
GH: #5503

Each of them seen by itself make sense.  The combined result, though, leaves me 
wondering...

(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?)

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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

[Tim Hudson]

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 information.

Noting which platforms are supported to which level and what level of test
coverage we have are the more important items in my view.

Tim.


On Wed, Apr 4, 2018 at 1:39 AM, Richard Levitte  wrote:

> 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 *that* code (be it assembler or something else)
>
> In message  w...@mail.gmail.com> on Tue, 03 Apr 2018 15:36:15 +, Tim Hudson <
> t...@cryptsoft.com> said:
>
> tjh> And it should have a test - which has nothing to do with ASM and
> everything to do with improving
> tjh> test coverage.
> tjh>
> tjh> Bugs are bugs - and any form of meaningful test would have caught
> this.
> tjh>
> tjh> For the majority of the ASM code - the algorithm implementations we
> have tests that cover things
> tjh> in a decent manner.
> tjh>
> tjh> Improving tests is the solution - not whacking ASM code. Tests will
> catch issues across *all*
> tjh> implementations.
> tjh>
> tjh> Tim.
> tjh>
> tjh> On Tue, 3 Apr. 2018, 8:29 am Salz, Rich,  wrote:
> tjh>
> tjh>  On 03/04/18 15:55, Salz, Rich wrote:
> tjh>  > This is one reason why keeping around old assembly code can have a
> cost. :(
> tjh>
> tjh>  Although in this case the code is <2 years old:
> tjh>
> tjh>  So? It's code that we do not test, and have not tested in years. And
> guess what? Critical CVE.
> tjh>
> tjh>  ___
> tjh>  openssl-project mailing list
> tjh>  openssl-project@openssl.org
> tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
> tjh>
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Salz, Rich]

>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, but it's not making
sense to me.
  
Shrug.
  
>The 1.1.0 version also used 256 bit.
  
The 1.1.0 code was pre-DRBG and was a piece of crap.  Using AES/DRBG is 
stronger, better, and for the normal case 128 bits is enough.



___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Kurt Roeckx]

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 
> be reverted.
> 
> I am concerned that we are trying to meet requirements that we really don’t 
> have.  The original code was a huge improvement.
> 
> Requiring 384 bits of random seed is silly.  I think it is ridiculous.  One 
> way or another we HAVE to fix that before the release.

Please note that that 50% extra is only used for instantiating the
DRBG. On reseed we it only uses 256 bits.

There is an alternative to that 50% extra, but it's not making
sense to me.

The 1.1.0 version also used 256 bit.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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

[Matt Caswell]

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: Andy Polyakov 
CommitDate: Thu May 19 22:33:00 2016 +0200

Add assembly CRYPTO_memcmp.

GH: #102

Reviewed-by: Richard Levitte 


Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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

[OpenSSL]

-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
   been made available. For details of changes and known issues see the
   release notes at:

https://www.openssl.org/news/openssl-1.1.1-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.1-pre4.tar.gz
  Size: 8259067
  SHA1 checksum: 28d83c6441d269660ca1571331bb830867b082d4
  SHA256 checksum: 
df2d5fcc2a878525611c75b9e9116fbcfbce8d9b96419a16eda5fb11ecc428f6

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.1-pre4.tar.gz
openssl sha256 openssl-1.1.1-pre4.tar.gz

   Please download and check this beta release as soon as possible.
   To report a bug, open an issue on GitHub:

https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJaw4CRAAoJENnE0m0OYESR8/gH+wRA1A8TQnwUr9/keW8SGZrg
wxhgEh3q04yYTL7yGYMWn53TDLJR1TJN3viEKtS9vZ7/EIfytb7Q/Sf+dlEpy3GP
Fe5QWQu76DakiF5HHKVoVmcNyObA1sdNzqagxz/XhYkhUdjToOlqDhT0lkPg42ps
lidX68jqvZx2DfE5yjsHp4HzHwLsXVPcOILarX0OOIeG7mVS1k9fIqnVFsajnOhR
KJxMoyJ59pos0hsjA6ZHcjMpcaeXFEUYCqpPQYP/EqQz5h5q456HRovempB+GRM8
yUWAPAgaqfTlOz5Jx5+1SxFbKqFc+/Rkx2M3zpa15SuJ6R7cHZiS/JLlBXF+LiQ=
=x0tg
-END PGP SIGNATURE-
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Richard Levitte]

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 that did it (#5503) should be
rsalz> reverted.
rsalz> 
rsalz> I am concerned that we are trying to meet requirements that we
rsalz> really don’t have.  The original code was a huge improvement.
rsalz> 
rsalz> Requiring 384 bits of random seed is silly.  I think it is
rsalz> ridiculous.  One way or another we HAVE to fix that before the
rsalz> release.
rsalz> 
rsalz> Thoughts?

FYI, here's the magic number that lies behind this:

: ; git grep RAND_DRBG_STRENGTH
...
include/openssl/rand_drbg.h:# define RAND_DRBG_STRENGTH 256

The requirement change from 128 to 256 happened with this commit:

commit 32bda2b2e4900308cb025020d8c8692e1d3c2ba9
Author: Kurt Roeckx 
Date:   Sun Feb 18 19:16:13 2018 +0100

Switch the DRBGs from AES-128-CTR to AES-256-CTR

Reviewed-by: Dr. Matthias St. Pierre 
GH: #5401

And then there's this one, which did the added 50%:

commit 2a70d65b99e1f2376be705d18bca88703b7e774a
Author: Kurt Roeckx 
AuthorDate: Sat Mar 3 23:19:03 2018 +0100
Commit: Kurt Roeckx 
CommitDate: Sun Apr 1 21:11:26 2018 +0200

Make sure we use a nonce when a nonce is required

If a nonce is required and the get_nonce callback is NULL, request 50%
more entropy following NIST SP800-90Ar1 section 9.1.

Reviewed-by: Dr. Matthias St. Pierre 
GH: #5503

Each of them seen by itself make sense.  The combined result, though,
leaves me wondering...

(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?)

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] Entropy seeding the DRBG

[Salz, Rich]

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 that we really don’t 
have.  The original code was a huge improvement.

Requiring 384 bits of random seed is silly.  I think it is ridiculous.  One way 
or another we HAVE to fix that before the release.

Thoughts?

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project