Encryption Algorithm Trade Study CCSDS Security WG Fall

Encryption Algorithm Trade Study CCSDS Security WG Fall 2005 Atlanta, GA USA Howard Weiss NASA/JPL/SPARTA hsw@sparta. com +1 -410 -872 -1515 September 2005 1

Agenda • 14 September 2005 – 0900 -0915: Welcome, opening remarks, logistics, agenda bashing, 0915 -0930: Review results of Spring 2005 Sec. WG meeting in Athens Mtg Notes – 0930 -1000: RASDS Review wrt Security Architecture (Kenny) – 1000 -1030: coffee break – 1030 -1200: Security Architecture Document Discussions (Kenny) – 1200 -1330: Lunch – 1330 -1400: Review CNES Mission Security Req Development using EDIOS (Pechmalbec/Belbus) – 1400 -1500: Encryption Algorithm Trade Study (Weiss) – 1500 -1530: coffee break – 1530 -1700: Authentication/Integrity Algorithm Trade Study (Weiss) • 15 September 2005 – 0900 -1000: Key management discussion (Kenny) – 1000 -1030: Coffee break – 1030 -1100: Identity Management, Spacecraft IDs (Weiss) – 1100 -1130: CNES Interconnection Rules (Pechmalbec/Belbus) – 1130 -1300: Lunch – 1300 -1400: CNES Security Development Process (Pechmalbec/Belbus) – 1400 -1500: Security Policy Document/Common Criteria (Weiss) 2

Discussion Topics • Standard Encryption Algorithm adoption by CCSDS – Previous proposal submitted (Montreal, Toulouse, Athens) to adopt AES-128. – Athens resulted in creating an action item to perform an encryption algorithm trade study. 3

Background Discussions • As previously discussed, CCSDS does not have standards for: – Encryption – Authentication – Integrity – (or much of anything security-wise) • Previous discussions in the (old) P 1 A (link layer) panel to create such “link-layer” standards (Spring 2002 mtg in Darmstadt) – Good discussion which didn’t lead to anything (P 1 A Security Briefing) • Created a “draft” P 1 A Security White Book to address some “strawman” proposals 4

Previous Encryption Algorithm Proposal: • Several Security Green Book solutions to pick from depending on existing link layer chip sets versus entirely new design. – Several algorithms should be supported for civilian missions such as AES and 3 DES – Propose FIPS 197 – AES with 128 -bit key as minimum CCSDS encryption algorithm standard. • Consensus? ? ? Agreement? ? ? NO AGREEMENT – perform Trade Study 5

Trade Study Basis • Various classes of encryption algorithms examined: – DES/3 DES – RSA (asymmetric) – AES Algorithm Finalists » Rijndael » Two. Fish » Serpent » RC 6 » MARS – GSM/UMTS Algorithms » KASUMI – Miscellaneous Algorithms » Blowfish » TEA » IDEA » SEED 6

Algorithms At A Glance Algorithm Name Algorithm Origin Characteristics (block size/(a)symmetric) Key Sizes (bits) Speed (MB/sec)[1] DES US (IBM) 64 bits/symmetric 56 21. 34 Triple DES (3 DES) US 64 bits/symmetric 112 (2 keys) or 168 (3 keys) 9. 84 Rijndael Belgium 128 bits/symmetric 128/192/256 61. 01 Serpent UK, Israel, Norway 128 bits/symmetric 128/192. 256 21. 09 Twofish US (Counterpane) 128 bits/symmetric 128/192/256 31. 41 Blowfish US (Counterpane) 64 bits/symmetric 256 -448 64. 38 RC 6 US (RSA) 128 bits (variable)/symmetric 128/192/256 37. 81 TEA UK (Cambridge) 64 bits/symmetric 128 23. 8 IDEA Switzerland 64 bits/symmetric 128 18. 96 MARS US (IBM) 128 bits/symmetric 128 -1248 27. 91 Kasumi (A 5/3) Europe (ETSI) 64 bits/symmetric 128 53[2] SEED South Korea (Korea Information Security Agency) 128 bit/symmetric 128 16[3] 4[4] RSA US (RSA) N/A/asymmetric 1024 -2048 Encrypt: 1024 bit key w/27607 iterations=0. 18 ms/operation Decrypt: 1024 bit key w/1050 iterations=4. 77 ms/operation Speeds obtained from Crypto++ 5. 2. 1 Benchmarks running on Pentium 4 2. 1 GHz, Windows XP, www. eskimo. com/~weidai/benchmarks. html Speed obtained from Motorola MPC 185 Security Co-processor User’s Manual (MPC 185 UM, dated 12/2003 rev 2. 3), page 1 -12, Table 1 -2 [3] Speed obtained from SEED Algorithm Self Examination, Korea Information Security Agency, running on Pentium III 800 MHz MS Visual C++ [4] Speed obtained from SEED Algorithm Self Examination, Korea Information Security Agency, running on Pentium III 866 MHz Java 1. 2. 2 [1] [2] 7

