[openssl-project] Entropy seeding the DRBG

[Dr. Matthias St. Pierre]

> -----Ursprüngliche Nachricht-----
> Von: openssl-project <openssl-project-bounces at openssl.org> Im Auftrag von Salz, Rich
> Gesendet: Mittwoch, 4. April 2018 02:59
> An: openssl-project at openssl.org
> Betreff: 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 that the random generator provides this level of
>     security.

Because it's not about the number of bits needed to store the key, but about the estimated amount of time to break it. According to https://csrc.nist.gov/csrc/media/projects/key-management/documents/transitions/transitioning_cryptoalgos_070209.pdf, the estimated security level of RSA 2048 is 112 bits:

> The security strength is measured in bits and is, basically, a measure of the difficulty of
> discovering the key. The understood security strength for each algorithm is listed in SP
> 800-57. For example, RSA using a key length of 1024 bits (i.e., 1024-bit RSA) has a
> security strength of 80 bits, as does 2-key Triple DES, while 2048-bit RSA and 3-key
> Triple DES have a security strength of 112 bits. See Table 2 in Part 1 of SP 800-57 for
> further security strength information.


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

I don't object to reverting it. After all, it takes only 88 bit to measure the age of the universe in nanoseconds, so 256 bits security should be fairly enough for the moment, even without a nonce.

Matthias



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180404/8686131d/attachment-0001.bin>