excessive usage of /dev/random?

[Peter Gutmann]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

>Peter, if your "numerology" remark is actually ironic (that is, if you do not
>believe the literal conclusion you've drawn but are instead critiquing what
>you see as bogus equivalences between classes of cryptographic algorithms),
>could you please clarify that?  Sorry for having to ask...

It's most definitely ironic, it was meant in the sense of "the numerologists
say we need to do X, so let's see what happens when I throw that statement out
there".

(The cryptographic numerology here comes from the confusing idea of algorithm
pairings, that every conventional encryption algorithm or key size has to be
somehow matched up to a public-key algorithm key size.  Since conventional
encryption algorithms generally have the property that every single bit added
to the key doubles the work factor needed to break it by brute force while
public-key algorithms don't, this means that attempts to pair conventional-
encryption with public-key sizes leads to insanely large public keys as the
conventional-encryption key sizes get larger.

Using any known technology it's unlikely that humans can ever get beyond about
2^^100 operations, which means that common key sizes of 112 bits (triple DES),
128 bits (AES), 192 bits (AES again), and 256 bits (yet more AES, because you
can never have too many key sizes) are all equally unbreakable, and yet the
desire for algorithm pairing means that we're supposed to go to public-key
sizes of 2048, 3072, 7680, and 15,360 bits respectively for all of these
equally-unbreakable conventional key sizes.  Thus: "cryptographic
numerology").

>2) we can produce an arbitrary amount of unpredictable data from a CSPRNG
>seeded with 256 bits of entropy.

Yup.  Now that doesn't mean don't use 2048 bits (or whatever) if it's
available, but you don't need 2048 bits of pure entropy, anything over... well
lets round it up to a nice 128 bits, should be OK.

(Adding some further comment in case this ends up getting quoted elsewhere, 
you don't even need 128 bits of "pure entropy", just 128 bits not known to 
your opponent.  Choose a fixed 128-bit value that you keep very secret and add 
one to it every time it's used, it's not optimal but good enough if it's the 
only option).

Peter.