AES COMMENTS (e-mail)

====================

Return-Path: \<stewarts@ix.netcom.com\>

X-Sender: stewarts@popd.ix.netcom.com (Unverified)

Date: Thu, 02 Jan 1997 17:31:20 -0800

To: AES@nist.gov

From: Bill Stewart \<stewarts@ix.netcom.com\>

Subject: Attn: FIPS for AES Comments

Cc: cryptography@c2.net

To: Director, Computer Systems Laboratory,

Attn: FIPS for AES Comments,

Technology Building, Room A231,

National Institute of Standards and Technology,

Gaithersburg, MD 20899.

NIST\[Docket No. 960924272-6272-01\] RIN 0693-ZA13 is a request for
comments

on draft minimum acceptability requirements and draft criteria to
evaluate

candidate algorithms for a new Advanced Encryption Algorithm.

I am commenting on the criteria as an individual, and not as a

representative of my employer. I work in the telecommunications/

computer industry, including security analysis and some cryptography.

Overall, the drafts and process look good, and I\'m quite pleased

to see a commitment to an open process from NIST, as opposed to another

closed process such as the CCEP and Clipper projects.

Unfortunately, there is also one very serious process problem,

which may make the proposed selection approach unworkable and illegal

unless addressed carefully by NIST and the Administration.

The problem is the conflict between an open process,

with submission requirements (B.1 and B.2) for complete algorithm

specification, security analyses, and working source code,

vs. the International Trafficking in Arms Regulations and

other existing, announced, and proposed export policies which prohibit
or

require licensing or prior jurisdictional determination for \"export\"
of

source code, technical data, and cryptographic components,

including open publishing on the Internet, discussion with foreigners,

export of machine-readable media, and possibly even of paper
documentation.

While the NIST and NSA can reasonably operate in this environment,

industry, academia, and non-US cryptographic experts cannot

adequately participate in open discussions without some assurance of

legal protection and the ability to exchange information with each
other.

How does NIST propose to address this issue? International participation

is a particularly important issue, given the expertise of people such as

Biham, Shamir, Lai, and other non-US academic cryptographers and

the need for interoperation and efficiency for telecommunications and
finance

implementations.

An important part of an open process is positioning AEA/AES as a
recognized

symmetric algorithm for non-military applications, since the military

generally uses closed standards, while the commercial world generally

prefers a negotiation among a family of encryption algorithms, including

\- export-approved trivial and near-trivial algorithms,

such as RC4/40 and RC4/128 with 88-bit exposed salts

and the US and GSM cell-phone encryption algorithms,

plus algorithms that may be approved in the future,

\- fallback DES support

\- slow but secure algorithms like Triple-DES

\- fast newer algorithms such as RC4, RC5, and Blowfish

\- hardware implementations, including proprietary systems and

accelerators for (Triple) DES

\- fast-setup algorithms for some applications and

slower-setup high-throughput algorithms for others.

\- block vs stream cyphers depending on application

There are three of the design criteria that have problems,

some technical and some organizational/political.

A.3 AES shall be designed so that the key length may be increased as
needed.

The straightforward technical problem is with criterion A.3:

It\'s a good goal, but it unfortunately excludes the most important

existing candidate symmetric cypher algorithm, Triple-DES.

Triple-DES may be slow and clumsy to implement in software,

but it\'s very well understood, allows reuse of existing designs,

and is secure enough for probably the next 50 years of computer speed
growth.

It\'s possible to accommodate Triple-DES into the criterion by

treating it as part of a family of DES, 3-DES, 5-DES, 7-DES, etc.,

but it\'s inelegant and stretches the wording of the criterion.

A more complex problem with criterion A.3 (and thus A.6) is that the

relationships between strength and key length are not simple:

An algorithm that performs very securely for longer keys may be very
weak

with shorter keys which permit optimized attack methods,

and encryption speed may or may not differ significantly with key
length.

(For instance, with DES, the key schedule is relatively slow for

single keys, but recent work has shown that a brute-force keyspace

search in Grey-code order can reduce the key-schedule work for

additional keys to a small fraction of the single-key time.

Pre-computation attacks work quite well on algorithms like RC4/40,

but fail on variants like RC4/128 with revealed 88-bit salts,

even though both have the same size secret key and similar speed.)

This means that keylengths chosen for political reasons, e.g. 56 bit

limits for exportable algorithms, may affect different candidate

algorithms to very different extents. In particular, an algorithm
that\'s

as strong as possible for short key lengths may be slow with longer
keys,

or may require a very long setup time (e.g. Blowfish), and an algorithm

that\'s a very good choice for realistic commercial-strength key lengths

maybe too weak at exportable lengths.

A.2 AES shall be a symmetric block cipher.

Block cyphers are probably more important than stream cyphers,

and this is probably a good choice. However, the issues of streaming

and block chaining need to be addressed - some algorithms like DES

and Triple-DES can work well in either block chaining or codebook modes,

while others such as RC4 require more care for some environments.

The security of some applications is also quite sensitive to block
sizes.

For instance, known plaintext attacks may be more effective with

shorter block sizes because of short standard file/data headers.

A.1 AES shall be publicly defined.

\"Publicly defined\" needs to be defined carefully, and publicly.

DES suffered reputation problems for years because of the

\"What does the NSA \_really\_ know about the S-Box Structure?\"
uncertainties,

which were increased when people discovered efficiencies due to

group structures in the S-boxes, and really only abated after the

discovery of differential cryptanalysis by Biham and Shamir and

the confirmation that the NSA had used those techniques to strengthen
DES.

It\'s especially important to have open public discussion of the

tradeoffs and criteria for selecting between algorithms. For instance,

the comparisons between Digital Signature Algorithm vs. RSA signatures

depend on the relative importance of signature speed vs. verification
speed,

and industry generally viewed both NIST\'s and PKP\'s positions on

that issue to be motivated more by ownership concerns than technical
ones.

Thanks!

Bill Stewart

stewarts@ix.netcom.com

Mountain View, CA.

\-\-\-\-\-\-\-\-\-\-\-\-\-\--

References: \[Federal Register: January 2, 1997 (Volume 62, Number 1)\]

\[Notices\] \[Page 93-94\]

Federal Register Online via GPO Access \[wais.access.gpo.gov\]

http://jya.com/aes010297.txt

====================

Return-Path: \<dthorn@gte.net\>

Date: Thu, 02 Jan 97 21:56:13 -0800

From: Dale Thorn \<dthorn@gte.net\>

To: AES@nist.gov

Subject: New Encryption Standard

I\'d suggest you use what I use, and perhaps redevelop it to suit your

needs. For security, simplicity, ease of use and rewrite:

Take a bitstream and:

1\. Pre-normalize the relative number of zero- and one-bits to whatever

ratio you prefer. Techniques include padding unused bits, and/or

adding new bits to the stream.

2\. Rearrange the bits (don\'t change any except in step #1) using

a pseudo-random scheme of some kind:

a\. Use the PRN stream in several ways simultaneously, i.e., to specify

temporary block size, to specify move-to locations\*\*, to pad the

filestream, etc.

\*\* Note that move-to\'s are not specified directly by output from

PRN\'s, only by the relative amplitude of the PRN\'s.

b\. Use different PRN sources for each of several encryption passes,

to break continuity and patterning.

Note that by shifting the emphasis from changing bits to moving bits,

you can get as close to the ideal of a true random distribution as you

wish (or have time for), as if you were to put the bits into a lottery

tumbler and mix them by turning the crank a few hundred times.

3\. Fragment the encrypted data and store the fragments mixed with

fragments from numerous other streams. This should help keep

control of encrypted data more centralized.

I have sample (compilable) PC code in ANSI \'C\', fully commented,

plus a FAQ which answers most common questions.

====================

Return-Path: \<whmurray@dttus.com\>

To: \"AES@nist.gov\" \<aes.nist.gov\>

Subject: Comment

Date: Fri, 10 Jan 97 11:36:49 -0500

From: William Hugh Murray \<whmurray@dttus.com\>

\-- \[ From: William Hugh Murray \* EMC.Ver #3.0 \] \--

I understand that the intent of the initiative is to have a high-

performance cipher that advances the state of the art beyond DES.

However, unless the intent is also to exclude a stream cipher or

asymmetric key cipher that performed as well as a traditional cipher,

then the bullet that requires a symmetric block cipher is inappropriate.

It dictates a solution rather than a desirable property of the solution.

I suggest that the bullet be re-written to stress the property, i.e.,

high-performance, rather than the means for achieving it. In the

absence of new invention, the outcome might be the same but why pre-

judge.

In 1996 we could do 10,000 DES operation for the cost of one in 1977.

====================

Return-Path: \<seward@netcom.ca\>

From: seward@netcom.ca (John Savard)

To: AES@nist.gov

Subject: Comments respecting the Advanced Encryption Standard

Date: Sat, 11 Jan 1997 19:38:59 GMT

X-Newsreader: Forte Free Agent 1.0.82

John Savard

10245 - 151st Street

Edmonton, Alberta

Canada

T5P 1T6

January 11, 1997

The draft criteria and procedures for submissions for the Advanced

Encryption Standard are appropriate, reasonable, and well thought out,

as well as largely noncontroversial. However, I feel that a few

comments respecting some of the criteria are still in order.

A.1 AES shall be publicly defined.

I personally approve of this criterion. However, given the following

facts:

\- a classified algorithm, known as \"Skipjack\", to be implemented only

with a key escrow feature, has been put forward as the next encryption

standard,

\- that algorithm can reasonably be presumed to meet the security

requirements of government communications in the time frame to be

covered by the Advanced Encryption Standard, and

\- the alternative of a publicly defined encryption standard

significantly more advanced than DES has been claimed to have an

adverse impact on national security, and this claim has been accepted

and endorsed by the Administration,

entities wishing to submit algorithms may harbor reservations as to

whether or not the process will be permitted to proceed normally to

its conclusion.

A.2 AES shall be a symmetric block cipher.

That the AES should be a symmetric-key cipher, and not a public-key

cipher, is clearly correct. For reasons of computational efficiency, a

symmetric-key cipher would be an essential component of a practical

cryptographic system, and so one would be required as part of any

standard.

As research into new public key ciphers is continuing, and the design

of new ones involves making advancements in mathematical theory, not

only would standardization in that aspect be premature, but also a

standards process of the current form would likely not succeed in

eliciting the submission of very many new public-key ciphers.

Conversely, however, it could be argued that a standard without a

public-key component is incomplete, and that the development of new

symmetric-key ciphers is sufficiently trivial as to be unworthy of an

extensive standards process.

There are several factors which support the criterion that the AES be

a block cipher rather than another form of symmetric-key cipher:

Block ciphers have been subject to much public study, and there is a

body of applicable theory for their design.

As there are a number of modes of operation for block ciphers, these

ciphers have a greater flexibility than stream ciphers.

But the modes of operation of a block cipher which are applicable to

the circumstances in which a stream cipher might also be used,

specifically Output Feedback mode and Cipher Block Chaining mode, are

somewhat unsatisfying in respect of the complexity of the part of the

cipher that varies with each block. The security of a block cipher in

such cases could, I believe, be augmented significantly by provision

for a simple stream cipher for use in modes similar to Counter mode to

also be available without exceeding the terms of the standard.

Also, a block cipher could be made amenable to use with an

accompanying stream cipher by so designing it that part of the key

could be modified with a much shorter set-up time than is normally

required for loading in a new complete key. I envisage the reduced

set-up time as being comparable to the time to encipher one block.

However, such a modified block cipher design could be dangerous, as

careful design would be required to ensure that, were this rapidly

changing key not kept completely secure, knowledge of it would not

significantly augment attacks such as differential and linear

cryptanalysis.

A.3 AES shall be designed so that the key length may be increased as

needed.

In connection with this, I shall hazard the following conjecture

without proof: if the full security-related benefits of an increased

key length are to be realized, for a key of length n, the block size

should increase proportional to n, and the computational time of

applying the block cipher should increase proportionally to n squared.

Although it may be intentional that a block size is not recommended or

suggested, it should be noted that if the security of a block cipher

is assessed based on the complexity of defeating the cipher under

theoretical circumstances requiring large amounts of known plaintext,

then, as pointed out by one Terry Ritter, an independent developer of

cryptographic software, any block cipher with an n-bit block size is

subject to an attack of complexity 2\^n requiring O(2\^n) known

plaintexts or exactly 2\^n chosen plaintexts: accumulate a complete

table of the block cipher\'s inputs and outputs.

In any event, while typical block cipher designs can provide for their

keys to be increased in size up to a certain limit (that of

independent subkeys) without otherwise modifying the operation of the

cipher, if indefinite increase of key length is a requirement, at

least the number of rounds will have to be subject to increase.

It seems that, in the absence of more specific guidance, the proposer

of a standard would need to offer more than one option for increasing

the key length, with various rates of increase in the time required to

apply the cipher as the key length increases.

A.5 AES shall either be a) freely available or b) available under

