Subject: RE: Security Use Requirements

From: RJ Atkinson <[email-masked]>
Date: Wed, 07 Feb 2001 16:02:51 -0500

At 15:20 07/02/01, Joshua Tseng wrote:

>It's often been said that the only thing worse than NO SECURITY
>is the ILLUSION of security.  

Some security keeps the kiddies away, no security doesn't.
I'd much rather have DES-CBC than nothing, because it visibly
increases the work function for the adversary.

>Single DES is known to be cracked.

That is a false statement.  It hasn't been cracked.  The best
attack known in the public literature is Biham-Shamir, which 
requires ~O(2^^56) operations and some non-trivial preconditions.  
There have been some specific brute-force attacks on DES that worked, 
but they weren't real-time attacks and required a significant amount 
of computational power.

I'm not arguing against 3DES in preference to DES-CBC, but it 
is just wrong to claim either that DES-CBC is cracked or 
that running in the clear is better than running with DES-CBC
(assumes reasonable cryptographic authentication in all cases).
Note also that my comments are constrained to what is in the 
published literature...

Ran
[email-masked]

---

From: Michael Eisler <[email-masked]>
Date: Wed, 7 Feb 2001 16:55:59 -0800 (PST)

Why use DES, which is slow for software implementations, when AES
is there, is fast, and has little dispute about its safety?

draft-ietf-ipsec-ciph-aes-cbc-01.txt proposes a means
for using AES in IPsec.

draft-ietf-tls-ciphersuite-03.txt proposes a means for
using AES in TLS.

3DES is really, really slow for software to the point of being impractical.
While one can always mandate it for implementation, in practice I doubt any
customer using a software 3DES over ips will want to use it.

	-mre

---

From: Michael Krause <[email-masked]>
Date: Thu, 08 Feb 2001 06:16:27 -0800

>customer using a software 3DES over ips will want to use it.

How fast is AES in hardware?  3DES is link-rate in hardware today and in 
wide use by many products.  While software implementations are interesting 
/ value to some, most high-speed implementations, e.g. 1 / 10 GbE, will 
require hardware acceleration and thus the preference is to focus on 
hardware friendly solutions wherever possible.

Mike

---

From: Michael Eisler <[email-masked]>
Date: Thu, 8 Feb 2001 09:51:11 -0800 (PST)

> hardware friendly solutions wherever possible.

One of the major criteria for NIST selecting the AES algorithm was hardware
friendliness.

I'd like to see a reference to 3DES hardware that encrypts at 10 gigabit/sec
in feedback mode.

http://bass.gmu.edu/crypto/AES_non_feedback.PDF compares AES (Riijndael) to
other AES candidates and 3DES on FPGAs. In feedback mode, AES did 414.2
mbit/sec, vs. 59.1 mbit/sec for 3DES.

In anoher paper, the same authors say
	http://ece.gmu.edu/crypto/AES_survey.pdf

that AES can do 1950 mbits/sec with an ASIC (page 27). 

	-mre

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 8 Feb 2001 23:11:27 -0800

>I'd like to see a reference to 3DES hardware that encrypts at 10
gigabit/sec

In general, my understanding is that 10 Gbps AES is so much closer
to reality than 10 Gbps 3DES, that it is hardly worthwhile to put
much effort into developing a 3DES chipset to operate at those speeds. The
3DES chipset would cost significantly more and the customers probably
wouldn't want to pay the increment. Better to update the ciphersuites
to include AES and negotiate that instead.