[cryptography] Tossing randomness back in?

Sandy Harris sandyinchina at gmail.com
Mon Apr 18 22:26:30 EDT 2011


In many situations, you have some sort of randomness pool
and some cryptographic operations that require random
numbers. One concern is whether there is enough entropy
to support the usage.

Is it useful to make the crypto throw something back
into the pool? Of course this cannot replace real new
entropy, but does it help?

In some cases, this is easy; there is more-or-less
random material lying around that might as well be
thrown in the pool.

If you are doing IPsec with HMAC SHA-1, for example,
SHA gives a 160-bit hash and it is truncated to 96 bits
for the HMAC. Why not throw the other 64 bits into the
pool? If you are using PGP with CAST-128 encryption,
the key schedule generates 64 bits per round but only
37 are used, 32 in an XOR and 5 to control a rotation.
Why not throw the other 27*16 bits into the pool?

In other cases, you might construct something to
derive data for the pool. You do not need a lot.
Each keying operation uses a few hundred bits
of randomness and protects anything from a few
K bits in a short PGP message to megabytes in
something like SSL or IPsec. Anything that
gives a few hundred bits to throw into the pool
per megabyte encrypted gives a rough balance.

For example, Serpent has 32 rounds. The middle
value after 16 rounds is not much related to the
plaintext or ciphertext; perhaps you could just
throw that into the pool. However, that involves
a lot of data and maybe there is some way it
would enable an attack. It might be better to
compress and obscure the data first.

One possibility: take the parity of each 32-bit
word so you get four bits per block encrypted.
Save up those 4-bit chunks until you have, say,
two kilobytes, hash it, and throw the result into
the pool. That involves 4K blocks, 64 K byes,
per hashing operation. Probably enough.

Any of these puts at least as much stuff
back into the pool as it takes out. It is
only pseudo-random data, but it is good
pseudo-random from strong algorithms
and not all of the timing is visible to an
attacker. An enemy can tell within a
millisecond or so when you encrypt an
IPsec packet, but not a PGP message.

So is this useful?



More information about the cryptography mailing list