advertisement

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