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