[cryptography] Just how bad is OpenSSL ?
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
> 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