[2781] in cryptography@c2.net mail archive
AES - draft of request for comments on candidate algorithms
daemon@ATHENA.MIT.EDU (Bill Stewart)
Fri May 29 09:47:16 1998
Date: Thu, 28 May 1998 07:07:22 -0700
To: cryptography@c2.net, cypherpunks@cyberpass.net
From: Bill Stewart <bill.stewart@pobox.com>
>X-Sender: foti@csmes.ncsl.nist.gov
>X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
>Date: Wed, 27 May 1998 13:35:10 -0400
>To: roback@csmes.ncsl.nist.gov
>From: Edward Roback <edward.roback@nist.gov> (by way of Jim Foti <jfoti@nist.gov>)
>Subject: AES - draft of request for comments on candidate algorithms
> (for August)
>
>AES contacts,
>
>Following is a working draft of an excerpt for our planned announcement
>(for August, 1998) asking for comments on the AES candidate algorithms.
>Since many of you will be analyzing the algorithms (and we presume reading
>the comments we receive, since we'll make them publicly available), we
>thought we'd ask for your informal feedback on our draft. Are we asking
>for the right kind of comments? Should we also ask for others that might be
>helpful? Suggestions?
>
>Thank you,
>
>Ed Roback
>
>
>
>W O R K I N G D R A F T
>
>/snip heading/
>
>Comments on the candidate algorithms are solicited by NIST in this "Round
>1" technical evaluation in order to help NIST reduce the field of
>candidates to five or fewer for the "Round 2" technical analysis. It is
>envisioned that this narrowing will be based
>primarily on security, efficiency, and intellectual property
>considerations. Comments are specifically sought on 1) specific security,
>efficiency, intellectual property, and other aspects of individual AES
>candidate algorithms and 2) cross-cutting analyses of the entire field of
>candidates. As discussed in #6 below, NIST particularly would appreciate
>receiving comments (with supporting justification) containing a list of
>five (or fewer) algorithms which should be considered for Round 2 analysis.
>
>NIST will accept both 1) general comments and 2) formal analyses/ papers
>which will be considered for presentation at the "Second AES Candidate
>Conference."
>
>Since comments submitted will be made available to the public, they must
>not contain proprietary information.
>
>Comments are sought on any aspect the candidate algorithms, including, but
>not limited to:
>
>1. SECURITY:
>
>The security (i.e., the effort required to cryptanalyze) provided by an
>algorithm is the most important factor in the evaluation.
>
>i. Actual security of the algorithm compared to other submitted
>algorithms (at the same key and block size).
>
>ii. The extent to which the algorithm output is indistinguishable from a
>random permutation on the input block.
>
>iii. Soundness of the mathematical basis for the algorithm's security.
>
>iv. Other factors, including any attacks which demonstrate that the
>actual security of the algorithm is less than the strength claimed by the
>submitter. (Claimed attacks will be evaluated for practicality.)
>
> 2. COST
>
>Cost in this context refers to computational efficiency and memory
>requirements.
>
>i. Computational efficiency: both hardware and software implementations
>(particularly focusing on the 128-128 key-block size combination during
>this public comment period) on various platforms and applications.
>
>ii. Memory requirements: The memory required to implement a candidate
>algorithm for both hardware and software implementations (particularly
>focusing on the 128-128 key-block size combination during this public
>comment period) on various platforms and applications. Memory requirements
>include such factors as gate counts for hardware implementations, and code
>size and RAM requirements for software implementations.
>
>3. ALGORITHM AND IMPLEMENTATION CHARACTERISTICS
>
>Three characteristics are included here: flexibility, hardware/ software
>suitability, and Simplicity of algorithm design.
>
>i. Flexibility:
>
>Some examples of "flexibility" may include (but are not limited to) the
>following:
>
>a. The algorithm's ability to accommodate additional key- and block-sizes
>(e.g., 64-bit block sizes, key sizes other than those specified in the
>Minimum Acceptability Requirements section [e.g., keys between 128 and 256
>that are multiples of 32 bits, etc.]) and discussion of how this
>flexibility is useful.
>
>b. Secure and efficient implementation of the algorithm in a wide variety
>of platforms and applications.
>
>c. Implemented as a stream cipher, Message Authentication Code (MAC)
>generator, pseudo-random number generator, hashing algorithm, etc.
>
>ii. Hardware and software suitability: discussions of the algorithm's
>ability to be efficiently implemented in both software and hardware
>
>iii. Simplicity of algorithm design.
>
>4. INTELLECTUAL PROPERTY
>
>This includes, but is not limited to, information regarding any patents
>(particularly any not otherwise identified by the submitter of each
>candidate) that may be infringed by the practice of each nominated
>candidate algorithm.
>
>5. CROSS-CUTTING ANALYSES
>
>This includes information comparing the entire field of candidates in a
>consistent manner for particular characteristics.
>
>6. OVERALL RECOMMENDATIONS
>
>When all factors are considered, identification of which algorithms should
>be selected for the next round of evaluation with supporting
>justifications. (Since NIST intends to select five or fewer algorithms for
>Round 2, it would be useful to identify five or fewer in this regard.)
>Also, conversely, identification and justification of which algorithms
>should NOT be selected for the next round of evaluation. Such comments
>(with supporting justifications) will be of great use to NIST and help
>assure a timely start to Round 2.
>
>///// end /////
>
>
>
>
>
>
