The Long Road to the Advanced Encryption Standard
Total Page:16
File Type:pdf, Size:1020Kb
The Long Road to the Advanced Encryption Standard Jean-Luc Cooke CertainKey Inc. [email protected], http://www.certainkey.com/˜jlcooke Abstract 1 Introduction This paper will start with a brief background of the Advanced Encryption Standard (AES) process, lessons learned from the Data Encryp- tion Standard (DES), other U.S. government Two decades ago the state-of-the-art in cryptographic publications and the fifteen first the private sector cryptography was—we round candidate algorithms. The focus of the know now—far behind the public sector. presentation will lie in presenting the general Don Coppersmith’s knowledge of the Data design of the five final candidate algorithms, Encryption Standard’s (DES) resilience to and the specifics of the AES and how it dif- the then unknown Differential Cryptanaly- fers from the Rijndael design. A presentation sis (DC), the design principles used in the on the AES modes of operation and Secure Secure Hash Algorithm (SHA) in Digital Hash Algorithm (SHA) family of algorithms Signature Standard (DSS) being case and will follow and will include discussion about point[NISTDSS][NISTDES][DC][NISTSHA1]. how it is directly implicated by AES develop- ments. The selection and design of the DES was shrouded in controversy and suspicion. This very controversy has lead to a fantastic acceler- Intended Audience ation in private sector cryptographic advance- ment. So intrigued by the NSA’s modifica- tions to the Lucifer algorithm, researchers— This paper was written as a supplement to a academic and industry alike—powerful tools presentation at the Ottawa International Linux in assessing block cipher strength were devel- Symposium. The reader should have at least oped. Some of these tools proved useful in un- first year university level knowledge of alge- derstanding more about the changes made by bra and physics. Someone with no knowledge the NSA. of mathematics can still benefit from this paper and its associated presentation. This topic of Taking an objective look at the standardization cryptography is covered lightly. Care is taken practices of the USA NSA and NIST organi- to present enough useful technical information zations, one can make broad assumptions on to be interesting to a technical audience and where the American state is focusing its crypt- beneficial to others. analytic resources. Ottawa Linux Symposium 2002 74 1.1 What the NSA/NIST has Taught Us from IBM or the NSA. Reducing the effec- tive key strength of the algorithm and the omi- By the mid-1970’s the private sector began nous change to possibly the single most crucial having an interest in digital cryptography. sub-component of the algorithm had everyone Even if the clearly false IBM statement “global second-guessing the DES. market for computers estimated at 10” had In the subsequent years after the 1976 DES been proven correct, most of the computers announcement, Shamir and Biham published in operation at the time were terminal servers. their paper on Differential Cryptanalysis (DC) The terminals connected to these servers were (1994, ISBN-0387979301). In this paper, the carrying progressively more sensitive data. Fi- two cryptographers of RSA fame (‘S’ to be pre- nancial records, payroll information, trade se- cise), outlined how to correlate input changes crets, and intellectual property; all crucial to to the output of several variants of the DES. At the success of a business were exposed to the then end of the day, the Lucifer algorithm fell hot new hobby of wire tapping with gator clips. to the attack of DC while DES remained unbro- Before the US government moved to create ken. To the shock of sceptics, the NSA appears a single encryption standard the private sec- to have not weakened the DES for their evil tor was taking its first steps into design cryp- purposes but in fact made it impervious to an tographic algorithms. In what would become attack not to be publicized for another eighteen crypto folklore, the NSA quietly send out let- years. ters of solicitation to a few hand picked cryp- After the announcement of DC, the Lucifer tographic experts and laboratories. It is im- co-designer Don Coppersmith confessed to portant to realize that previous to this the only knowledge of DC at the time of DES standard- communication a mathematician would have ization. This kept the sky from falling on the with the NSA was in the form of a “cease and heads of the crypto sceptics as you can well desist or be thrown in jail for conspiracy” let- imagine. ters. Of the few responses received by the NSA, only one had actually met the minimum stan- dards set out by the NSA in their solicita- 2 Obsolescence of the DES tion. The Lucifer block cipher designed by Don Coppersmith, Horst Fiestel and company at IBM was the winner practically by default. A 56bit key space did not provide sufficient There were two distinct differences between protection in lieu of the personal computer ex- the Lucifer algorithm submitted by IBM and plosion of the late 1980’s and 1990’s. The the final DES design. threat of attack was no longer from a sin- gle powerful computer, but from thousands of • The effective key space was reduced by commodity computers coordinating their ef- several orders of magnitude. forts. In comes the Triple-DES. Encrypting the data with three distinct keys resulted in a three- • The core substitution boxes were re- fold increase in key material, a three-fold in- designed. crease in computational effort required for en- cryption, and a 5.2 × 1033 increase in the key These changes were made without comment space. Ottawa Linux Symposium 2002 75 Figure 1: The DES Cipher Figure 2: The 3DES Cipher E = 3DESk1,k2,k3(D) −1 (1) E = DESk1(DESk2 (DESk3(D))) By the mid 1990’s, TripleDES was no longer sufficient. The security of the algorithm was assumed to be good, but there were other short- comings with TripleDES. TripleDES was too slow. The private sector’s obsession with higher digital communication bandwidths had made the integration of en- cryption at the data link layer far too costly. Economic conditions then predicted that all data would be encrypted at least once by 2006. Current economic conditions make this predic- tion conservative. Private sector dependence on secure data com- Figure 3: The OSI Network Stack munication was going to continue to grow be- yond the capabilities of DES/TripleDES. A new standard with greater security and a long Ottawa Linux Symposium 2002 76 lifetime needed to be decided to mitigate the • CAST-256 - Entrust Technologies Ltd. impact of migrating to a new standard. “We need to act fast before we’re in serious trou- http://www.entrust.com/ ble.” AESCD1 Another issue with DES and subsequently TripleDES, was a design limitation. DES AESCD2 was not designed to be efficient in software. The ubiquity of software in modern computer and communication technology dictated an ef- ficient hardware as well as software implemen- –The Communications Security tation for this new standard. Establishment (CSE)—Canadian equivalent to the US NSA—has 3 AES Round One adopted the CAST5 algorithm as their confidential government data encryption algorithm. Contrasting the algorithm solicitation process CSE website: used in selecting the DES, a very public an- http://www.cse.dnd.ca/ nouncement was made by the NSA/NIST for cipher designs. Appearing at private sector security and cryptography tradeshows, it was –CAST5 is synonymous with CAST- made very clear this time the standard was go- 128 ing to be a very public affair. The NSA/NIST set out minimum requirements –CAST-256 is an extension to for block cipher submission[NISTAESWWW] CAST5 for inclusion to the AES AESCD1 • Crypton - Future Systems AESCD2 AESCD3 http://www.future.co.kr/ . AESCD1 AESCD2 • Size efficiency of hardware/software im- plementation • Speed efficiency of hardware/software implementation –At the time of AES, this algorithm • Minimum 128bit block sizes submission would be allowed to ENTER the US, but not leave. Is • Key sizes up to 256 bits something wrong here? • Resilience to all known modern attacks. • DEAL - Outerbridge, Knudsen Fifteen algorithms met these requirements. Ottawa Linux Symposium 2002 77 http://www.ii.uib.no/˜larsr/newblock.html • FROG - TecApro AESCD1 http://www.tecapro.com/aesfrog.htm AESCD2 AESCD1 AESCD2 –This is one of two submission co- authored by Knudsen. See also Ser- pent! –At the time of AES, this algorithm –Georgoudis is an amateur cryptogra- submission would be allowed to EN- pher, the only one in Puerto-Rico in TER the US, but not leave. Is some- all likelihood! FROG was the first thing wrong here? cipher he ever designed, and it was accepted to the AES process! • DFC - Centre National pour la Recherche –At the time of AES, this algorithm Scientifique - Ecole Normale Superieure submission would be allowed to EN- TER the US, but not leave. Is some- http://www.dmi.ens.fr/˜vaudenay/dfc.html thing wrong here? Or is Puerto- Rico’s special status with the US ex- AESCD1 empt them for this? Isn’t it nice we AESCD2 live in the “free world” and don’t have to worry about such ugliness? • HPC - Schroeppel –Vive la resistance! –At the time of AES, this algorithm http://www.cs.arizona.edu/˜rcs/hpc/ submission would be allowed to EN- TER the US, but not leave. Is some- AESCD1 thing wrong here? AESCD2 • E2 - Nippon Telegraph and Telephone http://info.isl.ntt.co.jp/e2/ –An academic’s block cipher. AESCD1 Schroeppel’s paper goes into great detail on the theoretical advantages AESCD2 of his Hasty Pudding Cipher. Not a very practical cipher, underlines the ‘openness’ of the AES submission –At the time of AES, this algorithm process.