[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:levitte at openssl.org] 
Sent: Tuesday, 3 April 2018 11:29 PM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] Entropy seeding the DRBG

In message <DA29A952-D1E7-44ED-8BE9-115E073A517B at akamai.com> on Tue, 3 Apr 2018 12:52:50 +0000, "Salz, Rich" <rsalz at 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 <kurt at 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.Pierre at ncp-e.com>
        GH: #5401

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

    commit 2a70d65b99e1f2376be705d18bca88703b7e774a
    Author:     Kurt Roeckx <kurt at roeckx.be>
    AuthorDate: Sat Mar 3 23:19:03 2018 +0100
    Commit:     Kurt Roeckx <kurt at 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.Pierre at 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         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-project mailing list
openssl-project at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project