-------------------------------------------------- From: "Perry E. Metzger" <pe...@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. Joe
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
