On Oct 26, 2012, at 2:29 PM, "Scott Fluhrer (sfluhrer)" <[email protected]> wrote:
> 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? In my mind, yes. >> 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. Indeed. > 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? It is not a question of implementing new: *all* new systems coming into the VPNC lab have AES-CBC, and have for a few years. However, if those implementations want to interoperate with older implementations, they need to also have 3DES. Thus, a "MAY" for 3DES with a clear explanation why it is inappropriate in high-volume implementations would be valuable. --Paul Hoffman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
