> -----Urspr√ľngliche Nachricht-----
> Von: openssl-project <openssl-project-boun...@openssl.org> 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 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 
 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 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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

openssl-project mailing list

Reply via email to