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
algorithm.
(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 :)
iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
