[cryptography] Just how bad is OpenSSL ?

ianG iang at iang.org
Sat Oct 27 22:41:35 EDT 2012

On 28/10/12 12:47 PM, Patrick Pelletier wrote:

Just a slow sunday morning so I thought I'd dive in on one point.  For 
the rest, nodding.

> The other thing that bugged me a bit was in the infamous rand(3ssl) man
> page:
>         3.  The state should be very large.  If the RNG is being used
>             to generate 4096 bit RSA keys, 2 2048 bit random strings
>             are required (at a minimum).  If your RNG state only has
>             128 bits, you are obviously limiting the search space to
>             128 bits, not 2048.  I'm probably getting a little
>             carried away on this last point but it does indicate that
>             it may not be a bad idea to keep quite a lot of RNG
>             state.  It should be easier to break a cipher than guess
>             the RNG seed data.
> This seems to contradict the advice given on Linux's random(4) man page:
>         The  amount  of  seed material required to generate a crypto‐
>         graphic key equals the effective key size of  the  key.   For
>         example,  a 3072-bit RSA or Diffie-Hellman private key has an
>         effective key size of 128 bits

This is comparing apples to oranges, which needs to be done with care 
and understanding.  Go to keylength.net and poke around at the 
algorithms used;  there is no better lesson in this, and it's worth 10 
minutes of play.

In essence the 3072 relates to asymmetric (apples) algorithms, whereas 
the 128 relates to symmetric (oranges).  We can approximate the 
strengths of these by converting the 3072 down to 128 but this is an 
approximation (albeit backed up by research).  It is designed to allow 
us to more happily pair the algorithms together for a balanced result, 
not to make decisions of how many bits of entropy are required for each 

> (it requires about 2^128 oper‐
>         ations  to  break) so a key generator only needs 128 bits (16
>         bytes) of seed material from /dev/random.

I do not believe either of those statements follow.  There are plenty of 
algorithms out there that require X random input bits, but only deliver 
Y bits of security when Y is some number less than X and Y is some 
apples-and-oranges comparison standard.  It simply doesn't follow that 
all algorithms are efficient, and we don't even have a definition of 
efficiency at this level.

>         While some safety margin above that minimum is reasonable, as
>         a  guard  against  flaws  in  the CPRNG algorithm, no crypto‐
>         graphic primitive available today can hope  to  promise  more
>         than  256 bits of security, so if any program reads more than
>         256 bits (32 bytes) from the kernel random pool  per  invoca‐
>         tion,  or  per  reasonable reseed interval (not less than one
>         minute), that should be taken as a sign that its cryptography
>         is not skilfully implemented.

I don't believe the Linux pages are skilfully written :)


More information about the cryptography mailing list