"Against Rekeying"

Joseph Ashwood ashwood at msn.com
Wed Mar 24 02:24:40 EDT 2010

From: "Perry E. Metzger" <perry at piermont.com>
Subject: "Against Rekeying"

> I'd be interested in hearing what people think on the topic. I'm a bit
> skeptical of his position, partially because I think we have too little
> experience with real world attacks on cryptographic protocols, but I'm
> fairly open-minded at this point.

Typically, rekeying is unnecessary, but sooner or later you'll find a 
situation where it is critical. The claim made that everything hinges on is 
that 2^68 bytes is not achievable in a useful period of time, this is not 
always correct.

Cisco recently announced the CRS-3 router, a single router that does 322 
Tbits/sec, that's 40.25 TBytes/sec. Only 7 million seconds to exhaust the 
entire 2^68. This is still fairly large, but be around the industry long 
enough you'll see a big cluster where they communicate as fast as possible, 
all with the same key. I've seen clusters of up to 100 servers at a time, so 
in theory it could be just 70,000 seconds, not even a full day, its also 
worth keeping in mind the bandwidth drain of an organization as cmopute 
intensive as Google of Facebook will easily exceed even these limits.

Certainly an argument can be made that the protocol used is wrong, but this 
kind of protocol gets all too frequently, and since it is usually used for 
high availability (one of the primary reasons for clustering) the need to 
rekey becomes all too real.

So there are times where rekeying is a very necessary requirement. I prefer 
a protocol reboot process instead of an in-protocol rekey, but sometimes you 
have to do what you have to do. Rekeying probably should never have been 
implemented in something like SSL/TLS or SSH, even IPsec it is arguable, but 
extreme environments require extreme solutions.

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

More information about the cryptography mailing list