Security Implications of Using the Data Encryption Standard (DES)

from rfc-editor announcement today

4772 I
    Security Implications of Using the Data Encryption
Standard (DES), Kelly S., 2006/12/22 (28pp) (.txt=68524)
(was draft-kelly-saag-des-implications-06.txt)

...

The Data Encryption Standard (DES) is susceptible to
brute-force attacks, which are well within the reach of a
modestly financed adversary.  As a result, DES has been
deprecated, and replaced by the
Advanced Encryption Standard (AES).  Nonetheless, many
applications continue to rely on DES for security, and
designers and implementers continue to support it in new
applications.  While this is not always inappropriate, it
frequently is.  This note discusses DES security
implications in detail, so that designers and implementers
have all the information they need to make judicious
decisions regarding its use.

... snip ...

rfc 4772 summary
http://
www.garlic.com/~lynn/rfcidx15.htm#4772

from 
http://www.g
arlic.com/~lynn/rfcietff.htm

and in the rfc summery, clicking on the ".txt="
field retrieves the actual RFC.

note that there have been (at least) two countermeasures to
DES brute-force attacks ...  one is 3DES ... and the other
... mandated for some ATM networks, has been DUKPT. while
DUKPT doesn't change the difficulty of brute-force attack on
single key ... it creates a derived unique key per
transaction and bounds the life-time use of that key to
relatively small window (typically significantly less than
what even existing brute-force attacks would take). The
attractiveness of doing such a brute-force attack is further
limited because the typical transaction value is much less
than the cost of typical brute-force attack.

... and a little extra in the same announcement:

4732 I
    Internet Denial-of-Service Considerations, Handley M.,
IAB, Rescorla E., 2006/12/22 (38pp) (.txt=91844) (Refs 1058,
1075, 1112, 2349, 2385, 2439, 2827, 2918, 3261, 3411, 3550,
3618, 3682, 3768, 4251, 4271, 4346, 4566, 4601) (was
draft-iab-dos-05.txt)

....

This document provides an overview of possible avenues for
denial-of-service (DoS) attack on Internet systems.  The aim
is to encourage protocol designers and network engineers
towards designs
that are more robust.  We discuss partial solutions that
reduce the effectiveness of attacks, and how some solutions
might inadvertently open up alternative vulnerabilities.

... snip ...

rfc 4732 summary
http://
www.garlic.com/~lynn/rfcidx15.htm#4732

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

| note that there have been (at least) two countermeasures
to DES brute-force
| attacks ...  one is 3DES ... and the other ... mandated
for some ATM networks,
| has been DUKPT. while DUKPT doesn't change the difficulty
of brute-force
| attack on single key ... it creates a derived unique key
per transaction and
| bounds the life-time use of that key to relatively small
window (typically
| significantly less than what even existing brute-force
attacks would take).
| The attractiveness of doing such a brute-force attack is
further limited
| because the typical transaction value is much less than
the cost of typical
| brute-force attack....
Bounds on brute-force attacks against DESX - DES with pre-
and post-whitening
- were proved a number of years ago.  They can pretty easily
move DES out
of the range of reasonable brute force attacks, especially
if you change
the key reasonably often (but you can safely do thousands of
blocks with
one key).

One can apply the same results to 3DES.  Curiously, as far
as I know there
are to this day no stronger results on the strength of 3DES!

I find it interesting that no one seems to have actually
made use of these
results in fielded systems.  Today, we can do 3DES at
acceptable speeds in
most contexts - and one could argue that it gives better
protection against
unknown attacks.  But it hasn't been so long since 3DES was
really too
slow to be practical in many places, and straight DES was
used instead,
despite the vulnerability to brute force.  DESX costs you
two XOR's - very
cheap for what it buys you.

Question:  How does DUKPT generate its unique keys?  If it's
using DES
on the previous key, or on a counter, or anything simple
like that, at
best, it's making brute force a bit more expensive - one
brute forces
a couple of transaction keys, then uses them to brute force
the DUKPT
key stream.  (There are certainly ways to make this much
harder, but I
wonder what they actually do.)
							-- Jerry

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com

Leichter, Jerry wrote:
> | note that there have been (at least) two
countermeasures to DES brute-force
> | attacks ...  one is 3DES ... and the other ...
mandated for some ATM networks,
> | has been DUKPT. while DUKPT doesn't change the
difficulty of brute-force
> | attack on single key ... it creates a derived unique
key per transaction and
> | bounds the life-time use of that key to relatively
small window (typically
> | significantly less than what even existing
brute-force attacks would take).
> | The attractiveness of doing such a brute-force attack
is further limited
> | because the typical transaction value is much less
than the cost of typical
> | brute-force attack....
> Bounds on brute-force attacks against DESX - DES with
pre- and post-whitening
> - were proved a number of years ago.  They can pretty
easily move DES out
> of the range of reasonable brute force attacks,
especially if you change
> the key reasonably often (but you can safely do
thousands of blocks with
> one key).
> 
> One can apply the same results to 3DES.  Curiously, as
far as I know there
> are to this day no stronger results on the strength of
3DES!
> 
> I find it interesting that no one seems to have
actually made use of these
> results in fielded systems.  Today, we can do 3DES at
acceptable speeds in
> most contexts - and one could argue that it gives
better protection against
> unknown attacks.  But it hasn't been so long since 3DES
was really too
> slow to be practical in many places, and straight DES
was used instead,
> despite the vulnerability to brute force.  DESX costs
you two XOR's - very
> cheap for what it buys you.
> 
The IETF/IESG refused to publish the "ESP DES-XEX3-CBC
Transform" submitted
as draft-ietf-ipsec-ciph-desx-00 (1997) and
draft-simpson-desx-01 and
draft-simpson-desx-02 (1998).

Of course, they also refused to publish
draft-simpson-des-as-00 (1998) and
draft-simpson-des-as-01 (1999) that deprecated DES --
despite strong
votes of support at SAAG and PPP meetings.

There was an "Appeal of IESG inaction, decisions of 13
Oct 1999 and 16 Feb 1999".
http://www1.ietf.org/mail-archive/web/ietf/curre
nt/msg11160.html

The NSA and Cisco folks that were involved in IKE/ISAKMP
advocated DES,
refusing to assign code points for DESX.  Gosh, I wonder
why....

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com