From: "Phillip M. Hallam-Baker" <hallam@ai.mit.edu>
Date: Fri, 18 Apr 1997 16:51:38 -0700 (PDT)
To: "Bruce Schneier" <schneier@counterpane.com>
Subject: Re: Meeting Report: "Developing the Advanced Encryption Standard"
Message-ID: <199704182351.TAA25998@life.ai.mit.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Boundary..3953.1071713693.multipart/signed"

--Boundary..3953.1071713693.multipart/signed
Content-Type: text/plain
Content-Transfer-Encoding: 7bit


>  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).


> 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.

>It was pretty much
>universally thought that this schedule is wildly optimistic.

Like design a new cypher in 6 months?

>NIST has a hard time figuring out how to measure hardware efficiency.
>They'd like to have definitive metrics (like there will be for
software)
>but are unwilling to force submitters to provide VHDL code, or gate
counts,
>or whatever.

Hardware is likely to cover a wide range of uses. The number of gates
for
DES in an ultra fast, `unwound' implementation is many more than a
n
iterator using the same gates for each round.

>NIST talked about what to do about "tweaking" algorithms after
submission.
>What if a break is found, but a simple fix prevents the attack?  What
if
>someone submits an algorithm and someone else proposes a tweak? 
These
>questions were not answered.

Surely this just menas that the tweakers get credit?

>But is there enough time for people to invent strong 128-bit block
ciphers?
>Probably not.  One alternative is to take existing 64-bit block
ciphers,
>and then use a 4-round Luby-Rackoff construction to create a 128-bit
block
>variant.  Another is to give people more time.  Both were talked
about.  I
>would like them to approve triple-DES as an interim standard, and then
take
>all the time they need for a secure 128-bit block cipher.


I suspect the assumption made is that the time table will slip. 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.

I've seen this type of delay a lot in the IETF standards arena. The
working
group starts by assuming it has too little time to do something new
then
spends far longer plugging up holes in a broken plan.

Phill




--Boundary..3953.1071713693.multipart/signed
Content-Type: application/octet-stream; name="bin00003.bin"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="bin00003.bin"
Content-Description: "smime.p7s"

MIIGVAYJKoZIhvcNAQcCoIIGRTCCBkECAQExCzAJBgUrDgMCGgUAMAsGCSqG
SIb3DQEHAaCCBUMwggU/MIIEqKADAgECAhBhQxVohIHU1aLeK14myavFMA0G
CSqGSIb3DQEBBAUAMGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3MgMSBDQSAt
IEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA0MTAwMDAwMDBaFw05ODA0
MTAyMzU5NTlaMIIBGzERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0g
SW5kaXZpZHVhbCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u
Y29tL3JlcG9zaXRvcnkvQ1BTIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj
KTk2MScwJQYDVQQLEx5EaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQx
JDAiBgNVBAMTG1BoaWxsaXAgTWFydGluIEhhbGxhbS1CYWtlcjEgMB4GCSqG
SIb3DQEJARYRaGFsbGFtQGFpLm1pdC5lZHUwXDANBgkqhkiG9w0BAQEFAANL
ADBIAkEAn1xytd7KYvG9xC2rzkxgAmoQLavzeX5JhSRifuyeS0Ib8m4juKZA
+SM6K+C8PAt+nfRu2/QtDFlS6KRs/ty8rQIDAQABo4ICfTCCAnkwCQYDVR0T
BAIwADCCAh8GA1UdAwSCAhYwggISMIICDjCCAgoGC2CGSAGG+EUBBwEBMIIB
+RaCAadUaGlzIGNlcnRpZmljYXRlIGluY29ycG9yYXRlcyBieSByZWZlcmVu
Y2UsIGFuZCBpdHMgdXNlIGlzIHN0cmljdGx5IHN1YmplY3QgdG8sIHRoZSBW
ZXJpU2lnbiBDZXJ0aWZpY2F0aW9uIFByYWN0aWNlIFN0YXRlbWVudCAoQ1BT
KSwgYXZhaWxhYmxlIGF0OiBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT
OyBieSBFLW1haWwgYXQgQ1BTLXJlcXVlc3RzQHZlcmlzaWduLmNvbTsgb3Ig
YnkgbWFpbCBhdCBWZXJpU2lnbiwgSW5jLiwgMjU5MyBDb2FzdCBBdmUuLCBN
b3VudGFpbiBWaWV3LCBDQSA5NDA0MyBVU0EgVGVsLiArMSAoNDE1KSA5NjEt
ODgzMCBDb3B5cmlnaHQgKGMpIDE5OTYgVmVyaVNpZ24sIEluYy4gIEFsbCBS
aWdodHMgUmVzZXJ2ZWQuIENFUlRBSU4gV0FSUkFOVElFUyBESVNDTEFJTUVE
IGFuZCBMSUFCSUxJVFkgTElNSVRFRC6gDgYMYIZIAYb4RQEHAQEBoQ4GDGCG
SAGG+EUBBwEBAjAsMCoWKGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9yZXBv
c2l0b3J5L0NQUyAwEQYJYIZIAYb4QgEBBAQDAgeAMDYGCWCGSAGG+EIBCAQp
FidodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMwDQYJ
KoZIhvcNAQEEBQADgYEAJh3+fz9jUp3TQecpDPMYoZLUJ42ncGftpS00xNE8
ILttcpp9CPSB38TMpr0JIyetRoMCB6M4Sq5IrNadWE/Ot5Rj//x8GjP5f2UW
jZnenvCgSGbZdy0d0j+9jk9O+sDZ2f7fKCMYabUDVatyJfIhLVlxuXChUKdi
CiEiUEjOtnUxgdowgdcCAQEwdjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNz
IDEgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXICEGFDFWiEgdTVot4rXibJ
q8UwCQYFKw4DAhoFADANBgkqhkiG9w0BAQEFAARAEFn85F2m/3bKO3t5+fsw
99OmXBo+DmWlRAb2B7IXvplmq1f/JyDbF1ZXSXnuoAv3i9j4KEv+2FbSoyTG
lo10tw==
--Boundary..3953.1071713693.multipart/signed--