I consider there to be a number of seperable issues:
1) Should the IETF support a weakened cipher?
2) Should DES be an acceptable weakened cipher?
3) Are there other reasons to use DES?
4) Is the legacy code issue going to be crippling?
The answer to (1) is much harder to answer when 56 bits are on offer
than when its only 40. Even in '94 the insecurity of 40bits was
quite apparent. The principle barrier to attacking SSL at the time
was the secrecy of the cipher.
56 bits are a significant obstacle to all but a few very well
equiped attackers, 40 bits are not much of a challenge these days.
Remember that the cipher is not necessarily the weakest link
in the chain. If I had to develop an attack against an application
with a 56 bit cipher I would only try brute force attacks against ]
the key as an extreeme last resort.
Ubiquitous deployment of 56 bits would have a significant increase
in effective security. While I could see the point of a principled
stand rejecting 40 bits I don't think that this is the time
to draw a line in the sand. The fact is that at this point 40bits
are deployed and the priority should be to displace that deployed
base.
The second part is somewhat subtler. Not all 56 bit ciphers are
the same. I would much rather use a 128 bit cipher and expose
part of the key than use a cipher with only 56 bits of key.
While the difficulty of attacking one key by brute force is
not changed the difficulty of compiling an 'attack dictionary'
is considerably increased.
Consider that every HTTP communication to a home page starts
with the sequence "GET / HTTP/1.1<CR><LF>" - and there are surely
other strings which provide useful known plaintext. Salting the
password provides considerable additional security.
There are still good reasons to use DES - in some cases it is
required by regulation.
Finally I don't buy the legacy code argument. In the first place
as has already been pointed out the 40 bit legacy code is already
there. I would much rather face the problem of a 56 bit legacy
base than a 40 bit legacy base.
Also it is not necessary to deploy an entire new client
infrastructure just to upgrade the strength of the cryptography.
Microsoft already ship their domestic cryptography as a patch.
Several enterprising folk have developed scripts to patch
Netscape clients.
For SSL the issue is even simpler. All the clients have been
shipping with 'server gated crypto' code for some time. If the
server certificate has the 'enable 128 bits' flag set even an
export client performs 128 bit encryption with no bits sent
in the clear for the benefit of Mr Freeh.
The one reason for trying to stop the use of 56 bits would be
if there was a concern that the compromise might be too
widely acceptable and reduce pressure on the administration
sufficiently for 56 bits to become a permanent state of affairs.
I don't play the kind of politics where you reject the compromise
to make people dependent on you delivering the whole loaf. On the
other hand I have seen others do so many times.
Sooner or later the nonsense on stilts that is the US crypto
policy will collapse of its own accord. I don't see the need to
fear that any compromise would become permanent.
Phill
