Advanced Encryption Standard (AES) Selection
Process – How Rijndael Won
MIDN 1/c Kevin Lee
20 March 2015
Capstone – SM463A
MIDN 1/c Kevin Lee
Table of Contents
1. Abstract
2. Rijndael Algorithm
2.1. Rijndael Term Definitions
2.2. Rijndael Parameters, Symbols, and Functions
2.3. Rijndael Specifics
2.3.a. The Round Transformation
2.3.b. The ByteSub Transformation
2.3.c. The ShiftRows Transformation
2.3.d. The MixColumns Transformation
2.3.e. The Round Key Addition
2.3.f. Key Schedule
2.3.f.1. Key Expansion
3. Creation of AES
3.1. AES Round 1
3.1.a. Round 1 Analyses
3.1.b. PC
3.1.c. Sun
3.1.d. SGI
3.1.e. Conclusion
3.1.f. AES Round 2 Selection
3.2. AES Round 2
3.2.a. Summaries of Finalists
3.2.b. Round 2 Analyses
3.2.b.1. Efficiency Testing
3.2.b.1.a. Cycle Count Testing
4. Conclusion
3
3
3
4
5
6
6
7
8
9
9
10
11
11
12
12
13
14
15
16
16
17
18
18
18
22
2
Capstone – SM463A
MIDN 1/c Kevin Lee
1. Abstract
The following paper will discuss the current Advance Encryption Standard (AES), Rijndael
Algorithm, established by the United States National Institute of Standards and Technology
(NIST). AES is the standard currently used by U.S. Government agencies to protect classified
information and implemented in software and hardware throughout the world to encrypt sensitive
data. This paper will also take an in depth look into the process used by NIST to select AES and
how Rijndael Algorithm was ultimately selected.
This paper is divided into three sections. The first section will discuss Rijndael Algorithm, the
parameters of the algorithm, and execution of the algorithm. The second and third sections will
describe the selection process of AES and how Rijndael Algorithm was ultimately selected. The
second section will discuss the analysis conducted on the fifteen algorithms submitted to select
the five finalists and the third section will discuss the analysis conducts on the finalists to declare
a winner.
2. Rijndael Algorithm
Two Belgium cryptographers, Joan Daemen and Vincent Rijmen, created the Rijndael Algorithm
and submitted their algorithm to NIST in 1998, in response to a call to develop an Advance
Encryption Standard. Their design of Rijndael was based on the three criteria: resistance against
all known attacks, speed and code compactness on a wide range of platforms, and design
simplicity [7].
2.1. Rijndael Definitions
In order to discuss the Rijndael Algorithm, basic definitions need to be established to under the
various steps and components of the algorithm. The following definitions are derived from NIST
and the Rijndael proposal submission [3].
Affine Transformation A transformation consisting of multiplication by a matrix followed by
the addition of a vector.
Array
An enumerated collection of identical entities (e.g., an array of bytes).
Block
Sequence of binary bits that comprise the input, output, State, and
Round Key. The length of a sequence is the number of bits it contains.
Blocks are also interpreted as arrays of bytes.
Cipher
Series of transformations that converts plaintext to ciphertext using the
Cipher Key.
3
Capstone – SM463A
MIDN 1/c Kevin Lee
Cipher Key
Secret, cryptographic key that is used by the Key Expansion routine to
generate a set of Round Keys; can be pictured as a rectangular array of
bytes, having four rows and Nk = 4, 6, or 8 columns.
Ciphertext
Data output from the Cipher or input to the Inverse Cipher.
Inverse Cipher
Series of transformations that converts ciphertext to plaintext using the
Cipher Key.
Key Expansion
Routine used to generate a series of Round Keys from the Cipher Key.
Plaintext
Data input to the Cipher or output from the Inverse Cipher.
Round Key
Round keys are values derived from the Cipher Key using the Key
Expansion routine; they are applied to the State in the Cipher and
Inverse Cipher.
State
Intermediate Cipher result that can be pictured as a rectangular array of
bytes, having four rows and Nb = 4 columns.
S-box
Non-linear substitution table used in several byte substitution
transformations and in the Key Expansion routine to perform a one-forone substitution of a byte value.
Word
A group of 32 bits that is treated either as a single entity or as an array
of 4 bytes.
2.2. Rijndael Parameters, Symbols, and Functions
The following parameters, symbols, and functions are also necessary to understand the various
steps and components of Rijndael Algorithm. These parameters, symbols, and functions are also
derived from NIST and the Rijndael proposal submission [3].
AddRoundKey()
Transformation in the Cipher and Inverse Cipher in which a Round Key is
added to the State using an XOR operation. The length of a Round Key
equals the size of the State (i.e., for Nb = 4, the Round Key length equals
128 bits/16 bytes).
InvMixColumns() Transformation in the Inverse Cipher that is the inverse of MixColumns().
InvShiftRows()
Transformation in the Inverse Cipher that is the inverse of ShiftRows().
InvSubBytes()
Transformation in the Inverse Cipher that is the inverse of SubBytes().
4
Capstone – SM463A
MIDN 1/c Kevin Lee
K
Cipher Key.
MixColumns()
Transformation in the Cipher that takes all of the columns of the State and
mixes their data (independently of one another) to produce new columns.
Nb
Number of columns (32-bit words) comprising the State. For this standard,
Nb = 4.
Nk
Number of 32-bit words comprising the Cipher Key. For this standard, Nk
= 4, 6, or 8.
Nr
Number of rounds, which is a function of Nk and Nb (which is fixed). For
this standard, Nr = 10, 12, or 14.
Rcon[]
The round constant word array.
RotWord()
Function used in the Key Expansion routine that takes a four-byte word
and performs a cyclic permutation.
ShiftRows()
Transformation in the Cipher that processes the State by cyclically shifting
the last three rows of the State by different offsets.
SubBytes()
Transformation in the Cipher that processes the State using a nonlinear
byte substitution table (S-box) that operates on each of the State bytes
independently.
SubWord()
Function used in the Key Expansion routine that takes a four-byte input
word and applies an S-box to each of the four bytes to produce an output
word.
XOR
Exclusive-OR operation.
Exclusive-OR operation.
Multiplication of two polynomials (each with degree < 4) modulo x4 + 1.

