Designs and Challenges in Authenticated Encryption Carlos Cid – Royal Holloway, University of London International Workshop on Cybersecurity – Kyushu University Jan 2016 privacy & authenticity • traditional goals of modern cryptography: data confidentiality, data integrity, authentication and non-repudiation. • there are well-know cryptographic primitives to tackle each of these goals. • confidentiality remains (to the general public at least) the archetypal crypto functionality. • “encryption” is often used to refer to “cryptography” • however in practice, data integrity/authenticity is often also desirable (or required). • it is a common fallacy (to the general public) that “encryption” alone can provide privacy and authenticity. • “if decrypts correctly, then it is authentic!” privacy ≠ authenticity • traditional encryption scheme K K E D privacy ≠ authenticity • traditional encryption scheme does not provide data authenticity! K K E D ≠ maybe a plausible message… privacy ≠ authenticity • how can be plausible? • encryption may be using a stream cipher (adversary could flip bits) • encryption may be using a block cipher in ECB mode (adversary could re- order, or remove blocks) • message may not have a high level of redundancy (plausible message space ≈ message space) • it would be better to: • make no assumptions about the encryption scheme and message structure… • … and recognize that standard encryption mechanisms do not provide data authenticity. ok, so how to achieve privacy and authenticity? for example, use a strong encryption algorithm and a strong MAC algorithm. • generic composition: the most common used solution. 1. Encrypt-and-MAC (used in SSH) Insecure 2. MAC-then-Encrypt (used in SSL/TLS) Insecure 3. Encrypt-then-MAC (used in IPsec) Secure security? only (3) can be proven secure – the other constructions may be attacked due to bad interaction between MAC and encryption. other issues: generic composition requires two algorithms, two independent keys, two full passes over the message, prone to implementation errors, ... can we do better? authentication encryption (AE) schemes • dedicated constructions providing data confidentiality and authenticity. • combined scheme: one algorithm and one key. • via modes of operation, or dedicated primitives. • more efficient/compact constructions. • research on dedicated AE started around 2000. • several schemes already standardized, e.g. CCM (IEEE 802.11, ISO, NIST*), GCM (ISO, NIST*). • some early (and prominent) constructions fall under patent (e.g. OCB) * recommended authenticated encryption (AE) schemes • AE definition and security notions are now well established. K K longer ciphertext includes authentication tag Enc Enc Traditional Encryption AE Encryption Traditional Decryption AE Decryption only “valid ciphertexts” decrypt K K correctly (at all) Dec or Dec or ⊥ AE security • AE security notion: IND-CPA + INT-CTXT • a secure AE scheme provides data privacy (indistinguishability from ideal cipher against chosen- plaintext attacks, IND-CPA) and ciphertext integrity against forgery attacks (INT-CTXT) AE notions • extended notions of AE operation and security: • AEAD – Authenticated Encryption with Associated Data • algorithm also takes as input nonce N, to provide freshness (N is not supposed to be repeated in a Enc query) • algorithm also takes as input Associated Data, which is authenticated but not encrypted (e.g. a header) • MRAE – Nonce Misuse-Resistant AE • if N is indeed nonce, we have standard AE security. • if N is re-used, repetitions are leaked (e.g. same (M,AD) or common prefix) • RUP confidentiality • attacker does not get ciphertext decryptions before verification is completed. AE features • security level (only up to • online birthday bound?) • incremental MAC • proofs of security • static AD • mode or primitive • implementation: • Nonce Misuse resistance parallelizable? inverse-free? • side-channel security • target platform (software. • number of passes on data hardware, bulk encryption, lightweight?) • RUP security. • patent issues. a few AE designs (pre-CAESAR) Grain 128a figures from Basic comparison of Modes for Authenticated-Encryption (P. Svenda) https://www.fi.muni.cz/~xsvenda/docs/AE_comparison_ipics04.pdf and A New Version of Grain-128 with Authentication (M. Agren et. al.) http://skew2011.mat.dtu.dk/proceedings/A%20New%20Version%20of%20Grain-128%20with%20Authentication.pdf CAESAR competition • CAESAR – Competition for Authenticated Encryption: Security, Applicability, and Robustness • NIST-supported competition to identify a portfolio of authenticated ciphers that: 1. offer advantages over AES-GCM; 2. are suitable for widespread adoption. call for submissions in 2013 deadline for submissions march 2014 expected announcement of winners: Dec 2017 committee: 18 members. all proposals open for public evaluation. http://competitions.cr.yp.to/caesar.html CAESAR competition • march 2014: 57 submissions received • jul 2015: 30 second-round candidates announced • mar 2016 (tentative) announcement of third-round candidates • dec 2016 (tentative) announcement of finalists • dec 2017 (tentative) announcement of final portfolio source: http://homes.esat.kuleuven.be/~eandreev/caesarviz/ CAESAR candidates features • type of construction: BC-based, stream cipher-based, sponge-based, permutation-based • security level (64-256 bits), proof of security • implementation features: parallelizable, inverse-free, platform target • nonce-misuse, RUP security • incremental AE • intermediate tags • etc. CAESAR candidates features Source: http://homes.esat.kuleuven.be/~eandreev/caesarviz/ CAESAR candidates See also: • AE Zoo: https://aezoo.compute.dtu.dk/doku.php • CAESAR performance: http://www1.spms.ntu.edu.sg/~syllab/speed/ a few CAESAR designs AES-COPA Figures from CAESAR submission document: http://competitions.cr.yp.to/round1/aescopav1.pdf a few CAESAR designs Acorn AES-AEGIS Figures from CAESAR submission document: http://competitions.cr.yp.to/round1/acornv1.pdf and http://competitions.cr.yp.to/round1/aegisv1.pdf a few CAESAR designs AES-OTR Figures from CAESAR submission document: http://competitions.cr.yp.to/round1/aesotrv1.pdf a few CAESAR designs Ketje and Keyak (based on sponge constructions) Figures from CAESAR submission document: http://competitions.cr.yp.to/round1/ketjev11.pdf and http://keyak.noekeon.org/Keyak-1.2.pdf a few CAESAR designs OCB Figure from CAESAR submission document: http://competitions.cr.yp.to/round1/ocbv1.pdf AE beyond CAESAR… • some interesting research problems/challenges: • network applications: authenticating and encrypting streams of data (rather than single “message”). • useful network features, e.g. combining error correcting codes with authenticated encryption. • AE for IoT • Trust in released unverified plaintext. • ECRYPT-CSA project currently considering challenges in AE (http://chae.cr.yp.to/index.html) conclusions Authenticated Encryption. • very active area of research in symmetric-key cryptography. • real world applications and impact. • CAESAR ciphers likely to start being deployed soon (network protocols, IoT) • still several challenges ahead in design, implementation and analysis. thank you and questions?.