David Black wrote: > David McGrew wrote: > > The issue is that 3DES has a 64-bit block instead of a 128-bit block; > > please see draft-irtf-cfrg-cipher-catalog-01 Section 2.2.3. (In > > retrospect, there should have been a citation in the draft.) > > That suggests that an explanation of the birthday bound concern > along with a discussion of transmission rate and rekeying concerns > would be appropriate for the ESP and AH requirements draft, as > opposed to a blanket "SHOULD NOT" statement for 3DES.
Would a "MAY-" be more appropriate? > A 1 Gbit/sec link running encrypted at line rate can get to the 4 > Gigabyte birthday bound stated in the cfrg draft fairly quickly, The problem is that the "birthday bound" is not a hard boundary, where you're perfectly safe if you stay below it, and becomes a concern only if you cross it. Instead, it's the pointer where the probability where you leak some data (specifically, the value of the exclusive-or of two 8 bytes segments of plaintext) is fairly good. However, this leakage can occur (with significantly lower probability) considerably before that. > but > a much slower throughput rate may take much longer before rekeying > becomes necessary, if ever (e.g., a remote access session's entire > traffic may be measured in 10s of Megabytes or less). If we consider a 50Megabyte remote access session encrypted with 3DES, there's approximately a 1 in a million probability that there will be some leakage (that is, someone going through the transcript will be able to deduce of value of the exclusive-or of two 8 byte segments). How bad would it be if someone could deduce that comparatively small amount of information? Is that probability low enough to be acceptable? Well, I don't know if we (the working group) can answer either question; they're far too dependent on what is being protected, and the security goals of the system. At the best, we could try to document the issues. On the other hand, what are the arguments for keeping 3DES? Ten years ago, that was the one cipher that everyone implemented, and so it was necessary for interoperability. However, nowadays, AES-128 appears to fill that role (and also doesn't have the above potential security concern); what reason would someone now have to implement 3DES rather than AES? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