Finite field multiplication.
2.3. Rijndael Specifics
Rijndael is an iterated block cipher and certain aspects of Rijndael Algorithm are specified. The
block and key length can be independently specified to 128-bits, 192-bits, or 256-bits [4]. The
various transformations throughout Rijndael operate on the State. The State is represented as an
5
Capstone – SM463A
MIDN 1/c Kevin Lee
array of bytes that has four rows and Nb columns which is equal to the block length divided by
32. The Cipher Key is also represented as an array of bytes of four rows and Nk columns which
is equal to the key length divided by 32 [3].
The input and output of Rijndael at the external interface are considered arrays of bytes,
numbered from 0 to 4*Nb-1. Thus, the blocks have lengths of 16-bytes, 24-bytes, or 32-bytes
and are indexed from 0…15, 0…23, or 0…31 respectively [3]. The Cipher Key is also
considered an array of bytes at the external interface, numbered from 0 to 4*Nk-1, and may also
have lengths of 16-bytes, 24-bytes, or 32-bytes and is indexed from 0…15, 0…23, 0…31
respectively.
The number of rounds, represented by Nr, is based on the values of Nb and Nk. The round totals
are denoted in Table 1 [3].
Nr
Nk = 4
Nk = 6
Nk = 8
Nb = 4
10
12
14
Nb = 6
12
12
14
Nb = 8
14
14
14
Table 1
2.3.a. The Round Transformation
At the beginning of Rijndael Algorithm, the input array is converted to the State array. The
Round Transformation consists of four individual byte-transformations for each round which
include ByteSub Transformation, ShiftRow Transformation, MixColumn Transformation,
and the Round Key Addition. The final Round Transformation, based on Table 1, is the same as
the Round Transformation minus the MixColumn Transformation [3].
The pseudo code in represented in Figure 1 [3].
Round(State, RoundKey)
{ByteSub(State);
ShiftRow(State);
MixColumn(State);
AddRoundKey(State,
RoundKey);}
FinalRound(State, RoundKey)
{ByteSub(State);
ShiftRow(State);
AddRoundKey(State,
RoundKey);}
Figure 1
6
Capstone – SM463A
MIDN 1/c Kevin Lee
2.3.a.1. The ByteSub Transformation
The ByteSub Transformation operates on each byte of the State independently. It is a nonlinear byte substitution. The substitution table, or S-box, is invertible and is created by the
composition of:
1. Take the multiplicative inverse in the finite field GF(28); the element {00} is mapped
to itself
2. Apply an affine (over GF(2)) transformation defined by Figure 2 [3]:
Figure 2
Figure 3 represents the ByteSub Transformation on the State [8].
Figure 3
2.3.a.2. The ShiftRows Transformation
During the ShiftRows Transformation, the rows of the State are shifted by a prescribed
number of bytes. Row 0 is never shifted, row 1 is shifted by d1 bytes, row 2 is shifted by d2
bytes, and row 3 is shifted by d3 bytes. The shift values of d1, d2, and d3 depend of the block
length Nb. Table 2 denotes the values for d1, d2, and d3 dependent on Nb [3].
7
Capstone – SM463A
Nb
4
6
8
MIDN 1/c Kevin Lee
d1
1
1
1
d2
2
2
3
d3
3
3
4
Table 2
Figure 4 represents the ShiftRows Transformation on the State [3].
Figure 4
2.3.a.3. The MixColumns Transformation
The MixColumns Transformation operates on each column of the State individually. A column
of the State is considered a polynomial over GF(28) and multiplied modulo x4 + 1 with a fixed
polynomial c(x) given by:
c(x) = ‘03’x3 + ‘01’x2 + ‘01’x + ‘02’ [3]
This transformation can be represented by matrix multiplication in Figure 5 [8]. Let s’(x) = c(x)
 s(x), thus:
