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 <da29a952-d1e7-44ed-8be9-115e073a5...@akamai.com> on Tue, 3 Apr 2018 
12:52:50 +0000, "Salz, Rich" <rs...@akamai.com> 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 <k...@roeckx.be>
    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 <matthias.st.pie...@ncp-e.com>
        GH: #5401

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

    commit 2a70d65b99e1f2376be705d18bca88703b7e774a
    Author:     Kurt Roeckx <k...@roeckx.be>
    AuthorDate: Sat Mar 3 23:19:03 2018 +0100
    Commit:     Kurt Roeckx <k...@roeckx.be>
    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 <matthias.st.pie...@ncp-e.com>
        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

Reply via email to