long-term GPG signing key

leichter_jerrold at emc.com leichter_jerrold at emc.com
Wed Jan 18 10:06:28 EST 2006


| >>>Even though triple-DES is still considered to have avoided that
| >>>trap, its relatively small block size means you can now put the
| >>>entire decrypt table on a dvd (or somesuch, I forget the maths).
| >> 
| >> 
| >> This would need 8 x 2^{64} bytes of storage which is approximately
| >> 2,000,000,000 DVD's (~ 4 x 2^{32} bytes on each).
| >> 
| >> Probably, you are referring to the fact that during encryption of a
| >> whole DVD, say, in CBC mode two blocks are likely to be the same
| >> since there are an order of 2^{32} x 2^{32} pairs.
| >
| >Thanks for the correction, yes, so obviously I
| >muffed that one.  I saw it mentioned on this list
| >about a year ago, but didn't pay enough attention
| >to recall the precise difficulty that the small
| >block size of 8 bytes now has.
| 
| The difficulty with 3DES's small blocksize is the 2^32 block limit when 
| using CBC -- you start getting collisions, allowing the attacker to 
| start building up a code book.  The amount of data is quite within 
| reach at gigabit speeds, and gigabit Ethernet is all but standard 
| equipment on new computers.  Mandatory arithmetic: 2^32 bytes 
But the collisions are after 2^32 *blocks*, not *bytes*.  So the number to
start with is 2^35 bytes.

|								is 2^38 
So this correspondingly is 2^41.

| bits, or ~275 * 10^9.  At 10^9 bits/sec, that's less than 5 minutes.  
And this is about 10^10/40 minutes.

| Even at 100M bps -- and that speed *is* standard today -- it's less 
| than an hour's worth of transmission.  The conclusion is that if you're 
8 hours.

| encrypting a LAN,
Realistically, rekeying every half an hour is probably acceptable.  In fact,
even if an attacker built up a large fraction of a codebook, there is no
known way to leverage that into the actual key.  So you could rekey using
some fixed procedure, breaking the codebook attack without requiring any
changes to the underlying protocols (i.e., no extra data to transfer).
Something like running the key through a round of SHA should do the trick.
If it's agreed that this is done after the 2^30 block is sent/received, on
a 1GB network you're doing this every 20 minutes, with essentially no chance
of a practical codebook attack.

(Not that replacing 3-DES with AES isn't a good idea anyway - but if you
have
a fielded system, this may be the most practical alternative.)

|		    you need AES or you need to rekey fairly often.
Perhaps I'm being a bit fuzzy this morning, but wouldn't using counter mode
avoid the problem?  Now the collisions are known to be exactly 2^64 blocks
apart, regardless of the initial value for the counter.  Even at
10GB/second,
that will take some time to become a problem.  (Of course, that *would* 
require redoing the protocol, at which point using AES might be more 
reasonable.)
							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list