Figure 5
8
Capstone – SM463A
MIDN 1/c Kevin Lee
Figure 6 is an illustration of how the MixColumns transformation operates on the State.
Figure 6
2.3.a.4. The Round Key Addition
When the Round Key is added to the State, a Round Key is applied through bitwise XOR. The
Round Key comes from the Cipher Key which comes via the key schedule. The creation and
selection of the Round Key will be further discussed in Section 2.3.f. Figure 7 illustrates the
AddRoundKey operation on the State [8].
Figure 7
2.3.b. Key Schedule
The Round Keys for Rijndael are derived from the Cipher Key, K, through the key schedule. The
total number of Round Key bits necessary for the algorithm is equal to the block length
multiplied by the number of round plus one. For example, a block length of 128 bits and 10
rounds requires 1408 Round Key bits. The Expanded Key is created from the Cipher Key and the
Round Key is derived from the Expanded Key in the order that the first Round Key is the first
Nb words, the second Round Key is the second one of the following Nb words, and it continues.
9
Capstone – SM463A
MIDN 1/c Kevin Lee
2.3.b.1. Key Expansion
The algorithm undergoes a Key Expansion routine to generate a key schedule. The Key
Expansion creates W[Nb*(Nr + 1)] words. The algorithm has an initial set of Nb words and
each of the Nr rounds requires Nb words of key data [3].
The Key Expansion function is dependent upon the value of Nk.
For Nk < 6, the Key Expansion code is as followed:
KeyExpansion(byte Key[4*Nk] word W[Nb*(Nr+1)])
{
for(i = 0; I < Nk; i++)
W[i] = (Key[4*i],Key[4*i+1],Key[4*i+2],Key[4*i+3]);
for(i = Nk; i < Nb * (Nr + 1); i++)
{
temp = W[i - 1];
if (i % Nk == 0)
temp = SubByte(RotByte(temp)) ^ Rcon[i / Nk];
W[i] = W[i - Nk] ^ temp;
}
}
Two functions in the code above that need to be discussed are SubByte(W) and
RotByte(W). SubByte(W) takes an input word and returns a 4-byte word where each byte is
a result of applying the Rijndael S-box to the byte at the corresponding position in the input.
RotByte(W) is a cyclic permutation of the bytes from the input word to produce the output
word in the manner that the input word (a,b,c,d) produces the output word (b,c,d,a) [8].
For Nk > 6, the Key Expansion code is as followed:
KeyExpansion(byte Key[4*Nk] word W[Nb*(Nr+1)])
{
for(i = 0; i < Nk; i++)
W[i] = (key[4*i],key[4*i+1],key[4*i+2],key[4*i+3]);
for(i = Nk; i < Nb * (Nr + 1); i++)
{
temp = W[i - 1];
if (i % Nk == 0)
temp = SubByte(RotByte(temp)) ^ Rcon[i / Nk];
else if (i % Nk == 4)
temp = SubByte(temp);
W[i] = W[i - Nk] ^ temp;
}
}
10
Capstone – SM463A
MIDN 1/c Kevin Lee
The difference with the scheme for Nk ≤ 6 is that for i-4 a multiple of Nk, SubByte is applied
to W[i-1] prior to the XOR.
The round constants are independent of Nk and defined by:
Rcon[i] = (RC[i],‘00’,‘00’,‘00’) [3]
with RC[I] representing an element in GF(28) with a value of x ( i − 1) so that:
RC[1] = 1 (i.e. ‘01’)
RC[i] = x (i.e. ‘02’) •(RC[i-1]) = x(i-1) [3]
3. Creation of AES
NIST had been using encryption algorithms such as Data Encryption Standard (DES), Triple
DES, and Skipjack to encrypt sensitive government information but felt something stronger was
necessary to withstand advance hacking [4]. The goal of developing AES was to create a Federal
Information Processing Standard (FIPS) that specified an encryption algorithm capable for
protecting sensitive (unclassified) government information well into the twenty-first century [8].
Some of the initial requirements from NIST were that the algorithm had to be royalty-free,
publicly-disclosed, based on symmetric-key cryptography as a block cipher, and support block
sizes of 128-bits, at a minimum, with key sizes of 128-bits, 192-bits, and 256-bits.
3.1. AES Round 1
On January 2, 1997, NIST published the intent to develop AES. A formal call for algorithms was
made on September 12, 1997 [9]. NIST received fifteen submissions from twelve countries for
the first round of review at the First AES Candidate Conference (AES1). The fifteen algorithms
are listed in Table 3 [4].
Algorithm Name
CAST-256
CRYPTON
DEAL
DFC
E2
FROG
HPC
LOKI97
MAGENTA
MARS
AES Round 1 Submissions
Submitted By
Entrust Technologies, Inc.
Future Systems, Inc.
Richard Outerbridge and Lars Knudsen
Centre National pour la Recherche Scientifique (CNRS) – Ecole Normale
Superieure
Nippon Telegraph and Telephone Corporation
TecApro Internacional, S.A.
Rich Schroeppel
Lawrie Brown, Josef Pieprzyk, and Jennifer Seberry
Deutsche Telekom AG
International Business Machines
11
Capstone – SM463A
RC6
RIJNDAEL
SAFER+
SERPENT
TWOFISH
MIDN 1/c Kevin Lee
RSA Laboratories
Joan Daemen and Vincent Rijmen
Cylink Corporation
Ross Anderson, Eli Biham, and Lars Knudsen
Bruce Schneiger, John Kelsey, Doug Whiting, David Wagner, Chris Hall, and
Niels Ferguson
Table 3
NIST relied heavily on comments from the public, academic and research communities,
manufacturers, voluntary standards organizations, and Federal, state, and local government
organizations, while still conducting some of their own internal examinations. A public notice
was released in the Federal Register on September 14, 1998, with information regarding how to
make comments and suggested topics to consider in the comments. The topics included were
security (noted as the most important factor for round one), cost, algorithm and implementation
characteristics, intellectual property, cross-cutting analyses, and overall recommendations for the
second round. The notice stated that the intent was to assist NIST in narrowing the candidate
field to five or fewer algorithms for detailed testing [9].
3.1.a. AES Round 1 Analyses
One test conducted for round one was an analysis on performance measures across multiple
platforms. Lawrence E. Bassham III from NIST’s Computer Security Division conducted the
testing and published the results on October 13, 1999 in his paper called “Efficiency Testing of
ANSI C Implementations of Round1 Candidate Algorithms for the Advanced Encryption
Standard.”
The goal of the performance testing was to find which algorithms were consistently performing
on the test platforms. An algorithm with marginal speed differences was not considered better
than another algorithm, but if speed differed by 50% rather than 0.5% relatively, then that would
be considered a significant difference [1]. The amount of time required to create 128-bit, 192-bit,
and 256-bit keys was analyzed and cycle counts were also recorded. The cycle count included
the number of cycles to setup a key for encryption, to setup a key for decryption, to encrypt
block(s) of data, and to decrypt block(s) of data [1].
3.1.b. PC
At the conclusion of the testing, Bassham found that the most reliable and accurate value was
cycling counting measurements on the PC, which focused on the 128-bit key length. Cycle count
values for encryption and decryption were recorded for varying message block lengths. The
algorithm encryption and decryption speeds were consistent within each algorithm for messages
greater than 128-bits (one block). Further testing of messages of length 128 blocks (2046 bytes),
which is a typical size for an electronic mail message showed a clear separation of the top six
12
Capstone – SM463A
MIDN 1/c Kevin Lee
algorithms [1]. Chart 1 shows the average encryption speed using Borland and Visual C
Compiler on the Pentium Pro. The fastest six algorithms were RC6, CRYPTON, TWOFISH,
MARS, E2, and RIJNDAEL. HPC and MAGENTA were not included in Chart 1 because they
both had speeds over three times slower than the slowest included algorithm [1]. On Pentium II
and Pentium III, the same six algorithms proved to be the fastest but the new order was RC6,
CRYPTON, E2, TWOFISH, RIJNDAEL, and MARS from fastest to slowest [1].
Chart 1
3.1.c. Sun
Timing tests were conducted on the UltraSPARC CPU found in the sun systems [1]. Sun systems
utilize 64-bit processors and DFC and HPC included code for 64-bit math operations therefore,
the timing tests were conducted in both 32-bit mode, denoted as DFC and HPC, and 64-bit mode,
denoted as DFC-64 and HPC-64 [1]. Chart 2 reflects the collected results, averaging the times
from two different compilers used on Sun systems. The six fastest, from fastest to slowest, were
CRYPTON, RIJNDAEL, TWOFISH, SERPENT, MARS, and CAST-256. The E2 results do not
accurately reflect the algorithm’s true performance [1]. The code provided was not designed to
be executed on big endian systems; therefore, it compiles and then terminates abnormally [1].
13
Capstone – SM463A
MIDN 1/c Kevin Lee
Chart 2
3.1.d. SGI
SGI systems provides another 64-bit processor which runs the same version of the GCC compiler
used for the testing on Sun systems [1]. Therefore DFC and HPC were tested in both 32-bit and
64-bit modes. Chart 3 reflects the results of the tests conducted and shows that the six fastest
algorithms, from fastest to slowest, were RC6, CRYPTON, MARS, TWOFISH, RIJNDAEL, and
HPC [1]. Again, E2 compiled but did not execute normally.
14
Capstone – SM463A
MIDN 1/c Kevin Lee
Chart 3
3.1.e. Conclusion
From Bassham’s testing, it was concluded that the top performers on all platforms tested were
CRYPTON, RC6, RIJNDAEL, TWOFISH, and MARS. Table 4 includes information on the
system platforms used for the tests conducted in 3.1.b, 3.1.c, and 3.1.d [1].
System Platforms (Hardware/Software) and Compilers Used in Efficiency Testing
Processor/Hardware
Operating System
Compiler
200MHz Pentium Pro
Windows95
Borland C++ 5.01 (time &
Processor, 64MB RAM
cycles)
Visual C++ 6.0 (time &
cycles)
Sun: 300MHz UltraSPARC-II Solaris 2.7 (a 64 bit operating GCC 2.8.1
with 2MB Cache, 128 MB
system)
Sun Workshop Compiler C
RAM
4.2
Silicon Graphics: 250MHz
IRIX64 6.5.2(a 64 bit
GCC 2.8.1
R10000 with 2MB Cache, 512 operating system)
MB RAM
Table 4
15
Capstone – SM463A
MIDN 1/c Kevin Lee
3.1.f. AES Round 2 Selection
While NIST conducted their own analyses on the submitted algorithms, NIST also facilitated an
online forum for public comments from the global cryptographic community. The Second AES
Conference (AES2) was held in Rome, Italy on March 22-23, 1999 [5]. At AES2, Round 1
technical analysis was presented and discussed along with recommendations for which
candidates to select as finalists for Round 2. At the end of the public comment period, which
officially closed on April 15, 1999, NIST established an internal AES technical review team to
recommend algorithms for AES Round 2 evaluation [5]. The members that made up the review
team had at least one method of exposure to the AES process to include reviewing the
algorithms, reviewing the public comments, selecting papers for AES2, conducting NIST
efficiency and randomness testing, attending and presenting information at the AES1 conference,
or managing the AES development process [5].
During the two-month evaluation period, all comments, papers, verbal comments at the
conference, NIST studies and reports, and any related comments were taken into account. Each
candidate was thoroughly discussed relative to the announced algorithm criteria and other criteria
publically suggested. Security, efficiency, flexibility, simplicity, and other criteria were
evaluated but the team agreed that it was not possible to quantitatively select finalists [5]. The
analyses submitted were not complete for each algorithm. For example, comments were not
received regarding the security analysis of some of the algorithms. Other algorithms were
considered “broken” because there was a compile or execution error based on the software and
the user attempting to utilize the algorithm. Because security was considered to be the most
important evaluation criteria, the team made the initial cuts based off on security and then
proceeded with the other selection criteria. From the original fifteen submissions, five algorithms
were selected as finalists for AES Round 2 [5].
3.2. AES Round 2
It is important to note that the selection of an algorithm for AES Round 2 did not constitute as an
endorsement by NIST for the algorithm or its security measures. Furthermore, the fact that an
algorithm was not selected for AES Round 2 did not imply anything about the quality, security,
efficiency, or any other characteristic of the algorithm.
On August 9, 1999, NIST announced that the five finalists for AES Round 2 were MARS, RC6,
RIJNDAEL, SERPENT, and TWOFISH.
At this time, public comments were opened up for Round 2 analysis and would remain open until
May 15, 2000.
The Third AES Conference (AES3) was scheduled for April 13-14, 2000 in New York, New
York. Much like AES2, AES3 would provide a forum for technical analysis of the finalists and
recommendations as to which of the finalists should be selected as the AES winner.
16
Capstone – SM463A
MIDN 1/c Kevin Lee
3.2.a. Summaries of Finalist
During the AES Round 1 analysis, no significant security vulnerabilities were found and each
algorithm showed potential superior technology. NIST published these summaries about the five
finalists.
MARS incorporates its "cryptographic core" into an innovative, heterogeneous overall structure.
It also features a wide variety of operations, including the technique of rotating digits by a
varying number of places that is determined by both the data and the secret key. Consequently,
while MARS performs well in general, it performs particularly well on computer platforms that
support its rotation and multiplication operations efficiently. NIST accepted a modification to
MARS for Round 2 (proposed by the submitter) that should improve its ability and flexibility to
function in some memory-constrained environments, such as low-end smart cards. MARS was
submitted to the AES development effort by the International Business Machines Corporation
[5].
RC6 is an algorithm that is simple enough to memorize, and should be easy to implement
compactly in both software and hardware. Its simplicity also should facilitate its further security
analysis in Round 2, which is assisted by the analysis of its predecessor, RC5. RC6 does not use
substitution tables; instead, the principal engine for its security is the technique of rotating digits
by a varying number of places that is determined by the data. In general, RC6 is fast, and it is
particularly fast on platforms that support its rotation and multiplication operations efficiently; its
key setup is also fast. RC6 was submitted to the AES development effort by RSA Laboratories
[5].
RIJNDAEL performs excellently across all considered platforms. Its key setup is fast, and its
memory requirements are low, so it also should perform well in hardware and in memoryconstrained environments. The straightforward design and the conservative choice of operations
should facilitate its further analysis, and the operations should be relatively easy to defend
against certain attacks on physical implementations. Even though parallel processing was not
considered during the Round 1 selection process by the AES review team, Rijndael has the
potential of benefiting from advances in computer processors that allow many instructions to be
executed in parallel. Rijndael was submitted to the AES development effort by Joan Daemen and
Vincent Rijmen [5].
SERPENT is ultra-conservative in its security margin: the designers chose to use twice as many
iterations as they believed secure against currently known attacks. Consequently, Serpent’s
performance is relatively slow compared to the other four finalists; however, in some settings
this should be mitigated by the efficiency of optimized implementations using what the
submitters call the "bitslice" mode, for which the algorithm was specially designed. Serpent
should fit well in hardware (with potential tradeoffs of speed versus space) and in memoryconstrained environments. The straightforward design and the conservative choice of operations
should facilitate further analysis of this candidate, and the operations should be easy to defend
against certain attacks on physical implementations. Serpent was submitted to the AES
development effort by Ross Anderson, Eli Biham, and Lars Knudsen [5].
17
Capstone – SM463A
MIDN 1/c Kevin Lee
TWOFISH exhibits fast and versatile performance across most platforms; it also should perform
well both in hardware and in memory-constrained environments. It features variable substitution
"tables" that depend on the secret key. The submitters believe that such tables generally offer
greater security than tables with fixed values. The possibility of pre-computing these tables to
varying degrees helps Twofish to offer a wide variety of performance tradeoffs: depending on
the setting, Twofish can be optimized for speed, key setup, memory, code size in software, or
space in hardware. Twofish was submitted to the AES development effort by Bruce Schneier,
John Kelsey, Doug Whiting, David Wagner, Chris Hall, and Niels Ferguson [5].
3.2.b. Round 2 Analyses
Just like Round 1 of the AES selection process, NIST accepted public comments and papers
from the global cryptographic community while concurrently conducting their own testing and
analysis of the finalists. Thirty-seven papers were submitted in response to NIST AES3 Call for
Papers [6]. Of the thirty-seven, twenty-four were accepted for the main program of AES3. For
the purpose of this paper, two papers will be discussed for the Round 2 Analysis [6]. The first
paper discussed will be “Efficiency Testing of ANSI C Implementations of Round 2 Candidate
Algorithms for the Advanced Encryption Standard” by Lawrence E. Bassham III from NIST [2].
The second paper discussed will be “Randomness Testing of the Advanced Encryption Standard
Finalist Candidated” by Juan Soto and Lawrence E. Bassham III from NIST [8].
3.2.b.1. Efficiency Testing
Bassham conducted efficiency tests on the Round 2 AES Finalists much like he did for the
fifteen original submissions during Round 1. Performance measurements were taken over a
variety of platforms. Again, like his testing during Round 1, NIST was interested in finding the
consistent “top performers” across the multiple test platforms, thus one algorithm was not
considered better than another algorithm because it was relatively faster by 0.5%. However, if
one algorithm was faster than another by 50%, then that was considered a significant difference.
3.2.b.1.a. Cycle Count Testing
The performance test conducted by Bassham that was most interesting was the Cycle Count Test.
This method counted the number of clock cycles required to perform cryptographic operations
(e.g., how many cycles are consumed in encrypting a block of data or how many cycles are
consumed in setting up a key). The Cycle Count Tests counted the actual clock cycles consumed
in performing the operation under test [2]. The Cycle Count Test was extremely accurate and
reliable because the cycle counting utilized assembly language code in the testing program so
interrupts could be turned off during testing resulting in accurate measures of the underlying
18
Capstone – SM463A
MIDN 1/c Kevin Lee
cryptographic operations [2]. Also, cycle counting eliminated the variability of the processor
speed as the same number of clock cycles were required to perform an operation on a 300 MHz
Pentium II processor as on a 450 MHz Pentium II processor. However, cycle counting could
only be conducted on the Intel processor based systems so the platform scope for this testing was
greatly reduced [2].
For each key size (128, 192, and 256-bits), four values were calculated:
 The number of cycles needed to setup a key for encryption
 The number of cycles needed to encrypt block(s) of data
 The number of cycles needed to setup a key for decryption
 The number of cycles needed to decrypt block(s) of data [2]