terms consistent with the American National Standards Institute (ANSI)

patent policy.

It may be noted that, as patents relating to the original Data

Encryption Standard and its experimental predecessor have expired, the

construction of a secure block cipher need not depend on proprietary

technologies, making this standard requirement particularly reasonable

in this case.

John Savard

====================

Response to NIST request for comments on requirements for AES

By Don B. Johnson, Certicom Jan 17, 1997

I have 3 comments:

1\. I believe the AES request should be reformulated to expand its
scope. Let me explain.

DES encryption can be characterized as a non-linear permutation mapping
a 64-bit input to a 64-bit output under control of a 56-bit key. DES
decryption is the inverse operation under control of the same key. There
are an additional 8 bits in the key that may be used for parity. The
group generated by the set of DES transformations is very large.

The experience we have had with DES has seen it used in many ways. For
example, review the following non-exhaustive list:

1\. MAC calculation (as in ANSI X9.9 and X9.19)

2\. Block data encryption (as in ANSI X3.106 CBC mode)

3\. Stream data encryption (as in ANSI X3.106 OFB mode)

4\. Symmetric key encryption (as in ANSI X9.17)

5\. Random number generation (as in ANSI X9.17 or ANSI X9.30)

6\. Nonce generation

I am sure others can easily add to this list.

This request to expand the question to reformulate its scope is based on
the analysis that each of the above uses has differing requirements.
These requirements sometimes come into conflict and cannot all be
satisfied, at least in the ideal scenarios. For example, an ideal n-bit
random number generator is expected to repeat after about n/2 samples
(due to the birthday phenomenon), while an ideal n-bit nonce generator
would not repeat until around n samples, that is, it would have a very
long cycle length.

This request to expand the scope is as follows:

1\. Identify the uses of symmetric key algorithms.

2\. For each use, identify the exact ideal security requirements.

3\. Accept proposals identified as meeting the requirements of each use.
It is obviously best if one solution can be transformed into another via
a relatively minor tweak, but this should not be assumed beforehand.

The goal is to obtain excellent solutions for each identified use. This
will allow solution design and architecture to be easier, as each
building block will be accepted in its use. Also, accepting this
suggestion may help avoid arguments over deciding the requirements for a
single AES algorithm.

2\. I note that the prevailing philosophy today is to design an
algorithm so that its security is associated with a variable that may be
increased. Asymmetric algorithms can have key size increases to address
increases in computation power. Similarly, I note that the call for
requirements identified variable key and block size as a likely
requirement for a symmetric algorithm. I believe there should be a
similar call for a variable length output one-way hash function. This
way, a system designer will be able to tailor all relevant security
sizes to the expected attack computation capability. Any solution will
be able to be balanced against all computation-based attacks. For
example, today SHA-1 has an output of 160 bits. This means that many
uses of SHA-1 depend on the unfeasibility of finding a collision in
about 2\*\*80 trials (due to the birthday phenomenon). 2\*\*80 trials is
considered infeasible in today\'s computing environment but may not be
in the future. There !

is no

need to arbitrarily limit this number.

3\. I believe the idea of defining parity bits in a DES key was a
particularly poor idea. As use of these bits imbeds redundancy inside a
key, they may be able to be used to help cryptanalyze a key. The parity
bits also pose interoperability problems, as a system may decide to set
and test, just set, or not set at all, each with different attributes
and advantages and disadvantages. I suggest that any symmetric key
definition contain only key bits and that any redundancy function on the
key bits to ensure integrity be defined independent of the key
definition.

====================

Return-Path: \<zimmer@dlcc.com\>

From: zimmerman \<zimmer@dlcc.com\>

To: \" \'aes@nist.gov\' \" \<aes@nist.gov\>

Subject: NIST Encryption Effort

Date: Tue, 21 Jan 1997 15:59:05 -0800

Encoding: 12 Text

Are you serious?

What makes you think that any user who has privacy

concerns would believe that their communications are

secure. NO government branch has any credibility for

concerns such as these.

davez

David Zimmerman

Hardware Engineer

Diamond Lane Communications Corp

zimmer@dlcc.com

707.792.2946 x144

====================

Memorandum

> Date: February 18, 1997

To:

From: M. Blake Greenlee

Subject: Comments on AES

I recommend that the AES have the following:

A. Technical Characteristics:

> 1\. Input block sizes of 64,128 and 256 bits.
>
> 2\. Key lengths (in bits) of:
>
> a\. 80
>
> b\. 96
>
> c\. 128
>
> 3\. Minimum internal structure (e.g., \"S-box\") length = 48 bits
>
> 4\. Speed to support at lease T3 encryption
>
> 5\. Implementable in hardware or software

These characteristics might be met in a set of algorithm specifications
that defined three configurations as indicated in the table, below.

Key Length Block Size Use

80 64 General purpose, hardware or software encryption; adequate for all
but

highest value transactions.

96 128 General purpose, perhaps much faster in hardware than software;
bulk

encryption.

128 256 High speed encryption devices (probably hardware); bulk
encryption of

files and data bases; high speed link encryptors.

If the above is attainable with a \"flexible\" algorithm, many needs can
be met, yet tailoring of implementation complexity to risk will be
possible. Fully flexible key length and block size may sound \"good\",
but will result in additional costs and design difficulties. In
particular, key and block lengths that are not multiples of 8 bits
should be forbidden.

B. Patent Licensing Characteristics

> 1\. The AES must be available with a free license to anyone
> implementing it as a part of implementing a F.I.P.S. ISO or ANSI
> standard.
>
> Unless a submitter of an algorithm agrees to this condition, the
> submission should not be accepted -- even for initial evaluation.
> Under no circumstances should the power of N.I.S.T. to \"bless\" a
> replacement for DES place any vendor or individual in a monopolistic
> position.
>
> 2\. In the unfortunate event that N.I.S.T. decides to accept an AES
> candidate that is patented, licensees must be able to implement the
> AES in an embodiment of their own choosing. Under no circumstances
> must licenses restrict users to \"toolkits.\"

====================

Comments from the Fast Software Encryption Workshop,

Submitted by Ross Anderson on 3/6/97

Advanced Encryption Standard

Draft minimum requirements and evaluation criteria

Abstract: This is the minute of a discussion held at the Fourth Fast
Software Encryption

Workshop, Haifa, Israel, on Monday January 20, 1997 from 15.30 to 16.30
on the

NIST call for comments on the Advanced Encryption Standard proposal. The

discussion was held in the presence of over 50 workshop participants
from all

over the world. These comments were collected during the discussion by
Ross

Anderson (the discussion chair), Bart Preneel, and Eli Biham, and then

circulated by email to the participants who submitted a few further

comments. The final draft was prepared by Ross Anderson.

General Comments

1\. It was asked whether there should be a standard at all, or

whether a diversity of algorithms might be safer and more adapted to

applications. (This argument had been advanced by the NSA in

opposition to the adoption of triple DES as a standard.) The

counterarguments were:

a\) that a standard would be adopted whether we like it or not and we

might as well help make it a good one

b\) for due diligence reasons, many clients would only use an

algorithm with a government seal of approval

c\) that a new standard would give an opportunity for many existing

systems to be redeveloped and serious vulnerabilities in protocols etc

removed

d\) that a new standard would concentrate cryptanalytic effort on a

single target, which (if unsuccessful) would increase confidence in

that target

e\) that the AES initiative presented an opportunity to establish a
standard

supported from the outset by government, industry and the academy.

2\. Public trust in the algorithm will be harder to build if the
rationale behind design

decisions is not made fully public, and if the public does not
participate in the

evaluation process. So the rationale behind all design decisions should
be completely explicit.

3\. It would be helpful if any S-boxes, constants etc should be chosen
by some

convincing method (such as at random from a sufficiently large space).
There are

two reasons for this. Firstly, if all the design choices are made by a
single person or

organization, then the algorithm will be less likely to be trusted;
trapdoors will be

