Why DES in IPSEC ESP?
I suppose this is really addressed at Perry: Why was (single) DES chosen as the algorithm for the ESP part of IPSEC? If someone's IP traffic is being monitored and collected offline by some agency then they're going to get about a couple of hours of security while the special purpose key search hardware kicks into action. I know other algorithms can optionally be used, but surely it would have been better to have a second, stronger algorithm specified mandatory as well. - Andy +-------------------------------------------------------------------------+ | Andrew Brown Internet <asb@nexor.co.uk> Telephone +44 115 952 0585 | | PGP (2048/9611055D): 69 AA EF 72 80 7A 63 3A C0 1F 9F 66 64 02 4C 88 | +-------------------------------------------------------------------------+
| I suppose this is really addressed at Perry: | | Why was (single) DES chosen as the algorithm for the ESP part of IPSEC? | If someone's IP traffic is being monitored and collected offline by some | agency then they're going to get about a couple of hours of security while | the special purpose key search hardware kicks into action. I know other | algorithms can optionally be used, but surely it would have been better to | have a second, stronger algorithm specified mandatory as well. Since Perry is hopefully off busily implementing things, I'll try to answer. :) First, DES is still pretty strong. Try throwing Pentiums at it. It suffices as a fast, known to be reasonably strong, block ethernet sniffers algorithim. Second, no other algotrithm is known to be well designed. We can trust that the NSA did a fair job in the design. Thus, choosing a second algorithm is a difficult, and political task. (There are also patent and licensing issues with other ciphers) So, in order to ship sooner rather than later, DES was chosen. 3DES will probably be available soon afterwards. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
Adam Shostack writes:
choosing a second algorithm is a difficult, and political task. [...] So, in order to ship sooner rather than later, DES was chosen.
Well, if you define "ship" as "get the standards approved" you have the situation nailed. We basically could all agree on DES and the marketplace will dictate that in practice everyone has 3DES and other things available too. Perry
Andy Brown writes:
I suppose this is really addressed at Perry:
Why was (single) DES chosen as the algorithm for the ESP part of IPSEC?
It wasn't. Well, it wasn't *really*. IPSEC is a framework into which you drop any algorithm you like -- IDEA, 3DES, Skipjack (:-), or anything else. We picked a baseline algorithm to assure interoperability, but it is not our expectation that people would want to use DES in practice. Picking DES was largely a political, not a technical decision. RFCs describing 3DES and SHA modes are in the pipeline right now -- they are going before the IESG "real soon now".
I know other algorithms can optionally be used, but surely it would have been better to have a second, stronger algorithm specified mandatory as well.
Well, lets remember this: algorithms go sour with time, like dairy products. People are going to have to get used to regularly switching them very soon anyway. Think of this as just a way to get people in the habit of building their implementations modularly from the start. My recommendation is that all implementations include 3DES in their initial algorithm set. I'm going to do it with mine. Perry
participants (3)
-
Adam Shostack -
Andy Brown -
Perry E. Metzger