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)
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
************************************************************************
Return to April 1997
Return to ““Phillip M. Hallam-Baker” <hallam@ai.mit.edu>”