suspected. On the other hand, we do not want a \`\`committee\'\' design.
A customisable

design is probably the best balance between these concerns. Secondly,

there are users who will want to customise a standard algorithm (see 11
below).

4\. We would favour a process in which the initial submissions are

whittled down to a short list of perhaps 3-4 candidates. This would

enable the community to concentrate the analysis and evaluation effort

on them rather than dispersing it on dozens of targets. (In this

workshop alone about ten ciphers were suggested, some of them having

several variants.)

5\. NIST should clarify the role of non-US citizens. Clearly, a new US

standard will (like DES) become widely used in other countries. Will

non-US submissions be acceptable?

6\. There is concern that the proposed timetable does not leave enough

time for serious cryptanalysis.

General Requirements

7\. It is not clear that one cipher can satisfy the requirements for

all applications, and on all kinds of processors (or special

hardware). The question arise whether we should have a family of

ciphers, appropriate for different environments.

For example, the majority of fielded DES implementations are on 8-bit

processors such as smartcards and microcontrollers, and used in

applications such as banking, power metering, pay-TV key management,

door locks, road tolls and the like. In such applications, the main

\`improvement\' sought from a DES successor is a reduction in code size.

On the other hand, the importance of intellectual property protection

is growing and there is wide use of stream ciphers in, for example,

pay-TV systems. Here, speed is a definite requirement and code size is

relatively unimportant. So NIST should consider whether there should

be two standards: a block cipher suitable for 8-bit processors, and a

stream cipher optimised for speed.

8\. There was wide condemnation of the draft proposal, that C source

code be evaluated on a PC. Ideally, a survey of applications, both

fielded and planned, should be undertaken so that the relative

importance of different performance metrics (speed, code size, etc)

could be evaluated and a realistic benchmark suite be specified. At

the very least, NIST should be much more explicit about the

performance requirements. We expand on this below.

9\. NIST should also provide a ranking for the various evaluation

criteria to clarify their relative importance.

Technical Requirements

10\. There should be procedures agreed in advance for dealing with any

weakness of the algorithm that arises later. This might be

predictable, such as an advance in chip technology that makes a longer

key necessary; unpredictable but minor, such as the discovery of a new

but rare class of weak keys; or catastrophic, such as a new shortcut

attack that forces a change to a completely different algorithm.

Several mechanisms are thus likely to be necessary including a review

body or process, a \`backup algorithm\' and perhaps (as suggested by

NIST) a means of increasing the keylength. There was no unanimity on

this last point however; an alternative would be to adopt an algorithm

with a keysize well beyond possible exhaustive search (e.g., 256 bits)

and use part of the keyspace as appropriate.

One possible \`backup algorithm\' is using the same algorithm with

different parameters, such as with a different set of S boxes. This

could provide a rapid and low-cost means of recovering from all but a

total break.

11\. There are other reasons to support customization by other means

than the key. In addition to the building public confidence in the

absence of trapdoors, as mentioned above, parametrisation will appeal

to those users who want a compromise between a proprietary algorithm

and a standard one - such as those who at present use DES with

nonstandard S-boxes or other modifications to prevent keysearch. The

successor to DES should be chosen so that it is not as difficult to

choose strong values of the S-boxes or other constants as it is in the

case of DES.

12\. An increasing number of applications involve cryptographic

authentication protocols (Kerberos being an example). Here, the

64-bit blocksize of DES is a disadvantage; the real requirement is to

encrypt variable length blocks. Many implementers use DES-CBC but

this can be vulnerable to cut and paste attacks. A block cipher of

variable width would be ideal for such applications.

13\. Some people felt that a 64 bit blocksize was inadequate for

security reasons, as once large volumes of data start to be

encrypted the volume limits set by the birthday paradox may be

approached.

14\. Given that the algorithm may be of variable width and may also

have a variable key length, thought needs to be given on how such

parameters will be securely expressed. The RC5 approach of packaging

the key in a \`control block\' with such parameters might provide

inspiration here, as could the IBM approach of \`key control vectors\'

to enforce a functional partition of the keyspace where applications

require this. We probably need an algorithm version number as well,

and \`fields to be defined later\'.

15\. In the event that the standardized algorithm is simply another

64-bit block cipher, there is a need for a standard mode of operation

that allows a variable length block to be encrypted with error

extension in both directions. More generally, it is time to look not

just at modes of operation but also at other supporting structures

such as APIs and lower level interface definitions.

16\. The algorithm should approximate to a random permutation as

closely as possible, e.g. there should be no equivalent keys, no

complementation properties, no related keys and no weak keys.

17\. The bit naming convention should be explicitly defined.

Security Requirements

18\. The types of attacks that the cipher must withstand must be

made explicit (e.g., known plaintext, chosen plaintext, adaptive

chosen plaintext/ciphertext, related-key).

19\. The security targets must be quantified, e.g. \' 2\^10 related

key queries, 2\^40 chosen plaintexts, 2\^50 storage, 2\^60

known plaintexts, 2\^80 effort\'.

20\. There must be minimum values set for security parameters,

such as number of rounds, block size and key size, in order to prevent

loss of confidence in the standard following a published attack on a

legitimate implementation.

Efficiency requirements

21\. As noted above, it was widely felt to be unwise to evaluate the

candidate algorithms solely on a PC, as the majority of DES

implementations are believed to run on 8-bit processors in embedded

applications. It appears to be prudent engineering practice to

optimise an algorithm for the slowest processor on which it will be

widely used - which might mean the 8051 (although 4-bit processors

are still used, and GOST appears to have been designed with these in

mind). It should also run adequately in Java, as the commercial

success of this language cannot be ignored.

PCs will be important, but we do not know whether the typical PC CPU

in five years time will be a RISC processor such as Alpha, a VLIW

processor such as Philips\' TriMedia, or a combination

superscalar/SIMD such as Klamath. Similarly, hardware/firmware

implementations (FPGA, ASIC, standard cell,\...) should be considered.

22\. Some applications, such as B-ISDN require fast key setup. The

evaluation criteria should therefore define a maximum key scheduling

delay; this might defined relative to encryption as a function of key

length. A possible alternative would be ability to cache a number of

round keys. However, while 1024 keys might be sufficient for current

ATM switches, more keys might be needed by future equipment.

23\. There should be targets for code size and memory size, especially

for implementations on smartcards and other 8-bit processors. For

hardware implementations, there should be a target gate count; and

for power-critical applications (such as contactless smartcards)

there should be a power target of microjoules per block encrypted.

Evaluation and interface requirements

24\. The process of evaluation should involve bounties to attract

serious and sustained attack. It is suggested that NIST offer a large

sum (say \\\$1m) for a significant shortcut attack. This should ensure

that anyone outside the sigint community who discovers such an attack

will report it rather than seek to exploit it. The shorter term

evaluation procedure should be also clarified: what incentives will

there be for outside contributors to invest effort in it?

25\. When reducing a large number of candidates to a shortlist, one

possible approach to the performance issue would be to define a

minimum speed relative to known ciphers such as DES or triple-DES.

However, some participants felt that many people are unaware of, or

have no access to, fast DES code for comparison.

26\. In any case, a thorough examination of the performance aspects

of shortlisted candidates should be carried out. As mentioned above,

there would ideally be a study of existing and planned applications

leading to the development of a benchmark suite. In the absence of

such an exercise, then at the very least the following should be

considered for each shortlisted candidate:

a\) code and memory size, especially on common smartcards and

microcontrollers

b\) speed, not just on currently common chips such as 8051 and Pentium

but also RISC and VLIW chips

c\) gate count for simplest and fully pipelined hardware
implementations.

Tradeoffs between speed and gate/count should be considered, as well

as the minimum number of microjoules per block encrypted

d\) whether software implementations are significantly different (or

more difficult) according to whether the processor is big endian

or little endian

e\) key agility, or round key memory requirements if cacheing is

preferred for B-ISDN applications

f\) whether there is a well understood tradeoff between number of

rounds and attack effort

27\. NIST should define a standard interface for the algorithms in

order to facilitate validation by the wider crypto community.

28\. Ease of validation is important. A single test vector is not

enough: the algorithm designer should supply a full set of test

vectors, plus a validation suite that exercises them via the

standard interface mentioned above and performs any other tests

required to check all single points of failure and thus ensure

that an implementation is correct.

29\. Submissions should include not just one or more implementations

optimized for speed or memory size on various processors but also an

easy-to-read endian-indifferent one, so that correspondence with the

description of the cipher can be readily checked.

30\. Finally, the evaluation criteria should be more carefully drafted.

For example, criteria (b), (c) and (d) overlap, and it is not clear

what exactly is meant by \`simplicity\' and \`flexibility\'.

====================

Comments on AES Federal Register Notice

3/9/97

Dear Sirs,

I applaud your invitation for comments on a proposed AES. I am
submitting comments based on my 20 years experience as an information
security practitioner in the financial services industry, probably the
largest private sector implementor of national cryptographic standards.
In general I agree with your proposed criteria, with the following
input:

1\. I would make one modification to A.5: AES must be freely available
(i.e., no license fee), as is DES.

The remainder of my comments are additions to A.1 - A.6.

2\. AES must be exportable.

3\. I agree with Don B. Johnson\'s (Certicom) comments #1 and 3, dated
1/17/97. I assume he sent them to you, so I will not repeat them here.
If you do not have them please feel free to contact me. (I also agree
with his comment #2, but think it should be a separate request as it
does not deal directly with an AES algorithm.)

4\. There must be a well defined (backward compatible) migration path
from DES to AES (or some variant thereof). The banking industry has a
huge installed base of DES and could not afford to scrap it all.

5\. An AES validation process must be in place at the time the AES is
announced.

If you have any questions on the above, please feel free to contact me.

Respectfully submitted,

Sandra M. Lambert

Lambert & Associates

Voice & fax: (213) 469-6978

====================

Return-Path: \<rivest@theory.lcs.mit.edu\>

From: rivest@theory.lcs.mit.edu (Ron Rivest)

Date: Sat, 22 Mar 97 14:09:29 EST

To: AES@nist.gov

Subject: Comments on the proposed FIPS for AES

To: Director, Computer Systems Laboratory

Attn: FIPS for AES comments

Technology Building, Room A231, NIST, Gaitherburg, MD 20899

From: Professor Ronald L. Rivest, MIT Lab for Computer Science

Date: March 22, 1997

Re: AES criteria

Here are some comments on the Advanced Encryption Standard proposal and

procedures, as per your request for comments. These comments are listed

individually in no particular order.

1\. In general, it\'s nice to see that you are finally getting around to

replacing DES. It\'s about time!

2\. While I presume that 3DES will be submitted, you should be sure

to include it as a candidate in any case. (This suggestion is

somewhat inconsistent with my other comments, such as the one

on block size.)

3\. All submissions should be made public, and there should be a

public comment period on the submissions. You should not allow

proprietary submissions that may not be so published. Any such

submissions, and the publication of such submissions by NIST, should

of course be exempt from export regulations. You should post all

of the submissions on the World Wide Web.

4\. All deliberations and considerations on the selection of the AEA

should be public. In particular, the role of the NSA in the

evaluation procedure should be explicit and public. I would propose

that NSA stay out of the picture until the number of viable candidates

is down to a small handful, at which time NSA may wish to publically

comment on the security of one or more of them. The timetable

for the selection of AES should be sufficiently relaxed that

sufficient public comment and scrutiny is achieved. In particular,

the final candidate should be announced and comments

solicited before the decision is made final.

5\. Criterion A.3 should be reworded to say: \"AES shall be designed

to accept keys of variable length, from 0 to at least 256 bits,

inclusive, in one-bit increments.\" (The wording you have is

unnecessarily vague.)

6\. You don\'t say enough about the block length. Criterion A.2 should

be more specific here. I think that a block length of at least

128 bits should be specified, with explicit encouragement for larger

block sizes or even variable block sizes. The small block size of

DES has been the source of many difficulties. A block length of

160 bits or greater makes \"birthday\"-type attacks succeed with

probability at most 2\*\*(-80), which is satisfactorily small.

7\. You don\'t give any guidelines regarding key setup time. A short

setup time promotes key agility, which is needed in many network

contexts. A longer setup time hinders brute-force attacks. What

would you like? (Of course, you can have a variable setup time, too.)

8\. You don\'t mention a natural consideration for software-oriented

algorithms: whether it should be \"little-endian\" or \"big-endian\"

in style. I refer, of course, to the issue of the order in which

bytes are stored in a word. A little-endian bias favors Intel

architectures, whereas a big-endian approach favors other

architectures. Such \"fine points\" can noticeably affect the speed

of the algorithms, according to which machine they are run on.

(While you do specify a PC, you don\'t suggest such a bias.)

Of course, for some algorithms this issue is irrelevant. I suggest

that you specify that the \"target PC\" is little-endian.

9\. An algorithm should be accompanied by some indication as

to why it is free of \"trap-doors\". The derivation of and

justification for any tables or arbitrary parameters should be required

as part of the submission. If programs were used to derive the

tables or parameters, they should be included with the submission.

10\. The submitter should include not just a single input/output

example, but a proposed \"validation suite\" of examples to test

an implementation to see if it is correct. (This might be of

an iterative nature, to minimize the size of the suite given.

The encryption algorithm might be repeatedly applied to its own

output, for example, and the result after 100 iterations given.

For each iteration the key used would be derived from the previous

outputs as well.)

11\. A submission should clearly indicate if there are any known

weak keys or semi-weak keys. The submission should indicate what

special care, if any, should be taken in key selection, if this

process is other than just randomly picking a bit string of the

appropriate length.

12\. It is often desirable for organization such as banks to have their

own \"proprietary\" version of a standard algorithm. You may wish

to encourage submitters to indicate how such variants could be

derived from the standard algorithm in a way that does not affect

the security of the resulting algorithm.

13\. If there are other limitations on the algorithm design, such as

whether it should be implementable on current smart cards, or

whether it should be efficiently parallelizable on high-end

processors, then these limitations and criteria should be made

explicit, or at least listed as explicit biases for the evaluation.

14\. You do not say whether submissions from outside the U.S. are
welcome.

I presume therefore that they are welcome. It would help to be

more explicit on this point. You also could be more explicit

regarding international patent issues. (Would you accept an algorithm

that was patented only in Japan, but not in the U.S., when there was

no guarantee of reasonable licensing availability in Japan? This

would affect our multinational corporations.)

15\. It would help to inspire confidence in the algorithm chosen if you

were to adopt an explicit program of continual review, both by the

NSA and by non-governmental cryptanalysts (who might be paid by their

employers or by government grants). This program would continue

indefinitely.

16\. It should be explicit that use of the new algorithm is independent
of

any other issues of cryptographic policy. If, for example, the new

algorithm were patented and licenses were to be made available only

within the context of a key-recovery or key-escrow mechanism, then

the whole standards effort is likely to fail as it falls into this

policy tar-pit. It should be clear that the new algorithm can be used

with no more constraints than any published, unpatented, algorithm

could be, with respect to such requirements.

\-\-\-- end \-\-\--

=============

Return-Path: \<vallhonrat@worldnet.att.net\>

From: \"Eleanor & Juan Vallhonrat\" \<vallhonrat@worldnet.att.net\>

To: \"AES NIST\" \<AES@nist.gov\>

Cc: \"Lang Wedgeworth\" \<hpwlaw@prysm.net\>, \"Joe Morgan\"
\<morganj@arn.net\>

Subject: AES Comments from Gemini Systems

Date: Tue, 25 Mar 1997 11:08:05 -0600

X-Msmail-Priority: Normal

25 March, 1997

Director, Computer Systems Laboratory

Attn.: FIPS for AES Comments

Submitted by: Joseph M. Morgan and Juan B. Vallhonrat

Gemini Systems

Ladies and Gentlemen:

In your announcement of the AES workshop you include the following text

from the 1993

reaffirmation of DES:

\`\`At the next review (1998), the algorithm specified in this standard
will

be over twenty

years old. NIST will consider alternatives which offer a higher level of

security. One of

these alternatives may be proposed as a replacement standard at the 1998

review.\'\'

The way this wise statement is worded it implies to us that the
alternative

could be a truly

new standard altogether, rather than just a new algorithm.

In reading the proposed draft Minimum Acceptability Requirements it
appears

to us that

concepts which are 20 years old are being perpetuated. We respectfully

suggest that

perhaps what the encryption standard needs is a complete paradigm
change.

The

requirements enumerated, for example, a symmetric block cipher, are
based

on DES with

the exception that the key length may be increased as needed. Why would
a

new

algorithm be restricted to be symmetric? Why would it be restricted to

operate on fixed

length blocks of data? Relaxation of these two factors would, in itself,

offer a higher level

of security.

Instead of endorsing a single new fixed algorithm, our suggested
paradigm

change

envisions an AES which would provide the umbrella under which algorithms

could be built

by invoking a sequence of AES protocol compliant encryption components.

The AES

should define the framework for a component based encryption system
(CBES).

Such a

system would consist of a set of encryption primitives from which the

components would

be built. These primitives would include logical and mathematical

operations, bit

movement and management operations, data and key management operations,

etc.

The components, which are created from the AES sanctioned primitives,
would

be

categorized into functional groups such as:

Key Manipulations and Management

Data Delivery

Permutations

Data Separation and Concatenation

Substitutions

etc.

There would be an AES defined protocol for each group of components. The

components

would be developed by numerous sources, yet they each would need to
comply

with the

AES protocol for the category for which they were designed. Encryption

algorithms

would be designed by combining several components via a component base

interface

(CBI).

With the ever increasing and varying needs for encryption it is hard to

imagine how one

single algorithm could satisfy all requirements. With a CBES like

standard, the

component protocols become the standard, not a specific algorithm. This

would provide a

fertile environment where algorithms would be developed to fulfill

application specific

requirements. There would not be one single criteria with which to judge

speed or

memory requirements, as those criteria would be application dependent
and

proportional

to the degree of security required in the given application.

A CBES like standard would encourage creativeness and allow for the

emergence of

numerous third-party component vendors. For example, some vendors might

perfect key

management, while others may perfect substitution. The encryption

developer would

pick and choose from numerous components to fulfill the security

requirements of the

specific application by instructing the CBI as to which components to
use

and in which

order to use them during the encryption process.

In order to allow for a smooth transition to a new standard the existing

algorithms can be

implemented under this proposed CBES like standard exactly as the

algorithms are

presently defined. If a further evolutionary transition is desired one

could also easily

strengthen such algorithms. For example, the components used to
implement

DES can be

modified to increase the key length, and/or add more rounds, and/or vary

key shifting,

and/or change the S-boxes, etc. The possibilities are endless.

If CBES is to be endorsed, the Minimum Acceptability Requirements and

Evaluation

Criteria together with the Submission Requirements would have to be
drafted

from

scratch. For example, when DES was implemented 20 years ago, memory

requirements

for an algorithm was a terribly important consideration. Today memory

requirements take

on an entirely different light. The same goes for hardware
implementation

when one

considers that a good part of present day hardware is really firmware.

While in the last 20 years there have been revolutionary changes in

hardware, software,

and communications, the encryption standard has remained unchanged. Some

may praise

its staying power, while others may consider it an anchor to progress.
Let

us now

consider a truly flexible and dynamic standard which can adapt and
evolve

with the advent

of new technology.

We are looking forward to some lively discussions during the upcoming

workshop.

END

===============

Return-Path: \<ritter@io.com\>

X-Sender: ritter@mail.io.com (Unverified)

Date: Tue, 25 Mar 1997 16:56:45 -0600

To: AES@nist.gov

From: Terry Ritter \<ritter@io.com\>

Subject: COMMENTS ON CHOOSING THE ADVANCED ENCRYPTION STANDARD

COMMENTS ON CHOOSING THE ADVANCED ENCRYPTION STANDARD

In the National Institute of Standards and Technology:

A Response to \[Docket No. 960924272-6272-01\] by:

Terry Ritter, Registered Professional Engineer

ritter@io.com http://www.io.com/\~ritter/

Ritter Software Engineering

2609 Choctaw Trail

Austin, Texas 78745

\(512\) 892-0494

Here are my recommendations for a new ciphering standard intended

to assist The United States well into the next century:

1\. To be considered for the AES, candidate ciphers should have a

keyspace of 120 bits or more.

2\. To be considered for the AES, candidate ciphers should have a

block size of 128 bits.

3\. Ideally, the AES would also support much larger blocks, 64 bytes

wide and beyond. Large blocks are important to support features

generally not possible in a smaller block, and thus not currently

available to DES users. These include: ciphering without needing

plaintext randomization (allowing ECB mode), zero latency dynamic

keying, strong validation values, and homophonic control.

4\. Ideally, this standardization process would produce multiple

acceptable ciphers for each of multiple categories of ciphering

application. We should resist the idea that there can be only

\*one\* \"standard\" cipher. Cipher users are the appropriate

authority for any selection among acceptable ciphers.

5\. It is difficult to know what draft requirement A.3 (requiring

candidate ciphers to be able to \"increase key length\") is about:

If A.3 is about supporting a key of arbitrary length, presumably

through some associated hashing process, that is a good idea.

But if A.3 is about having a parameter to adjust the internal

keyspace, this is probably not a good idea. The typical way to

provide such a parameter would essentially \*reduce\* the native

strength of the cipher \*without\* any compensating advantages in

resource use or throughput. This would be a mistake.

6\. Draft requirement A.6(b) (computational efficiency) should be

more detailed, such as:

Ciphering rate, in bytes per second, for repeatedly

ciphering a single block in memory, using any named

operating system, and any named CPU chip X at clock

speed Y. The ciphering rate must be listed for a

version in high level C, but additional values may be

presented for other versions, possibly using

assembly-language.

Setup or initialization time, in seconds, for each

ciphering rate measurement.

It might be useful to additionally require values for some

widely-available CPU, with results normalized to a standard

clock speed, such as Pentium CPU (w/o MMX) normalized to

100 MHz.

A.6(b) is also the appropriate place for comments regarding

the advantages of custom hardware realizations, although no

such hardware need actually exist, so that actual performance

measurements will not be available.

7\. Draft requirement A.6(f) (flexibility) seems like an attempt

to get a single cipher for all applications. But, in ciphering,

one size does \*not\* fit all.

Certainly a cipher \*technology\* can be scalable across a wide

range of resource costs and throughput targets. But a particular

\*cipher\* probably will have some inflexible decisions which will

optimize it for a particular environment.

We should instead define \*groups of applications\* with similar

requirements, and then define the appropriate ciphers for each

group.

Smart cards might be a group which would be particularly

sensitive to computation and memory requirements. Larger

systems, where memory is not constrained, might be another

group (even entry-level PC\'s now often have 16MB of RAM).

8\. Draft requirement B.2 (source code) should also be more detailed:

Source code for each system measured in A.6(b), should be

delivered both as printed text and as ASCII text files on

a 3.5\" 1.44 MB floppy in IBM PC format. Simple drivers

for A.6(b) and B.4 should be included.

9\. I am aware of sentiment to restrict the AES to unpatented

algorithms or to require a free grant of rights by the patent

holder. But considering that patent rights are granted by the

very same U.S. Government now making a selection, any attempt

to ignore patented designs would be very disturbing.

If you want this selection process to continue well into the

new millennium, all you need to do is to treat some participant

class unfairly, and the whole issue will end up in court for

a very long time.

10\. I am also aware of comments that AES should be a stream cipher,

because (it is said) a stream cipher can be 10 times as fast

as a block cipher. Having personally developed and patented new

fundamental technology for both stream and block ciphers, and

having personally implemented a wide variety of stream and block

ciphers, I question such conclusions. In my experience, software

realizations of stream and block ciphers with comparable strength

tend to have surprisingly comparable throughputs.

In hardware realizations, it seems likely that block cipher

architectures which support massively parallel operations

\*must\* be much faster than \"equivalent\" stream ciphers.

11\. I am also aware of sentiment that the AES should run on all

platforms from \"smart cards\" to Alpha workstations. I think

this would necessarily compromise the strength of the AES

by inherently eliminating many of the advantages that two

decades of semiconductor progress have bought us, including

large amounts of storage and modern CPU design.

If it is necessary to have a cipher for \"smart cards,\" that

should be a different standard.

If there are to be limits on RAM storage, they should reflect

the situation of a modern desktop computer with 16 megabytes

of RAM. By the time a new standard is effective, 64 megabytes

could be very common. AES should make use of common computation

capabilities to deliver serious strength and performance.

12\. I am also aware of attempts to limit candidate designs based

on ratios of enciphering vs. deciphering speeds or setup vs.

ciphering, etc. Such comparisons are misguided, in that they

could eliminate a cipher which is superior in absolute terms.

13\. My last comment is that while cipher \"strength\" is clearly our

ultimate goal, it is \*only\* a goal, because it cannot be

measured. Rather than relying upon such analysis as may have

occurred in the \"open academic literature,\" I would hope that

the National Security Agency would be enlisted to perform a

scientific analysis of each acceptable candidate. While there

may be some motive to minimize the content of such comments,

they must be sufficiently factual and forthcoming to allow

external comparison across a wide range of categories and

benefits, instead of being simple \"yes / no\" conclusions.

\-\--

Terry Ritter ritter@io.com http://www.io.com/\~ritter/

===================

Return-Path: \<dkatz@aba.com\>

Date: Wed, 26 Mar 1997 14:39:00 -0500

From: Deborah Katz \<dkatz@aba.com\>

To: AES@nist.gov

Subject: ASC X9 Comments on AES

(Embedded in email message AND attached as a Word 6.0 file)

March 26, 1997

TO: Director, Computer Systems Laboratory

Attn: FIPS for AES Comments

Technology Building, Room A231,

National Institute of Standards and Technology

Gaithersburg, MD 20899

From: Cindy Fuller, X9 Secretariat

Accredited Standards Committee X9 - Financial Services, an
ANSI-accredited

committee, has achieved consensus on the following list of comments for
the

first phase of the Advanced Encryption Standard (AES) development.

1\) Consideration should be given to the transition time for the
financial

industry to migrate to any proposed new encryption standard. The
transition

time is expected to take from two to five years once the new AES has
been

selected and approved. Along with the next federal register announcement

regarding the algorithm selection process, a proposed timetable should
be

published to include the following:

a\) Algorithm testing and selection schedule

b\) A one year public scrutiny period used to find flaws and fix them

c\) Validation (NVLAP, etc.) methodology availability

2\) Many in the financial industry are beginning to use ANSI X9.52,
Triple

DES. Even though this may be a transition tool being used until
widespread

AES availability, NIST should recognize this reality and continue to
support

DES in this context and other appropriate contexts for as long as is
prudent

from a security perspective.

3\) The financial industry of the United States must protect the flow of

funds and related information both inside and outside of this country\*s

borders. X9 realizes that making an algorithm exportable under the
current

regulations are outside the scope of the selection of any symmetric

encryption algorithm. However, once AES has been selected, every

consideration (including changing current regulations) must be given to

ensure that our financial industry can continue to compete on an

international basis while protecting its data with an algorithm of

sufficient strength.

4\) If AES is to become a cost effective solution, it must be free of
any

unreasonable patent issues.

In addition, AES must be freely implementable in any way that a vendor

chooses. No license constraint (associated with any patent) should
dictate

that the AES can only be implemented in a specific manner or with a
specific

vendor\*s \*tool kit\* or software package. This will allow the
marketplace to

provide more competitive and secure alternatives.

AES must be royalty-free.

5\) The AES algorithm should have an associated (NVLAP or other)
initiative

that provides a mechanism that will validate AES implementations.

6\) Ideally only one AES should be selected to satisfy all requirements.
However,

there are many uses that AES will be subject to, such as:

a\) MAC calculation (as in ANSI X9.9 and X9.19)

b\) Block data encryption (as in ANSI X3.106 CBC mode)

c\) Stream data encryption (as in ANSI X3.106 OFB mode)

d\) Symmetric key encryption (as in ANSI X9.17)

e\) Random number generation (as in ANSI X9.17 or ANSI X9.30)

f\) Nonce generation

g\) Key-derivation techniques, such as DUKPT (as in ANSI X9.24, Section

4.8 and Appendix E)

7\) AES should not use parity bits for keys. The use of these bits
imbeds redundancy

inside a key, which may be used to cryptanalyze a key. The parity bits
also pose interoperability

problems based on the different ways that communicating systems use
these parity bits. There is

anecdotal evidence in the financial industry concerning implementation
delays and costs

associated with the use of parity bits for keys. No corresponding
benefit for the use of parity bits

for keys has been documented. Therefore, symmetric key definitions
should contain only key bits.

Any redundancy function on the key bits to ensure integrity should be
defined independent of the

key definition.

8\) There are only three criteria to be considered for the evaluation of
AES. These criteria

listed in order of relative importance are:

a\) Security - which defines the capaibility of the AES to withstand
cryptanalysis or

exhaustive key search.

b\) Total cost - including CPU cycle cost (computational efficiency) and
memory

allocation costs.

While cost factors are considered in the aggregate, any single drawback
(e.g.,

computational efficiency) may rule out an algorithm if this attribute
makes AES

infeasible. However, NIST should be careful not to discard too quickly a
poor

implementation of a good AES candidate. History has shown that large

differences in computational efficiency for the same algorithm depend on
the

implementation techniques used. Once AES is exposed to commercial

development and optimization, computational efficiency advances will be
made.

For measurement purposes - many very large financial institutions that
use the

fastest commercial mainframe processors use DES engines with a
single-engine

throughput of about 112 million bytes per second.

c\) System Feasibility - the ability to design, develop, implement, and
operate the

AES on a variety of industry platforms (for example, ATMs, POS devices,
user

workstations, servers, and mainframes); using a variety of technology
support

devices (for example, dongles, smart cards, PCMCIA cards, various PC
boards,

and a variety of integrate encryption engines).

===================

Return-Path: \<Bill_Poletti@MASTERCARD.COM\>

To: aes \<aes@nist.gov\>

Cc: Melinda Yee/NYC/MASTERCARD
\<Melinda_Yee/NYC/MASTERCARD@MASTERCARD.COM\>,

Dennis Allen/STL/MASTERCARD
\<Dennis_Allen/STL/MASTERCARD@MASTERCARD.COM\>,

dkatz \<dkatz@aba.com\>

From: Bill Poletti/STL/MASTERCARD

\<Bill_Poletti@MASTERCARD.COM\>

Date: 26 Mar 97 10:47:54 EDT

Subject: MasterCard comments regarding AES

Director, Computer Systems Laboratory

Attn: FIPS for AES Comments

Technology Building

Room A231

National Institute of Standards and Technology

Gaithersburg, MD 20899.

Dear Sir:

MasterCard appreciates the opportunity to respond to the AES FIPS
proposal.

The following represents the position of MasterCard in addition to the
comments

previously submitted by the ANSI X9 Secretariat.

\"The use of keys should not be restricted to a single or fixed length

mechanism. Key lengths should be variable with the extension of key size

effectively not limited by the algorithm. Recommended minimum key
lengths

should be made as part of the standard, but additional key lengths
should be

easily implemented without the need to re-write the standard.\"

If you have any questions, please let me know eiher by email or a call.

Bill Poletti

Manager, Information Security, Cryptography

MasterCard International, Inc.

=====================

27 March 1997

Director, Computer Systems Laboratory

Attn: FIPS for AES Comments

Technology Building, Room A231

National Institute of Standards and Technology

Gaithersburg, MD 20899

RE: Advanced Encryption Standard

Dear Mr. Director:

This letter is in response to your request for comments on the proposal
to

develop a FIPS for an Advanced Encryption Standard (AES). As author of

Applied Cryptography and cryptography consultant to dozens of different

hardware and software companies, I feel I have a good inkling of what
the

commercial community needs from an AES.

In general, I think it is an excellent idea for NIST to oversee the

development and adoption of a standard enryption algorithm to replace
DES.

While DES is an excellent encryption algorithm, its key length is
clearly

too small for today\'s security needs. The commercial security community
is

unlikely to converge on a single replacement algorithm on their own, and
a

new NIST standard will go far to increase public confidence in
cryptography.

I agree that the AES should be a publicly defined algorithm, but I

hesitiate to require it to be a block cipher. I find that most of my

clients are satisfied with triple-DES if they need a block cipher. The

biggest hole in my array of good algorithms is a fast stream cipher with
a

low gate count. Steam ciphers can probably run about ten times faster
than

comparible block ciphers; it makes more sense for triple-DES to continue
to

be used for applications where a block cipher is required, and that the
AES

address the bulk-encryption problem with a suitable stream cipher.

If a block algorithm is required, I suggest requiring a 128-bit block.
The

current generation of 64-bit block ciphers are becomming more and more

vulnerable to attacks based on the block size.

I agree that the AES should have a variable key length and implementable
in

both software and hardware. However, I strongly feel that any

government-endorsed algorithm should be available free for all uses,
like

DES is. Patented algorithms should not be considered, unless the

patent-holder is willing to grant free world wide rights as IBM did with

DES.

With regards to your factors for judging, the issues are far more subtle

than your list indicates. \"Computational efficiency\" and \"hardware
and

software suitability\" are very complex metrics. You have to
differentiate

between the time required to set up a key with the time required to
encrypt

an amount of plaintext after key setup. Some algorithms have very

efficient key-setup routines; others are very slow. This efficiency and

suitability also depends strongly on the type of processor. An AES will
be

used on platforms ranging from 8-bit microprocessors on smart cards to
64

bit Alpha workstations, as well as platforms that haven\'t been
developed

yet. On hardware, speed is often a function of gate count. Algorithms
can

often run very quickly if they are implemented in a large number of
gates,

and slowly if they are implemented in a small number of gates.

I feel that efficiency should be judged on slow 8-bit platforms. The

desktop machines are getting faster every year; almost any algorithm is

efficient on those platforms. I recently wrote a paper on fast

implementations of algorithms on Pentium machines; the number of clock

cycles required for encrypting a single block of plaintext (20 clocks
per

byte encrypted for Blowfish; 24 cocks per byte encrypted for CAST) were

remarkably close. A factor of 4 or 5 is not very much when processor

speeds double every 18 months. The low end, however, will always be with

us, and it is constrained both in processor power and available RAM. And

as cryptography becomes more of a consumer item, it will find its way
more

into the low end.

Hardware efficiency should be judged on the basis of flexibility: the

algorithm should be implementable in both small-gate-count and

large-gate-count variants, with appropriate variances in speed.

In any case, there should be clearly-defined minimum acceptability

requirements for efficiency. I suggest the following:

Encryption no slower than DES on any platform (e.g. at most 360

clock cycles per block on a Pentium).

Key setup no more than 5 times the speed to encrypt one block.

Encryption and decryption speeds within 10% of each other.

Implementable in hardware with a total table size of less than 256

bytes.

Hardware enryption throughput of one block per clock cycle (given

enough gates), with a maximum encryption/decryption latency of 16

clock cycles.

Minimum RAM requirements (RAM only, not code or tables) of no more

than 64 bytes on an 8-bit smart-card processor.

Software implementation should favor little-endian machines.

With regards to your draft submission requirements, I suggest that you

provide standard function calls in ANSI C that the software
implementation

should conform to. This will greatly simplify comparison testing, by

providing a standard interface for comparison. These calls should test

bulk encryption as well as key-setup.

You should also require test vectors (possibly a standard suite) that
can

be used to verify any implementation of the algorithm, as well as a

copyright-free reference implementation. And in addition to a

cryptanalysis of the algorithm, you should require an explanation of the

design rationale.

Finally, I think we need to think more about the process of evaluation.

Assuming you are looking to choose an algorithm in 1998, any set of

candidates will only get a year or so of analysis before a choice is
made.

Unless you are sure that an existing block cipher with more than a

couple-years\' analysis (i.e. triple-DES, IDEA, Blowfish, RC5, Khufu,
CAST,

and SAFER) meets your requirements, this is far too short a time to
develop

and analyze a new algorithm. Perhaps it might be smarter to adopt

triple-DES as a short-term fix, and spend the next few years developing
a

completely new algorithm for long-term use.

The benefits of this approach is that we can then develop an algorithm
with

all sorts of useful features not generally present in the list of
algorithm

suggested above:

Both block modes and a stream modes, with the steam modes at least

five times faster than the block modes.

A standard hash-function mode. (While I understand that SHA-1 is

NIST\'s standard for hashing, many hardware modules cannot afford the

silicon necessay to implement SHA-1. If they are already using AES,

they will want to use it for hashing as well.)

A standard MAC (Message Authentication Code) mode.

A mechanism for improving the algorithm, in the field, in the event

that an unforseen weakness is discovered after approval.

Variablility in the algorithm to provide a family key for different

applications. (Sometimes companies want their algorithm to be

proprietary in some way; it makes sense to give them a harmless way

to do this.)

In any case, you should consider finding a panel of cryptanalytic
experts

to quickly weed out bad candidates, spending money on public
cryptanalysis

of the top contenders, and offering bounties for successful
cryptanalyses

of top contenders. I suspect you will get many algorithms that are not

worthy of serious consideration, and eliminating them quickly will allow

the serious contenders to receive more analysis.

I applaud your efforts to develop a new encryption standard, and I look

forward to attending your AES Criteria Workshop on 15 April 97 to futher

discuss these issues.

Sincerely,

/s/ Bruce Schneier

=====================

(From RSA Laboratories)

March 28, 1997

The Director

Computer Systems Laboratory

Attn.: FIPS for AES Comments

Technology Building

Room A231

National Institute of Standards and Technology

Gaithersburg, MD 20899

Dear Director,

It is with great interest that RSA Laboratories has noted the intended
development of a forthcoming Advanced Encryption Standard.

The existing draft Minimum Acceptability Requirements and Evaluation
Criteria cover many important issues and offer good working guidelines
to some of the issues that must be addressed during the review of a
submitted algorithm. We note, however, that the draft listed in the
Federal Register on January 2, 1997 leaves various aspects of the
process unspecified.

We expect that many of the outstanding detailed technical considerations
will be discussed at the meeting of April 15, 1997. At this point,
therefore, we would like to highlight some issues that might usefully be
noted prior to that meeting. All are general in nature and most are
related to issues of procedure.

1\. The exact aim of the Advanced Encryption Standard should be
clarified.

> •Is it intended that proposals for the Advanced Encryption Standard be
> judged solely on their merit as encryption algorithms? While block
> ciphers are primarily used for encryption, they are often used in
> other ways. As an example, block ciphers have been used as the basis
> for hash functions and as a building block in the process of providing
> message authentication codes. It would be valuable to specify at the
> outset exactly what the uses and applications of the forthcoming
> Advanced Encryption Algorithm are intended to be. By doing this,
> criteria more relevant to an application not under direct
> consideration can be separated from those used to assess an algorithm
> for it\'s intended roles.

2\. The anticipated timetable and procedures adopted during the
development of an Advanced Encryption Standard should be clearly
defined.

> • Is the aim to have an Advanced Encryption Standard in place by 1998,
> so that it can be immediately deployed as a replacement to DES? If so,
> the whole effort will be under a great deal of time pressure.
>
> • Is there adequate time to allow for a thorough analysis of the
> different submissions?
>
> • What happens if all the submissions are rejected as being
> inadequate? Will there be a second call for submissions? Will an
> alternative algorithm be proposed for immediate adoption so as to
> avoid a period during which no encryption algorithm would be approved
> for government use?

3\. It can be anticipated that several algorithms will satisfy certain
Minimum Evaluation Requirements and that further, more detailed,
evaluation will be required.

> •Which groups or persons will be responsible for this advanced
> assessment?
>
> •Will the results of this assessment be made public, including any
> cryptanalytic techniques that might have been used in assessing the
> security of a proposed cipher?
>
> •Will the open cryptographic community be involved in the process of
> assessing all aspects of the suitability of some cipher?
>
> •It is very likely that some aspect of a candidate algorithm might
> appear to be in conflict with another. A common example would be that
> of security and performance. How is it intended that any potential
> conflict between a \"fast but sufficiently-secure\" cipher and a
> \"secure but sufficiently-fast\" cipher be resolved?
>
> •It is very important that a clear prioritization between the possible
> attributes of a submission be established ahead of time. It might in
> fact be desirable to consider quantifying and setting certain minimum
> goals that a candidate algorithm must surpass. Perhaps a specific
> target speed of encryption for different environments should be set,
> along with some minimum goals on the amount of data required for a
> successful cryptanalytic attack along with a minimum required work
> effort to recover a key.
>
> •How will the final decision on which submission is the most suitable
> be made?

4\. There is some ambiguity in some of the terms used in the current
draft Minimum Acceptability Requirements and Evaluation Criteria.

> •Terms and criteria such as \"simplicity\", \"hardware and software
> suitability\" and \"statement of computational efficiency in hardware
> and software\", for example, are vague and open to a great deal of
> conflicting interpretation. We would suggest that the final Minimum
> Acceptability Requirements and Evaluation Criteria and the final
> Submission Requirements be more specific in such issues so as to avoid
> misinterpretation.

5\. Some issues with regard to the assessment of an algorithm might be
considered for inclusion in the Minimum Acceptability Requirements and
Evaluation Criteria.

> • In the evaluation of any algorithm, it is important to recognize
> whether the algorithm has already been the subject of widespread
> scrutiny and analysis. In this way, the algorithm might already have
> achieved a certain level of trust, thereby making the process of
> acceptance by the cryptographic community that much easier. As a
> consequence, a list of related and published cryptanalytic work would
> make an essential addition to any algorithm submission. It is also
> important to realize that there is a great deal of difference between
> whether an algorithm has been available in the public domain for a
> number of years and whether it has, in fact, been the subject of a
> serious cryptanalytic effort.
>
> •An algorithm submission should be accompanied with a full explanation
> of the design rationale used for the algorithm. In addition, the
> method used to generate any cryptographic S-boxes, and the method used
> in choosing any constants or other terms that appear in the algorithm
> should be described.

The issues highlighted in the points above are merely representative of
some of the more detailed questions we have on the draft Minimum
Acceptability Requirements and Evaluation Criteria as they have been
published.

We anticipate that the meeting of April 15, 1997 will be very useful in
addressing many of the issues we have raised. We also expect it to be
very productive in setting out more of the details required in assessing
the relative merits of any proposal for the forthcoming Advanced
Encryption Standard.

Yours sincerely,

Matthew J.B. Robshaw

=====================

Return-Path: \<Dan_Nessett@3mail.3com.com\>

X-Sender: dnessett@tdc.3com.com

Date: Mon, 31 Mar 1997 17:09:48 -0800

To: AES@nist.gov

From: Dan Nessett \<Dan_Nessett@3mail.3com.com\>

Subject: Evaluation criteria for the advanced encryption standard

To : The Director, Computer Systems Laboratory

National Institute of Standards and Technology

Dear Sir,

Please accept the following evaluation criteria for the Advanced

Encryption Standard currently under study by NIST. They are the result
of

input from various senior engineers and managers at 3Com Corporation :

1\. The most important criteria that will affect acceptibility of the

standard by commercial vendors is the availability of an exportable
version

(perhaps tied to key length). Large corporations, such as 3Com, not only

ship a large percentage of their products overseas, they also have

engineering divisions outside of the United States that work on products

requiring cryptographic services. In addition, the engineering

organizations, manufacturing facilities and sales channels of such

corporations are not designed to differentiate between domestic and

international versions of a product.

It must be possible to design, manufacture, sell, deploy and maintain a

product that uses cryptography in a single version that can be shipped
both

domestically and internationally. Achieving these objectives must not

increase the cost of the product substantially (a maximum of 1-2% for

minimally acceptible implementations). In addition, the algorithm should

allow implementors to trade-off cost versus strength of protection.

To achieve these objective, the algorithm should be designed to support
a

wide range of cryptographic strengths and allow a single implementation
to

be tailored in the field for the strength appropriate for particular

markets. Such tailoring cannot introduce significant engineering,

manufacturing, marketing, sales, deployment or maintenance costs.

2\. The standard should be tailorable to a wide variety of applications
and

implementation platforms. The algorithm should be suitable for high
asset

value applications, such as business strategic planning and financial

transactions as well as low asset value applications, such as protecting

casual communications between individuals.

In addition, the standard should be appropriate for implementation in
high

performance computing equipment as well as mobile or hand-held
platforms,

such as Personal Digital Assistants. The algorithm should lend itself to

efficient (both in terms of gate count and total delay from input to

output) implementations in hardware. The algorithm should be structured
so

that its components could be used for other purposes, such as computing
a

message authentication code, one-way hash, or digital signature.

Finding a single algorithm with the requisite flexibility, efficiency
and

strength may be difficult, but is a primary requirement of a useful
Federal

Encryption Standard. One way to meet this goal would be to choose an

algorithm that scales in terms of strength, implementation complexity
and

(degradation of) performance as the key size increases. The algorithm

should have properties (e.g., not form a group under composition), so it

can be applied in multiple super-encryption modes, such as triple-DES.

3\. The lifetime of the algorithm should be sufficient to justify its

deployment. At a minimum, the algorithm should be useful in some form
for

at least 20 (preferably 30) years after acceptance.

4\. The algorithm will be used to provide such services as message

authenticity, integrity and confidentiality. Consequently, it will not
only

be used alone, but also in tandem with other cryptographic algorithms,
such

as message authentication codes and digital signatures. The algorithm

should be designed to compliment these other cryptographic services to
the

best extent possible.

5\. Certain applications, such as email and computer communications,
carry

content that is variable in sensitivity. The current approach is to
protect

the content as if all of it had a sensitivity equal to its most
sensitive

parts. This usually implies higher computational costs, and thus, lower

performance than may be necessary.

The standard should allow the interleaving of ciphertext produced by

different gradations in the strength of the cryptographic algorithm.

Important characteristics in this regard are fast rekeying, and
efficient

accommodation of different key lengths by a single implementation. If
the

computational work to produce internal state from an input key is large
as

compared to the computational work to encrypt a plaintext block, the

algorithm should allow implementations to quickly protect and dump that

state to external storage and allow them to quickly and efficiently
restore

that state at a later point in time. The speed and efficiency of these

operations should be measured relative to the speed and work required to

encrypt a single block of plaintext. Furthermore, the amount of memory

required to represent the internal state associated with a key should be
no

more than 100 times the key length.

Respectfully yours,

Dan Nessett

=====================

Return-Path: \<100142.1670@CompuServe.COM\>

Date: 01 Apr 97 17:29:01 EST

From: Steve Mathews \<100142.1670@CompuServe.COM\>

To: AES review \<AES@nist.gov\>

Subject: Comments

We wish to submit the following comments and observations on the AES
proposal.

AES acceptability requirements and evaluation criteria

Comments upon current criteria.

A.2 AES shall be a symmetric cipher which may operate in block mode or
in

stream mode.

A.3 AES shall be designed such that the key length is alterable such
that an

increase in the key length equates to an increase in the overall
security (i.e.

the effort required to cryptanalize),

A.6.b) computational efficiency having regard to the security (i.e. the

effort required to cryptanalyze), in both hardware and software,

It is not clear if the criteria in A.5 b) would also meet the ISO/IEC
criteria,

and thus avoid export and/or problems in other jurisdictions.

The evaluation criteria put security as the first criterion and
computational

efficiency second. Risk analysis restates Juvenal\'s comment \"Omnia
Romae cum

pretio,\" literally \'anything may be had for a price\'. There must be a
trade of

these two, (the others are corollaries of the main price), so they
should be

considered first among equals rather than first and second.

We are intending to provide a representative to the Gaithersburg
meeting.

Kind regards.

Steve Mathews

PCSL, Dallas.

================

Director, Computer Systems Laboratory

Attn: FIPS for AES Comments

Technology Building, Room A231

National Institute of Standards and Technology

Gaithersburg, MD 20899

Trusted Information Systems, Inc. appreciates the opportunity to provide

comments on the draft minimum acceptability requirements for an Advanced

Encryption Standard (AES) that NIST has published as a first step in

development of a new Federal Information Processing Standard, pursuant
to

its responsibilities under the Computer Security Act of 1987, the

Information Technology Management Reform Act of 1996, Executive Order
13011,

and OMB Circular A-130. Public visibility and input are critical factors

for the success of this undertaking. By including a mechanism for public

comment and other inputs at the beginning of the FIPS development
process,

NIST\'s first steps are in the right direction in this regard.

Overall, the draft requirements comprise a reasonable starting point for

identification of suitable candidate algorithms. Our comments focus on
four

areas that merit further attention:

· importance of public scrutiny of the candidate algorithm(s)

· availability of algorithm(s) for worldwide use

· need for a multiyear transition period

· concerns over requirement for variable key length

Importance of Public Scrutiny

The solicitation for comments implies an open process will be used for

development of the new FIPS, including public scrutiny of candidate

algorithms. Adequate public scrutiny of candidate algorithms, as well as

public review and critiquing of testing and evaluation results, will be

crucial to public acceptance of and confidence in the NEA.

In effect, the \"DES model\" should be used for selection and approval
of the

new standard. Although iterative public inspection and will lengthen the

time required to promulgate the new FIPS, the extra time and care at the

front end will result in a standard with a longer useful lifetime and
wider

utilization. The durability of the Data Encryption Standard and its

international acceptance (despite initial public skepticism) is due to
the

thorough public scrutiny it underwent.

The lessons of history with respect to the promulgation of cryptographic

FIPS are: (1) mistrust and suspicions fostered by lack of public
visibility

and participation cannot be overcome by the technical quality of an

algorithm and (2) for the purposes of building trust and user
acceptance,

\"vetting\" of a proposed standard by limited-membership bodies cannot

replace open public inspection

Availability for Worldwide Use

Even though the NES will be promulgated for government use, the reality
of

the Global Information Infrastructure is that it will come to be used by

various communities within the United States and beyond its borders.

Therefore, the candidate algorithm(s) must be available for worldwide
use.

Multiyear Transition Period

NIST has correctly anticipated that \"a multi-year transition period
will be

necessary to move toward any new encryption standard.\" Allowing
sufficient

time for a graceful phase-in of the NES will allow users to recoup the

investment that have made in DES and enable producers to gear up
production

of products implementing the new FIPS algorithm(s). However, because DES

has proved to be so popular and durable and has been adopted in numerous

other standards, the time remaining until the end of the present

certification period is unlikely to be \"sufficient time\" for a
graceful

transition to a brand-new FIPS.

Requirement for Variable Key Length

Criterion A.3 states, \"AES shall be designed so that the key length may
be

increased as needed.\" The requirement for a variable key length is
cause

for concern, in that it may preclude alternatives like Triple DES from

consideration as a candidate for the new FIPS. It is not clear that the

objective of a durable new FIPS necessarily requires an adjustable key
length.

====================

Return-Path: \<tmcdermo@missint.missilab.com\>

Date: Wed, 02 Apr 1997 14:37:00 -0500 (E)

From: \"McDermott, Thomas\" \<tmcdermo@missint.missilab.com\>

Subject: NSA comments on criteria for AES

To: NIST \<AES@NIST.GOV\>

Cc: Brian Snow \<bsnow@radium.ncsc.mil\>

Encoding: 66 TEXT

Director, Information Technology Laboratory, NIST

In accordance with our technical advisory role under the Computer

Security Act of 1987, we are pleased to offer the following in response

to your call for comments on \"Proposed Draft Minimum Acceptability

Requirements and Evaluation Criteria\" for an Advanced Encryption

Standard, as published in the Federal Register of January 2, 1997.

The National Security Agency\'s Information Systems Security

Organization strongly supports your proposal to develop a FIPS for an

advanced encryption algorithm using a public process and welcomes the

opportunity to comment.

While we believe any algorithm can be implemented in hardware or

software, certainly computational efficiency is an important

consideration; we suggest that minimum specified requirements in this

area should be detailed. For example, we recommend that hardware

implementations of the selected algorithm must be able to encrypt data

at a minimum of 1 Gb/s, pipelined if necessary, in existing

technology.

Another additional important factor is key agility; that is the ability

to rapidly change cryptovariables so as to simultaneously support

multiple processes in applications such as ATM. Here, we believe, a

goal should be that two blocks could be enciphered with different keys

in virtually the same time as two blocks could be enciphered with the

same key.

Finally, given the requirement for a symmetric block cipher algorithm,

we recommend the consideration of a 128 bit block size supporting

multiple modes including CBC, ECB, and counter driven modes.

We feel strongly than any algorithm selected should be patent free

and/or available to all users free of charge. Patented algorithms

should not be considered unless the patent holder is willing to grant

free usage as was the case with the adoption of DES.

Finally, in regard to algorithm flexibility, we caution that the more

design parameter value combinations allowed, the more difficult it is

to evaluate the security of the algorithm and to enable

interoperability across a broad range of users and supporting

protocols. Ideally, a fixed width for the codebook, a fixed number of

steps, and a fixed key length would make for the easiest and quickest

evaluation and promote greater interoperability.

If some of these parameters must vary, we point out that the full set

of permissible value combinations must be specified, understanding, of

course, that each point in the design parameter space yields a distinct

algorithm for evaluation.

My point of contact for technical discussions is Brian Snow, INFOSEC

Technical Director. He can be reached at (301) 688-8199, (301) 688-3090

facsimile, or bsnow@dockmaster.ncsc.mil.

THOMAS J. McDERMOTT

Deputy Director

for

Information Systems Security

National Security Agency

=================

Return-Path: \<romeror@FRB.GOV\>

From: romeror@FRB.GOV

Date: Wed, 2 Apr 1997 16:35:12 -0500

To: AES@nist.gov

Cc: romeror@FRB.GOV

Content-Description: cc:Mail note part

April 2, 1997

Dr. Chukri A. Wakid

Director, Computer Systems Laboratory,

Attention: FIPS For AES Comments

Technology Building, Room A231

National Institute of

Standards and Technology

Gaithersburg, MD 20899

Dear Sir,

This letter is in response to the request for comment issued by

the National Institute of Standards and Technology (NIST) on the

Advance Encryption Standard (AES) draft acceptability requirements and

evaluation criteria. Over the past 20 years, the financial services

industry has been well served by the current Data Encryption Standard

(DES). Technological developments, however, necessitate establishing

a more secure standard. The Federal Reserve endorses NIST\'s current

efforts to establish an Advance Encryption Standard and support the

open and collaborative approach in which this is being accomplished.

We hope you find the comments listed below beneficial in finalizing

the AES acceptability requirements and evaluation criteria.

1\. Requirement A.2 does not qualify the block size. We recommend

that A.2 should qualify a selectable block size or a block size of at

least 128 bits.

2\. Requirement A.3 will have the effect of disqualifying Triple

DES as an AES alternative. We recommend that A.3 be revised to

include a minimum key length as an alternative to the ability to

increase the key length.

Requirement A.3 should also qualify whether the block size must

also be increased to correspond with an increase in the key length.

Requirement A.3 should also specify that parity bits should not

be used for keys. The use of these bits imbeds redundancy inside a

key, which may be used to cryptanalyze a key. The parity bits also

pose interoperability problems based on the different ways that

communicating systems use these parity bits. There is anecdotal

evidence in the financial industry concerning implementation delays

and costs associated with the use of parity bits for keys. No

corresponding benefit for the use of parity bits for keys has been

documented. Therefore, symmetric key definitions should contain only

key bits.

3\. Requirement A.5 should also reference the International

Standards Organization\'s patent policy.

4\. The seven criteria listed in A.6 (a through g) should be

combined into three evaluation criteria. Moreover, the evaluation

criteria should be listed in order of importance. Provided below are

the evaluation criteria we would recommend listed in order of

importance:

a\) Security - the strength of AES to withstand cryptanalysis

or exhaustive key search. (Includes criteria A.6.a)

b\) System Feasibility - the ability to design, develop,

implement, and operate the AES on a variety of industry platforms such

as ATMs, Point of Sale Devices, User Workstations and Servers, and

Mainframes, based on a variety of devices such as smart cards, PCMCIA

cards, PC boards, and integrated encryption engines. (Includes

criteria A.6.d, e, and f )

c\) Cost - total cost of the AES based on licensing fees,

computational efficiency, and memory requirements. (Includes criteria

A.6.b, c, and g)

5\. The AES algorithm should have an associated National Voluntary

Laboratory Accreditation Program (NVLAP) or other initiative that

provides a mechanism for validating AES implementations.

6\. Ideally only one algorithm should be selected as the AES.

However, there are many uses that AES will be subject to, such as,

message authentication, block data encryption, stream data encryption,

symmetric key encryption, random number generation, nonce generation,

and key-derivation techniques. A single algorithm, however, may not

serve all these requirements effectively. Consequently, NIST may want

to consider selecting more than one algorithm based on performance for

different applications.

7\. Given the significant install base of DES, NIST should also

consider features that would allow for a seamless and cost effective

transition to a new standard.

8\. NIST should consider establishing a timetable for algorithm

selection and testing. Moreover, a one year public scrutiny period

should be instituted following the selection of an algorithm so flaws

can be identified and corrected before the standard is finalized.

9\. Consideration should be given to the transition time for the

financial services industry to migrate to AES. It is anticipated that

the time required to migrate to a new encryption algorithm may take

five to seven years after the standard is finalized. During this

transition period, DES will continue to play an important role in

protecting information. Moreover, many in the financial services

industry my utilize a variation on DES, such as Triple DES (ANSI

X9.52), during this transitional period as a means of reinforcing

existing cryptography infrastructures. The Federal Reserve currently

uses DES and is analyzing the use of Triple DES. Therefore, the

Federal Reserve encourages NIST to continue support for DES during

this transitional period. Attached is a press release from the

Federal Reserve related to its evaluation of Triple DES.

If you have any questions about these comments, please contact

Mr. Raymond Romero at (202) 452-6474 or via E-mail at romeror@frb.gov.

Sincerely,

/S/

Clyde H. Farnsworth, Jr.

Attachment

For Release: Contact:

April 2, 1997 Joe Elstner, St. Louis -

\(314\) 444-8902

Sandra Conlan, San Francisco - (415)

974-3231

Gwen Byer, Richmond - (804) 697-8105

Federal Reserve is Evaluating Triple DES

ST. LOUIS\--The Federal Reserve is evaluating an advanced application

of the Data Encryption Standard (DES), known as Triple DES, to protect

data that are transmitted electronically between the Federal Reserve

Banks and between the Federal Reserve and financial institutions.

Federal Reserve officials said that if the new standard proves

effective, an announcement about actual implementation can be expected

in early 1998.

The Federal Reserve is an active participant in the X9 committee of

the American National Standards Institute (ANSI), which is completing

a standards document for Triple DES. \"Our active role in developing

improved data security techniques, of which Triple DES is one

component, helps provide assurance that transactions with the Federal

Reserve will continue to be safe and secure from cryptographic crime,\"

said Bruce J. Summers, director of automation resources for the

Federal Reserve. \"This year we will be testing Triple DES and working

on an implementation plan, coordinating with vendors of encryption

products and our customers.\"

The Federal Reserve currently uses DES to secure electronic

information and will spend the next several months completing its

analysis of Triple DES. \"Triple DES significantly increases data

security because it invokes DES three times,\" Summers said. \"With

each iteration, it is possible to use a different encryption key

value, which results in a longer overall key value that is far more

resistant to attack.\" Certain Triple DES operating modes are also

compatible with the Fed\'s current DES implementations, which will

ensure a smoother transition for Federal Reserve customers.

The Fed is also following a National Institute of Standards and

Technology (NIST) project to develop an advanced encryption standard

to eventually replace DES. Summers believes that, while the Fed

should closely monitor such activities and study other options being

developed, it must be at the forefront of data security

implementations and be prepared to use Triple DES to provide continued

security until a new standard is ready. \"Our evaluation of Triple DES

is a continuation of the Fed\'s efforts to ensure that the highest

levels of security are applied to Federal Reserve operations and

payment services,\" said Summers.

===============

Return-Path: \<Cadams@entrust.com\>

From: Carlisle Adams \<Cadams@entrust.com\>

To: \"\'AES@nist.gov\'\" \<AES@nist.gov\>

Subject: Comments on AES Criteria\...

Date: Wed, 2 Apr 1997 18:35:22 -0500

Encoding: 160 TEXT

Entrust Technologies

2 Constellation Crescent

Nepean, Ontario, Canada

K2G 5J9

\> 2 April 1997

\>

\>

\>Director, Computer Systems Laboratory,

\>Attn: FIPS for AES Comments,

\>Technology Building, Room A231,

\>National Institute of Standards and Technology,

\>Gaithersburg, MD 20899

\>

\>Dear Director:

Please find below comments with respect to the \"Proposed Draft Minimum

Acceptability Requirements and Evaluation Criteria\" which was published

on January 2nd of this year. It is our understanding that these

comments will be made part of the public record.

Sincerely,

Carlisle M. Adams, Ph.D.

Senior Cryptographer,

Entrust Technologies

cadams@entrust.com

\>PROPOSED DRAFT MINIMUM ACCEPTABILITY REQUIREMENTS AND EVALUATION
CRITERIA

\>

\>The draft minimum acceptability requirements and evaluation criteria
are:

\>

\>A.1 AES shall be publicly defined.

\>

\>A.2 AES shall be a symmetric block cipher.

\>

\>A.3 AES shall be designed so that the key length may be increased as
needed.

A.3 AES shall be designed so that the key length may be increased as

needed (up to some appropriate maximum).

\>A.4 AES shall be implementable in both hardware and software.

A.4 AES shall be economically implementable in both hardware and

software.

\>A.5 AES shall either be a) freely available or b) available under
terms

\>consistent with the American National Standards Institute (ANSI)
patent

policy.

A.5 AES shall be freely available.

A.6 AES shall be amenable to short messages and to environments in

which keys are changed frequently (i.e., any set-up time required for

the algorithm, prior to encryption/decryption, shall not be

prohibitive).

\>A.6 Algorithms which meet the above requirements will be judged based
on

A.7 \...

\>the following factors:

\>

\>a) security (i.e., the effort required to cryptanalyze),

\>b) computational efficiency,

b\) computational efficiency (particularly in software and firmware),

\>c) memory requirements,

\>d) hardware and software suitability,

\>e) simplicity,

\>f) flexibility, and

\>g) licensing requirements.

\>

\>Comments are being sought on these draft minimum acceptability
criteria and

\>evaluation criteria, suggestions for other criteria, and relative
importance

\>of each individual criterion in the evaluation process. Criteria will
be

\>finalized by NIST following the criteria workshop.

\>

\>PROPOSED DRAFT SUBMISSION REQUIREMENTS

\>

\>In order to provide for an orderly, fair, and timely evaluation of
candidate

\>algorithm proposals, submission requirements will specify the
procedures and

\>supporting documentation necessary to submit a candidate algorithm.

\>

\>B.1 A complete written specification of the algorithm including all

\>necessary mathematical equations, tables, and parameters needed to
implement

\>the algorithm.

\>

\>B.2 Software implementation and source code, in ANSI C code, which
will

\>compile on a personal computer. This code will be used to compare
software

\>performance and memory requirements with respect to other algorithms.

B.2 Software implementation and source code, in ANSI C code, which will

compile on an IBM-compatible personal computer. This code will be used

to compare software performance and memory requirements with respect to

other algorithms.

\>B.3 Statement of estimated computational efficiency in hardware and

software.

B.3 Statement, with sufficient justification, of estimated

computational efficiency in hardware and software (or specific

performance figures, if these are available).

\>B.4 Encryption example mapping a specified plaintext value into
ciphertext.

B.4 Encryption example mapping a specified plaintext value into

ciphertext (i.e., test vectors showing expected ciphertext for given

plaintext/key pairs so that implementations can be verified for

correctness).

\>B.5 Statement of licensing requirements and patents which may be
infringed

\>by implementations of this algorithm.

\>

\>B.6 An analysis of the algorithm with respect to known attacks.

B.6 A detailed analysis of the algorithm, including published papers

evaluating the strength of the algorithm with respect to known attacks.

\>B.7 Statement of advantages and limitations of the submitted
algorithm.

====================

Return-Path: \<alpoplove@its.cse.dnd.ca\>

From: \"A. L. Poplove\" \<alpoplove@its.cse.dnd.ca\>

To: \"\'AES@nist.gov\'\" \<AES@nist.gov\>

Cc: \"A. L. Poplove\" \<alpoplove@its.cse.dnd.ca\>

Subject: FW: comments on AES proposal

Date: Tue, 8 Apr 1997 16:44:56 -0400

\-\-\-\-\-\-\-\-\--

Dear Dir/ITL

In accordance with your request, I would like to re-submit the

following comments with regard to the AES proposal. Ted Elliott, a

colleague of mine at CSE, will submit his comments separately.

Thanks, Alan Poplove Cryptomath UnitHead , Communications Security

Establishment, Ottawa, Canada

Regarding A.3

There is some ambiguity about what is meant by \"AES shall be designed

so the key length may be increased as needed\"; i.e. does NIST mean

that the users can simply choose their key spaces with an algorithm

which allows this variation; or does it mean that the AEA does have a

fixed key space, and that future versions/upgrades of the AEA may have

larger key spaces? I favour that latter.

Regarding A.6 (a) and B.6; \"Algorithms to be judged on Security\...\"

and a submission requirement of \"an analysis of the algorithm with

respect to known attacks\"

Algorithms should be shown, in a mathematically-explicit manner, by

the submitting party to be resistant to all potential cryptanalytic

attacks. However, as a condition of submission, it should be

recognized that the security evaluation may include classified

analysis, the results of which may cause an otherwise attractive

contender to be dismissed. It should be accepted that the results of

any classified analysis will not be released.

Regarding A.6 (g) and B.5: We recommend that AES should be available

with a free license to anyone implementing it.

Regarding A.6 (f) \"Flexibility\" should be defined. Does this refer to

supporting multiple uses?

===================

Comments Submitted to NIST Regarding the AES Draft FIPS

I wish to submit the following comments on the AES draft FIPS for NIST.
These

are my personal recommendations and shall not be taken to represent

either the official CSE view nor the official view of the Government

of Canada, at this time.

1\. U.S. Patent 5,559,993 issued 24 Sept \'96 to our Minister of

National Defence provides, in hardware, the ability to lock any

software, for example, the subject i.e. AES algorithm(s), i.e. AEA,

complete, if desired with any related AEA keymat, and/or AEA key

generation software, behind read-ONLY hardware technology, the subject

of my/our invention. Corresponding Canadian and European patent

protection is also assigned to our Minister. An MFM prototype, an IDE,

SCSI, and MFM prototype have been built. A further commercial design

is being studied for cost and feasibility by one of our allies for a

law enforcement application. Our Minister may wish to consider the

utility of allowing this technology to be released under suitable

terms, for any specified U.S. and/or international use, within such an

AES FIPS framework. This is related to Section A.5 of the draft.

2\. My paper also refers to this subject, which was published in the

Proceedings of the NIST/NCSC 17th National Computer Security

Conference, October 11-14, 1994, Vol 1, pages 274-282.

3\. Entrust (TM) digital signature, with the corresponding PKI

infrastructure of the Government of Canada, may provide an additional

mechanism for both wrapping the subject i.e. AES algorithm(s), i.e.

AEA complete, if desired with any related AEA keymat and/or AEA key

generation software, to assure its integrity, and verify its integrity

at any time after creation, forming part of the security of any

proposed AEA implementation under the AES.

4\. Section A.4 as written does not appear to cover any proposal in

software which is implemented \"behind\" such hardware integrity

control. This section implies a proposal must be implement/able/ed in

BOTH software and hardware, as presently worded, yet I don\'t think

that was intended. Does AES as drafted include keymat and does it

include session generating software code?

5\. Section A.6 subsections e), f), g) are assured in my view by our

hardware device of item 1. above.

6\. Evaluation methodology in this current draft is not in my view

sufficiently described to take account of this high integrity

protection approach for the cryptographic components of AES and AEA.

7\. I will give my personal support to Mr.

Poplove during his attendance at your workshop, if there are any
questions.

Thank you.

T.E. (Ted) Elliott

Tel. 613-991-7506

FAX 613-991-7411

==================

Return-Path: \<sori@iss.isl.melco.co.jp\>

To: Jim Foti \<foti@st1.ncsl.nist.gov\>

Cc: etakeda@iss.isl.melco.co.jp, atsuhiro@iss.isl.melco.co.jp,

matsui@iss.isl.melco.co.jp, kondo@syskai.hoku.melco.co.jp,

WBoyles@MSM.mea.com, sori@iss.isl.melco.co.jp

Subject: Re: Preliminary agenda for AES workshop

Date: Thu, 10 Apr 1997 23:30:46 +0900

From: \"T.SORIMACHI\" \<sori@iss.isl.melco.co.jp\>

Dear Mr.Jim Foti:

My name is Tohru Sorimachi.

This E_Mail is comments of

\"PROPOSED DRAFT MINIMUM ACCEPTABILITY REQUIREMENTS

AND EVALUATION CRITERIA\"

1\. In order to implement variable key length in H/W,

I think it is required to specify maximum key length to be extended

and key length notch to be increased.

e.g. key length: from 128bits to 256 bits max.

key notch : 32bits i.e. 128bits,160bits,\....,224bits,256bits

as a sequence.

We agree with all other criteria.

2\. Since AES will be the world wide standard at least as a defacto,

please allow to submitt the proposals as a criteria and also of

algorithms from the other countries besides U.S.

Regards, Tohru Sorimachi.