1997-04-19 - Re: Meeting Report: “Developing the Advanced Encryption Standard”

Header Data

From: Bruce Schneier <schneier@counterpane.com>
To: “cypherpunks” <cypherpunks@toad.com>
Message Hash: 4bab04ee69b57886c105699bf6ea5e22781e5485fda2cb2d1920987a435ae50f
Message ID: <v0300780eaf7dc63ab15e@[206.11.192.185]>
Reply To: <199704182351.TAA25998@life.ai.mit.edu>
UTC Datetime: 1997-04-19 02:14:25 UTC
Raw Date: Fri, 18 Apr 1997 19:14:25 -0700 (PDT)

Raw message

From: Bruce Schneier <schneier@counterpane.com>
Date: Fri, 18 Apr 1997 19:14:25 -0700 (PDT)
To: "cypherpunks" <cypherpunks@toad.com>
Subject: Re: Meeting Report: "Developing the Advanced Encryption Standard"
In-Reply-To: <199704182351.TAA25998@life.ai.mit.edu>
Message-ID: <v0300780eaf7dc63ab15e@[206.11.192.185]>
MIME-Version: 1.0
Content-Type: text/plain


At 6:57 PM -0500 4/18/97, Phillip M. Hallam-Baker wrote:
>
>>  Regarding computational efficiency, NIST will favor
>>efficiency on 32-bit processors and short key-setup time, will test
>>efficiency on a little endian processor, and will publish the specs of
>>the test system.
>
>  This seems misguided IMHO. The current trend is towards 64 bit
>processors and the inefficiency of using only half of a 64 bit processor
>seems to me to be somewhat more serious than the hassle of having
>to kludge up 64 bit operations on a 32 bit processor. The most likely
>platforms are 64 bit and 8 bit (embedded systems such as cellular).

I agree that testing on a 32-bit machine is kind of dumb.  I also think
that testing it on a 64-bit machine is just as dumb.  We're talking about
a standard that will be with us for 20-30 years; whatever the current
archetecture is, it will be outdated before the standard is.

The lessons of computer are:  the high end always gets faster, and the
low end never goes away.  Anything will run fast on the high end, if not
now then in a generation or two.  We need something optimized for 8-bit
smart card processors.
>
>> They also encourage two submissions: reference (possibly in
>>Java) and optimized (in C).  Regarding memory requirements, NIST will
>>measure memory requirements for C implementation on a single reference
>>platform (presumably a Pentium Pro), although submitters are welcome to
>>provide results for other platforms.
>
>Thats also a somewhat limited approach. The x86 familly is getting long
>in the tooth. Intel themselves have it scheduled for replacement in 1999.
>The architecture is very much compromised by backwards compatibility
>with the CISC instruction set. A mixed bag of AXP, Pentium PRO and
>commodity embedded processors popular in VLSI cell form such as
>Z-80, 6502 and 680x would be more reasonable.

Again, all that matters is the low end.

>My concern is however that the starting gate closes too soon. 6 months
>is too little time to start something entirely new. But I would not be
>suprised if there was an extension. But unless people know in advance
>there will be one it means that they find out in six months time that
>they have six months to sumbit and algorithm.

We discussed that.  If a group thinks they have six months to develop
something new, they might decide not to even both.  Then, if there is
a six-month extension, we haven't gained anything.  I argued that a full
year should be given.

That's why I want triple-DES approved now, and then to let everyone take
their time with AES.

Bruce

************************************************************************
* Bruce Schneier            2,000,000,000,000,000,000,000,000,002,000,
* Counterpane Systems       000,000,000,000,000,000,002,000,000,002,293
* schneier@counterpane.com  The last prime number...alphabetically!
* (612) 823-1098            Two vigintillion, two undecillion, two
* 101 E Minnehaha Pkwy      trillion, two thousand, two hundred and
* Minneapolis, MN  55419    ninety three.
* http://www.counterpane.com
************************************************************************







Thread