Encryption Algorithm Trade Study CCSDS Security WG Fall 2005 Atlanta, GA USA

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

2. Agenda • 14 September 2005 • 0900-0915: Welcome, opening remarks, logistics, agenda bashing, 0915-0930: Review results of Spring 2005 SecWG 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)

3. 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.

4. 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) P1A (link layer) panel to create such “link-layer” standards (Spring 2002 mtg in Darmstadt) • Good discussion which didn’t lead to anything (P1A Security Briefing) • Created a “draft” P1A Security White Book to address some “strawman” proposals

5. 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 3DES • Propose FIPS 197 – AES with 128-bit key as minimum CCSDS encryption algorithm standard. • Consensus??? Agreement??? NO AGREEMENT – perform Trade Study

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

7. Algorithms At A Glance [1] Speeds obtained from Crypto++ 5.2.1 Benchmarks running on Pentium 4 2.1 GHz, Windows XP, www.eskimo.com/~weidai/benchmarks.html [2] Speed obtained from Motorola MPC185 Security Co-processor User’s Manual (MPC185UM, 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

8. Discussion – DES/3DES • DES is dead – included simply for completeness but should not be considered for adoption by CCSDS • Triple DES (3DES) – 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. X

9. Discussion - RSA • 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 on-board 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 co-standard for those missions that think they want/need an asymmetric algorithm? X

10. 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 • RC6 • MARS

11. 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.

12. Discussion – GSM/UMTS • GSM/UMTS already specifies the use of AES (Rijndael) for authentication and key generation. • However, for confidentiality and integrity (functions f8 and f9) use KASUMI • Based on MISTY1 • 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 3GPP WCDMA systems. • Conclusion: while a strong algorithm, does not appear to be better, stronger, or more efficient than Rijndael (appears that 3GPP 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). X

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

14. 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 ’90s • 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

15. 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)?