FW: Early Draft Algorithms Section

Forwarded with permission.

Note: David confused which comments were mine and which were Joseph Ashwood's...

Donald

-----Original Message-----
From: Wheeler, David M AZ [mailto:david.m.az.wheeler@intel.com]
Sent: Thursday, May 17, 2001 11:53 AM
To: 'Eastlake III Donald-LDE008'; 'Joseph Ashwood'
Subject: RE: Early Draft Algorithms Section


Donald and Joe,
I'm not going to jump too deep into the fray here, primarily because I'm
not sure of the appropriate 'rules' for contribution. I have been
watching the list actively for about 4 months, though I have been rather
busy on other things. My interest is that we will likely utilize the
standard or an early draft within the next 6-12 months for inclusion in
a product. Though interoperability will NOT be a requirement for this
particular product, it is a concern going forward.

So, that's some background on my interest. I'd like to respond to
Donald's question:

&& Does anyone else in the WG have an opinion on including a stream
cipher?

Although I don't have any formal status in the WG, I'd like to voice an
industry opinion.
Stream ciphers are vital to streaming media (music & video), of which
I'm sure you are both
aware. However, I thought I might mention that, because I didn't see it
in any of the
correspondence. As we move forward with different technologies, the
ability to stream
media, and encrypt/decrypt quickly, are vital. The stream ciphers meet
important real
time requirements for streaming media, but also for other technologies,
like voice
(and voice over IP is becoming real important).

IMHO, it would be a serious deficiency in the standard to ignore stream
ciphers, or
at least provide the ability to use a block cipher in streaming mode
(OFB, CFB, etc),
much like WAKE was proposed.

HOWEVER, this specification of a stream cipher has got to be optional.

I vehemently agree with Joe regarding code bloat and complexity to
implement.

> %% If the parties can't negotiate, then a profusion of algorithms
> %% either breaks interoperability or puts an enormous burden, 
> %% especially on low end limited memory and processing devices, to 
> %% implement all these algorithms.  I, for one, just do not believe 
> %% there is any good reason to provide for 39 symmetric algorithms.
> %% 2 or 3 well chosen strong algorithms are a much
> %% better idea from the viewpoint of the goals of interoperability and
> %% widespread implementation, including lower end devices.

Well said, Joe!

Donald, I understand what you are saying, and the technologist within me
wants
to agree, however, business disagrees. Why? Time to market and risk
management
are the primary reasons. If I build a web server that exports
information to a
closed group, what is the likelihood that someone is going to put
forward the 
effort to break the encryption of my data? Realistically?

Let me share a little inside information. DES is still viable as an
encryption 
algorithm for many solutions being built today because the financial
gain from
breaking the crypto and gaining access to the information provides no
pay back
for the effort to break the cipher in the first place.

Besides, there are so MANY other ways to gain access to the information,
and
so many other weaknesses in the system to address! The algorithm is on
one piece.
To directly attack a good cipher like AES, 3DES, (and yes even DES), is
highly unlikely.
Yes, it's possible to break DES...but how many of the real threats on my
system
will actually have that capability? Under 1/10%. The same will be said
of 3DES 
in 5 years. It is good enough for commercial use in 80% of the cases.

I hope this input is useful to you both. I hope also that the WG will
seriously
consider adding an optional stream cipher, or at least streaming modes
of operation
to the standard.

Thanks for you ear.
Sincerely,
David M. Wheeler
Home Products Group
Intel Corp.

LEGAL DISCLAIMER: The views and opinions expressed are solely my own,
and do not
necessarily reflect the views and opinions of Intel Corporation.

Received on Friday, 18 May 2001 13:38:26 UTC