The test program created 1000 sets of cycle counts for each key size. From there, all the values in
each category were sorted and the median was determined. A standard deviation was also
calculated for each category. All values that fell within three standard deviations of the median
were declared and the average cycle count was reported from those values for each specific
operation for each key size [2].
All the values reported are in clock cycles. Ekey is the number of cycles needed to setup a 128bit key for encryption. Dkey is the number of cycles needed to setup a 128-bit key for
decryption. Enc is the number of cycles per block needed to encrypt n blocks of data. Dec is the
number of cycles per block needed to decrypt n block of data [2].
Table 5 reports the Cycle Count results using Borland C++ 5.01 – 200 MHz Pentium Pro, 64MB
RAM, Windows 95 [2].
Table 5
Table 6 reports the Cycle Count results using Visual C 6.0 – 200MHz Pentium Pro, 64MB RAM,
Windows 95 [2].
19
Capstone – SM463A
MIDN 1/c Kevin Lee
Table 6
Table 7 reports the Cycle Count results using Borland C++ 5.01 – 450 MHz Pentium II, 128MB
RAM, Windows 98 [2].
Table 7
Table 8 reports the Cycle Count results using Visual C 6.0 – 450 MHz Pentium II, 129MB Ram,
Windows 98 [2].
20
Capstone – SM463A
MIDN 1/c Kevin Lee
Table 8
Table 9 reports the Cycle Count results using Borland C++ 5.01 – 600 MHz Pentium III, 128MB
Ram, Windows 98 [2].
Table 9
Table 10 reports the Cycle Count results using Visual C 6.0 – 600 MHz Pentium III, 128MB
RAM, Windows 98 [2].
21
Capstone – SM463A
MIDN 1/c Kevin Lee
Table 10
Across all the platforms tested, RIJNDAEL was the fastest algorithm for Ekey and Dkey. RC6
and MARS were closely trailing RIJNDAEL, respectively. SERPENT and TWOFISH were
considerably slower compared to the other three algorithms. SERPENT consistently was the
slowest algorithm for encryption and decryption for all block lengths tested. RC6 was
consistently on top or near the top for encryption and decryption for all block lengths tested,
followed by MARS, TWOFISH, and RIJNDAEL, respectively [2].
4. Conclusion
The team that declared the finalists for AES Round 2 were reconvened and tasked with declaring
the winning algorithm(s) from the finalists. Up front, the team was tasked with figuring out if
they would take a quantitative or qualitative approach to selection, if they would select one or
multiple algorithms, if they would select a backup algorithm(s), and if they would consider
public proposals to modify the algorithms [6].
The team wanted to use a quantitative approach so that they could assign a score to each
algorithm and declare the winner transparently, however, the scoring methodology was heavily
debated and a consensus was not reached [6]. During AES3, there were many debates and
opinions on what should be scored more heavily and what should be scored less heavily. The
team also feared that if there was not enough public discussion and consensus, the system and
process could appear unfair. With that, the team decided to take the qualitative approach, taking
into account security, performance, implementation, and other characteristics, keeping security at
the forefront of the assessments of each algorithm [6].
Many public arguments were also made in regards to how many algorithms should be selected.
Some felt that multiple algorithms were necessary to avoid placing critical data at severe risk or
if intellectual property issues came about in the future, an alternative algorithm could be
22
Capstone – SM463A
MIDN 1/c Kevin Lee
implemented immediately [6]. One of the most compelling arguments for multiple winners was
that multiple algorithms could cover a wider range of desirable traits, possibly offering both high
security and high efficiency, that could not be achievable with one algorithm. However, others
argued that multiple algorithms would increase interoperability complexity and raise
implementation issues. Some argued that selecting multiple algorithms would show a weakness
in NIST and portray the organization as unable to select a secure algorithm with confidence [6].
AES3 provided a forum for all those to voice their opinions on whether to select one or multiple
algorithms. Most of those in attendance voted for a single algorithm and some also voted to
implement a backup algorithm [6]. However, a consensus was not reached in terms of selecting
the backup algorithm. The team considered all of the comments and factors and eventually
decided to select a single algorithm.
A backup algorithm gained support however, the selection standard could not be agreed upon. As
NIST does for all cryptographic algorithm standards, NIST will continue to follow developments
in the cryptanalysis of the AES algorithm. The standard will be formally reevaluated every five
years and will act accordingly from there [6].
Many comments were also made expressing an interest to increase the number of rounds in some
of the algorithms. Notably, RC6 and RIJNDAEL received the most comments about adding
more rounds to the algorithm, however, the authors decided not to add rounds when proposals
were submitted at the end of AES Round 1. Furthermore, the authors of RIJNDAEL submitted a
statement saying that the algorithm provided a sufficient margin of security with respect to
cryptanalytic attacks [6]. Issues that came from increasing the number of rounds were the
unknown effects on the key schedules and how it would impact the security analysis, the
performance data changes from AES Round 1 and 2, and the lack of agreement from the public
on how many rounds to add and to which algorithms to add them to. Additionally, “tweak”
proposals were submitted during Round 1 and there were no changes to any of the algorithms,
showing the confidence from the authors in their algorithms [6].
Table 11 provides a summary of different aspects taken into consideration of the algorithms and
which algorithm(s) NIST felt was superior among the finalists [6].
Summary Assessment
General Security
Software Implementation
Restricted-Space Environment
Hardware Implementation
Attacks on Implementation
Encryption vs. Decryption
Key Agility
Potential for Instruction-level Parallelism
Superior Algorithm
MARS/SERPENT/TWOFISH
RC6/RIJNDAEL
RIJNDAEL
RIJNDAEL/SERPENT
RIJNDAEL/SERPENT
TWOFISH/MARS/RC6
TWOFISH
RIJNDAEL
Table 11
After a very complex and thorough analysis of each the finalists, NIST concluded that any of the
finalists could have served admirably as the Advanced Encryption Standard. Furthermore, each
23
Capstone – SM463A
MIDN 1/c Kevin Lee
algorithm has one or more areas where it did not perform quite as well as other algorithms,
saying that no algorithm was considerably superior from the rest. After considering all
comments, papers, tests, and verbal comments at conferences, NIST judged RIJNDAEL to be the
best overall algorithm for AES. NIST commented saying that RIJNDAEL was consistently a
good performer in both hardware and software across a wide range of computing environments.
The algorithm has a very low memory requirement, which made it desirable in restricted-space
environments while maintaining a superior performance level. The operations of the algorithm
were among the easiest to defend against power and timing attacks and it appeared some defense
could be provided against such attacks without significantly influencing the performance. In
addition, the flexibility in the blocks and key sizes also added variability to the number of rounds
[6].
For the sake of feasibility, not every public comment, paper, conference note, or verbal comment
could be analyzed to fully understand how the team from NIST decisively declared RIJNDAEL
as the AES. However, most of the tests conducted and reports submitted were consistent across
the board and the logic behind the team from NIST can be understood with a little more clarity
and confidence.
24
Capstone – SM463A
MIDN 1/c Kevin Lee
Works Cited
[1] Bassham, Lawrence E., III. Efficiency Testing of ANSI C Implementations of Round 1
Candidate Algorithms for the Advanced Encryption Standard. Tech. N.p.: Computer
Security Division, Information Technology Laboratory, National Institute of Standards
and Technology, 1999. Print.
[2] Bassham, Lawrence E., III. Efficiency Testing of ANSI C Implementations of Round 2
Candidate Algorithms for the Advanced Encryption Standard. Tech. N.p.: Computer
Security Division, Information Technology Laboratory, National Institute of Standards
and Technology, 2000. Print.
[3] Daemen, Joan, and Vincent Rijmen. AES Proposal: Rijndael. Tech. N.p.: National Institute of
Standards and Technology, 1998. Print.
[4] Jamil, Tariq. "The Rijndael Algorithm." IEEE Potentials Apr. 2004: n. pag. Web.
[5] Nechvatal, James, Elaine Barker, Donna Dodson, Morris Dworkin, James Foti, and Edward
Roback. STATUS REPORT ON THE FIRST ROUND OF THE DEVELOPMENT OF
THE ADVANCED ENCRYPTION STANDARD. Rep. N.p.: National Institute of
Standards and Technology, 1999. Print.
[6] Nechvatal, James, Elaine Barker, Lawrence Bassham, III, William Burr, Morris Dworkin,
Jame Foti, and Edward Roback. Report on the Development of the Advanced Encryption
Standard (AES). Rep. N.p.: National Institute of Standards and Technology, 2000. Print.
[7] "RIJNDAEL - Advanced Encryption Standard." McGill School of Computer Science, 15
Nov. 2000. Web. 22 Mar. 2015.
[8] United States of America. Department of Commerce. National Institute of Standards and
Technology. Federal Information Processing Standards. Announcing the ADVANCED
ENCRYPTION STANDARD (AES). N.p.: n.p., n.d. Print.
[9] United States of America. Department of Commerce. National Institute of Standards and
Technology. REQUEST FOR COMMENTS ON CANDIDATE ALGORITHMS FOR
THE ADVANCED ENCRYPTION STANDARD (AES). By Robert E. Hebner. N.p.:
n.p., n.d. Print.
25