Discussion – DES/3 DES X • DES is dead – included simply for completeness but should not be considered for adoption by CCSDS • Triple DES (3 DES) – also known as Triple Data Encryption Algorithm (TDEA): – Still considered “safe” by most cryptographers – for now – Two and three key variations – but still using 64 -bit keys » Two key using key 1 to encrypt, key 2 to decrypt ciphertext, key 1 to again encrypt the random test resulting from the decrypt. » Three key using key 1 to encrypt, key 2 to decrypt, and key 3 to again encrypt. • Conclusion: modern, stronger, safer, and more efficient algorithms are available. 8

Discussion - RSA X • RSA is an asymmetric (i. e. , Public Key) algorithm • Asymmetric algorithms suffer from the need for: – Large amounts of CPU power » Highly inefficient – Large key sizes (other than elliptic curve) – Need for Public Key Infrastructure (or some other means to create, sign, and distribute public keys). • Conclusion: too much overhead and too much onboard resources required to effectively use RSA or other asymmetric algorithms as the sole means of encryption. – BUT – should we also adopt this as an asymmetric costandard for those missions that think they want/need an asymmetric algorithm? 9

Discussion – AES Finalists • Advanced Encryption Standard (AES): – US National Institute for Standards and Technology (NIST) world-wide open competition for a DES replacement algorithm » Had to be strong yet efficient in both hardware and software implementations • Five finalists chosen from a much larger set of submissions: – Rijndael – Twofish – Serpent – RC 6 – MARS 10

Discussion – AES (cont) • NIST finalist evaluation study found no cryptographic weaknesses among any of the entries. • Rijndael was selected because: – Superior performance in both hardware and software over other candidates – Efficient general CPU usage – Efficient specialized processor usage – Efficient memory requirements • Rijndael has been extremely well scrutinized by the cryptographic community and has held up well • Conclusion: Based on the extensive amount of analysis already performed, Rijndael is recommended for adoption by CCSDS. 11

Discussion – GSM/UMTS X • GSM/UMTS already specifies the use of AES (Rijndael) for authentication and key generation. • However, for confidentiality and integrity (functions f 8 and f 9) use KASUMI – Based on MISTY 1 – Publicly disclosed algorithm (replaces a broken secret algorithm) • KASUMI – Block cipher algorithm operating over a 64 -bit block (rather than the 128 -bit block that AES uses) – 64 -bit key (from GSM/GPRS) – will go to a 128 -bit key in 3 GPP WCDMA systems. • Conclusion: while a strong algorithm, does not appear to be better, stronger, or more efficient than Rijndael (appears that 3 GPP chose KASUMI over Rijndael in the first place because it appeared to be more efficient in specialized hardware but that may no longer hold true). 12

Performance Chart Performance in megabits/sec on Motorola MPC 185 Security Co-Processor 13

Discussion – Miscellaneous Algorithms • Several other algorithms examined: – Blowfish » Essentially superceded by Twofish for AES competition – why go with the old? – TEA (Tiny Encryption Algorithm) » Tiny is the correct – 9 lines of C for encrypt and 9 lines for decrypt • 64 -bit block, 128 -bit key » Small, but not terribly efficient (many rounds req) – IDEA (International Data Encryption Algorithm) » Developed as a DES replacement in the early ’ 90 s » Patented algorithm with no outstanding features over other free algorithms – SEED » Developed by Korea Information Security Agency (KISA) » Korean national standard » Performance only adequate X 14

Conclusions and Recommendations • Rijndael was chosen from an international competition of cryptographically strong and efficient algorithms – Panels of international cryptographic experts participated in the algorithm selection for the AES competition. • Other good algorithms available – However, other than diversity there does not appear a good, strong reason for selecting any of them as a standard. • Recommendation: AES with a minimum key size of 128 -bits (256 -bits preferred) as specified in FIPS PUB 197. – But should we also adopt an asymmetric co-standard (e. g. RSA)? 15