Modern authenticated encryption

Transcription

1 Modern authenticated encryption Joan Daemen STMicroelectronics and Radboud University Zagreb 2O16 Zagreb, Kroatia, March 23, / 46

2 Authenticated encryption: what and why Outline 1 Authenticated encryption: what and why 2 An ideal AE scheme 3 Making it practical 4 Dealing with usage wishes and worries 5 Keyak and Ketje 6 Nonceless AE: Haddoc 7 Robust AE: Mr. Monster Burrito 2 / 46

3 Authenticated encryption: what and why What is authenticated encryption (AE)? Messages and cryptograms M = (AD, P) message with associated data and plaintext M c = (AD, C, T) cryptogram with assoc. data, ciphertext and tag All of M is authenticated but only P is encrypted wrapping: M to M c unwrapping: M c to M Symmetric cryptography: same key used for both operations Authentication aspect unwrapping includes verification of tag T if not valid, it returns an error Note: this is usually called AEAD 3 / 46

4 Authenticated encryption: what and why The CAESAR competition Public competition for AE schemes consortium from academia and industry aims for portfolio instead of single winner CAESAR committee (secretary Dan Bernstein) Timeline submission deadline: March 15, rounds foreseen end of round 1: July 7, 2015 target end date: December 2017 Status: Round 1: 57 candidates Round 2: 29 left 4 / 46

5 Authenticated encryption: what and why CAESAR 2nd round candidates 7 points! Singapore Hongjun Wu (& co) 4, Jean, Nikolic & Peyrin 3 5 points! Belgium COSIC team 2, FX Standaert& co, Keccak team 2 3 points! California Rogaway, Krovetz & co 3 Japan NTT & co team, Minematsu, NEC & co team 2 points! India Nandi & co 2 Switzerland Aumasson & co, EPFL team 1 point Luxembourg Biryukov & Khovratovich Germany Lucks & co from Weimar Austria Mendel, Schläffer & co from IAIK Graz Poland Morawiecki, Gaj, Pieprzyk & co Macedonia Danilo Gligoroski& co Finland Markku Saarinen China Lei Wang 5 / 46

6 Authenticated encryption: what and why Limitations of AE No protection against traffic analysis AE does not hide length and number of messages to be addressed separately: random padding and dummy messages Determinism: equal messages lead to equal cryptograms information leakage concern of replay attacks solution: ensure message uniqueness at wrapping end include nonce N in input when wrapping wrapping becomes stateful a simple message counter suffices From now on we always include a nonce N 6 / 46

7 Authenticated encryption: what and why Functional behaviour Wrapping: state: K and past nonces N input: M = (N, AD, P) output: C, T or processing: if (N N ) return else add N to N and return C, T Wrap[K](N, AD, P) Unwrapping: state: K input: M c = (N, AD, C, T) output: P or processing: return Unwrap[K](N, AD, C, T): P if valid and otherwise 7 / 46

8 Authenticated encryption: what and why Sessions Session: tag in cryptogram authenticates also previous messages full sequence of messages since the session started Additional protection against: insertion, omission, re-ordering of messages within a session Attention point: last message of session Alternative views: split of a long cryptogram in shorter ones intermediate tags See [Bellare, Kohno and Namprempre, ACM 2003], [Keccak Team, SAC 2011], [Boldyreva, Degabriele, Paterson, Stam, EC 2012] and [Hoang, Reyhanitabar, Rogaway and Vizár, 2015] 8 / 46

9 Authenticated encryption: what and why Functional behaviour, with sessions 1 K, N AD (1) P (1) AD (2) P (2) AD (3) P (3) C (1) T (1) C (2) T (3) C (3) T (2) Session start: creation of stateful session object D if (N N ) (past nonces) return else add N to N and create D with State Start(K, N) Wrapping return C (i), T (i) D.Wrap(AD (i), P (i) ) this updates State Unwrapping return D.Unwrap(AD (i), C (i), T (i) ): P (i) or in case of no error, this updates State 9 / 46

10 Authenticated encryption: what and why Why (session-based) authenticated encryption? Convenience often both are confidentiality and integrity are needed one scheme to choose instead of two Efficiency combination can be more efficient than sum of the two, e.g., CBC encryption and CMAC: 2 block cipher calls per input block OCB3 AE: 1 block cipher call per input block sponge-based AE: 1 permutation call per input block Reduction of attack surface differential attacks limited to session setup due to nonce chosen ciphertext attacks ineffective due to Increase of robustness against fault attacks in wrap due to nonce requirement in unwrap due to 10 / 46

11 An ideal AE scheme Outline 1 Authenticated encryption: what and why 2 An ideal AE scheme 3 Making it practical 4 Dealing with usage wishes and worries 5 Keyak and Ketje 6 Nonceless AE: Haddoc 7 Robust AE: Mr. Monster Burrito 11 / 46

12 An ideal AE scheme An ideal AE scheme Underlying primitive: random oracle RO output length l implied by the context RO e ( ) = RO( 1) for encryption RO a ( ) = RO( 0) for tag computation Wrapping if (N N ) it return C RO e (K N AD) P T RO a (K N AD P) Unwrapping P RO e (K N AD) C T RO a (K N AD P) If (T = T) return, else return P Note: RO input shall be uniquely decodable in K, N AD and P 12 / 46

13 An ideal AE scheme Ideal AE scheme, now supporting sessions Starting the session if (N N ) it return History K N Wrapping of M (i) = (AD (i), P (i) ) History History AD (i) 1 History History P (i) 0 return (C (i), T (i) ) and then C (i) RO(History) P (i) and then T (i) RO(History) Unwrapping of M (i) c = (AD (i), C (i), T (i) ) save current state in case of error: S History History History AD (i) 1 and then P (i) RO(History) C (i) History History P (i) 0 and then τ RO(History) if (τ = T (i) ) return P (i), else History S and then return Note: History shall be uniquely decodable in K, N AD (i) and P (i) 13 / 46

14 An ideal AE scheme Security of our ideal AE scheme Attack model: adversary can adaptively query: Start, respecting nonce uniqueness (not counted), D.Wrap (q w times) and D.Unwrap (q u times) RO(x): n times Input to RO(K ) never repeats: outputs are uniformly random intra-session: each input to RO is longer than previous one inter-session: first part of RO input (N, K) never repeated So cryptograms C (i) and tags T (i) are uniformly random 14 / 46

15 An ideal AE scheme Security of our ideal AE scheme (cont d) Forgery: building sequence of valid cryptograms M (1) c... M (l) c not obtained from calls to wrap for some M (1)... M (l) Privacy break: learning on plaintext bits of M (l) c without unwrapping all of M (1) c... M (l) c Complete security breakdown: key recovery single target key: getting one specific key multiple target: getting one key out of m target keys 15 / 46

16 An ideal AE scheme Security of our ideal AE scheme (cont d 2) Forgery best strategy: send random but well-formatted cryptograms success probability for q u attempts: q u 2 T Privacy break best strategy at unwrap: send cryptograms with modified C i or T i success probability for q u attempts: q u 2 T Key retrieval best strategy: exhaustive key search single target: success probability for n key guesses n2 K multi-target: success probability for n key guesses (m + 1)n2 K Countermeasure against multi-target security erosion: global nonce Summary: 1 out of m keys recovery after 2 K log 2 (m+1) offline calls to RO( ) single privacy break/forgery after 2 T online calls to D.Unwrap 16 / 46

17 Making it practical Outline 1 Authenticated encryption: what and why 2 An ideal AE scheme 3 Making it practical 4 Dealing with usage wishes and worries 5 Keyak and Ketje 6 Nonceless AE: Haddoc 7 Robust AE: Mr. Monster Burrito 17 / 46

18 Making it practical Intermezzo: the sponge M pad trunc Z r c 0 0 outer inner f f f f f f absorbing squeezing Arbitrary input and output length Parameters: rate r and capacity c with r + c = b (width) Proven security strength when input M starts with long key: expected workload to distinguish from RO is 2 c ϵ calls to f deals with average behaviour over all possible f of width b f should be designed such that there are no better attacks 18 / 46

19 Making it practical Instantiating our ideal AE scheme Replace RO by a sponge function (e.g. Keccak) Due to security proof [Andreeva, Daemen, Mennink, Van Assche FSE 2015]: key recovery: min(2 K log 2 m, 2 c ϵ ) offline calls to Keccak-f privacy break/forgery: min(2 T, 2 c/2 ) online calls to Keccak-f... assuming f (e.g., Keccak-f) has no exploitable properties Practical scheme? History includes all previous messages storing it may require huge buffer Practical scheme! sponge variant operating sequentially on a b-bit state S at any point S: collision-resistant keyed hash of History instantiations: our CAESAR submissions Keyak and Ketje 19 / 46

20 Making it practical Instantiating our ideal AE scheme Replace RO by a sponge function (e.g. Keccak) Due to security proof [Andreeva, Daemen, Mennink, Van Assche FSE 2015]: key recovery: min(2 K log 2 m, 2 c ϵ ) offline calls to Keccak-f privacy break/forgery: min(2 T, 2 c/2 ) online calls to Keccak-f... assuming f (e.g., Keccak-f) has no exploitable properties Practical scheme? History includes all previous messages storing it may require huge buffer Practical scheme! sponge variant operating sequentially on a b-bit state S at any point S: collision-resistant keyed hash of History instantiations: our CAESAR submissions Keyak and Ketje 19 / 46

21 Making it practical Intermezzo: full-state keyed duplex (FSKD) K σ 0 Z 0 σ 1 Z 1 σ 2 Z 2 0 f outer inner f f init duplexing duplexing Duplex: alternating absorbing and squeezing Full-state absorbing (b bits instead of r bits) Security proof in [Mennink, Reyhanitabar and Vizár, 2015] relies on [Andreeva, Daemen, Mennink, Van Assche FSE 2015] basically same bounds as classical sponge in keyed mode 20 / 46

22 Making it practical Advantages of sponge-based AE Smaller surface for cryptanalysis than block-cipher modes there are no round keys evolving state during session: moving target Cheaper protection against side channel attacks DPA and DEMA limited to session setup due to nonce unicity moving target during session Optimization of ratio security strength vs memory usage 21 / 46

23 Dealing with usage wishes and worries Outline 1 Authenticated encryption: what and why 2 An ideal AE scheme 3 Making it practical 4 Dealing with usage wishes and worries 5 Keyak and Ketje 6 Nonceless AE: Haddoc 7 Robust AE: Mr. Monster Burrito 22 / 46

24 Dealing with usage wishes and worries Wish for being online Online: being able to wrap or unwrap a message on-the-fly Avoid having to buffer long messages Online unwrapping implies returning unverified plaintext but security of our scheme relies on it two ways to tackle this problem Tolerating Release of Unverified Plaintext (RUP) catastrophic fragmentation attack [Albrecht et al., IEEE S&P 2009] add security notions and attacks [Andreeva et al., ASIACRYPT 2014] try to satisfy (some of) these: costly Our solution: address this with sessions split long cryptogram into short ones, each with tag shorten cryptograms til they fit the unwrap buffer 23 / 46

25 Dealing with usage wishes and worries Wish for surviving sloppy nonce management Our assumption: K, N is unique per (wrapping) Session Start users/implementers do not always respect this wish to limit consequences of nonce violation All online AE schemes leak in case of nonce violation equality of first messages of session leaks in any case stream encryption: re-use of keystream block encryption: just equality of block(s) leaks low entropy plaintexts become an issue successful active attacks for quasi all proposed schemes Consensus among experts on following: ideal security in case of nonce misuse hard to define user shall be warned to not allow nonce violation calling an AE scheme nonce-misuse resistant gives wrong message Our stance: there is no excuse for nonce violation 24 / 46

26 Dealing with usage wishes and worries Wish for parallelism Many CAESAR submissions use AES Modern CPUs have dedicated AES instruction, e.g. AES-NI on Intel pipelining: 1 cycle per round but latency of 8 to 16 cycles performing a single AES: 80 cycles performing 8 independent AES: 88 cycles Expoiting the pipeline requires ability to parallelize Also non-aes based schemes can benefit from parallelism, e.g. pipelined architectures superscalar architectures SIMD instructions Hence: support for parallelism in Keyak 25 / 46

27 Dealing with usage wishes and worries Wish for lightweight Whole world of buzzwords: IoT, Smart Grid, RFID, ad-hoc sensor and body area network, Strongly constrained resources low area: reduce chip cost low power: RF powered low energy: battery-life Specific conditions short messages transaction time, Compromising on target security strength provable security of mode consequences of improper usage, Hence: Ketje is dedicated for lightweight 26 / 46

28 Keyak and Ketje Outline 1 Authenticated encryption: what and why 2 An ideal AE scheme 3 Making it practical 4 Dealing with usage wishes and worries 5 Keyak and Ketje 6 Nonceless AE: Haddoc 7 Robust AE: Mr. Monster Burrito 27 / 46

29 Keyak and Ketje Keyak [Keccak team + Ronny Van Keer] AE scheme submitted to CAESAR (tweaked for round 2) Permutation-based mode called Motorist Makes use of Keccak-p permutations Keccak-p: reduced-round version of Keccak-f Keccak-f: permutations underlying Keccak all 6 functions in SHA-3 based on Keccak-f[1600] (24 rounds) Generic definition with 5 parameters c capacity τ tag length b width of Keccak-p n r number of rounds in Keccak-p Π degree of parallelism 28 / 46

30 Keyak and Ketje Keyak named instances 5 named instances with c = 256, τ = 128, n r = 12 Efficiency: Short messages: Π calls to Keccak-p Long messages: twice as fast as SHAKE128 Name Width b Parallelism Π River Keyak Lake Keyak Sea Keyak Ocean Keyak Lunar Keyak / 46

31 Keyak and Ketje The Motorist mode of use 0 SUV 1 T (0) SUV = Secret and Unique Value Plaintext absorbed in outer part, AD in inner part also Tag and keystream from same output block Z i Specified in three layers: Piston: Π of them, each one an FSKD Engine: finite state machine steering the Piston(s) Motorist: session starting and (un)-wrapping, using the Engine 30 / 46

32 Keyak and Ketje The Motorist mode of use 0 SUV 1 P(1) A (1) T (0) C (1) T (1) SUV = Secret and Unique Value Plaintext absorbed in outer part, AD in inner part also Tag and keystream from same output block Z i Specified in three layers: Piston: Π of them, each one an FSKD Engine: finite state machine steering the Piston(s) Motorist: session starting and (un)-wrapping, using the Engine 30 / 46

33 Keyak and Ketje The Motorist mode of use 0 SUV 1 P(1) A (1) P (2) T (0) C (1) T (1) C (2) T (2) SUV = Secret and Unique Value Plaintext absorbed in outer part, AD in inner part also Tag and keystream from same output block Z i Specified in three layers: Piston: Π of them, each one an FSKD Engine: finite state machine steering the Piston(s) Motorist: session starting and (un)-wrapping, using the Engine 30 / 46

34 Keyak and Ketje The Motorist mode of use 0 SUV 1 P(1) A (1) P (2) A (3) T (0) C (1) T (1) C (2) T (2) T (3) SUV = Secret and Unique Value Plaintext absorbed in outer part, AD in inner part also Tag and keystream from same output block Z i Specified in three layers: Piston: Π of them, each one an FSKD Engine: finite state machine steering the Piston(s) Motorist: session starting and (un)-wrapping, using the Engine 30 / 46

35 Keyak and Ketje Ketje [Keccak team + Ronny Van Keer] AE scheme submitted to CAESAR (made it to round 2) Two instances Functionally similar to Keyak Lightweight: using reduced-round Keccak-f[400] or Keccak-f[200] small footprint low computation for short messages How? 96-bit or 128-bit security (incl. multi-target) more ad-hoc: monkeyduplex instead of FSKD reliance on nonce uniqueness for key protection 31 / 46

36 Keyak and Ketje Ketje instances and lightweight features feature Ketje Jr Ketje Sr state size 25 bytes 50 bytes block size 2 bytes 4 bytes processing computational cost session start per session 12 rounds 12 rounds wrapping per block 1 round 1 round 8-byte tag comp. per message 9 rounds 7 rounds More on Ketje and Keyak: / 46

37 Keyak and Ketje Keyak and Ketje in absence of nonces Keyak may leak plaintext information XOR of 1st differing plaintext blocks in otherwise identical sessions Ketje may break down completely single-round differential attacks become possible 33 / 46

38 Nonceless AE: Haddoc Outline 1 Authenticated encryption: what and why 2 An ideal AE scheme 3 Making it practical 4 Dealing with usage wishes and worries 5 Keyak and Ketje 6 Nonceless AE: Haddoc 7 Robust AE: Mr. Monster Burrito 34 / 46

39 Nonceless AE: Haddoc Haddoc: the concept AD P PRF K CTR T C Permutation-based variant of SIV [Rogaway, Shrimpton 2006] Nonceless Leakage limited to: length of messages identical messages (AD, P) give identical cryptograms (C, T) 35 / 46

40 Nonceless AE: Haddoc Inside Haddoc: the donkeysponge PRF Absorbing phase exploits state secrecy [DR, Pelican, 2005]: usage of full state width b n init = 2: make all state bits depend on the key n absorb = 6: limit max DP to prevent state collisions Squeezing phase: n squeeze = 12, c = / 46

41 Nonceless AE: Haddoc Building blocks of Haddoc PRF: donkeysponge with input K: key input M: injective coding of (AD, P) output T = Z 256 CTR: sponge in counter mode single-block in- and outputs Z i = sponge(k T i) C i = M i Z i n r = 12 Permutations Keccak-p[1600, n r ] Keccak-p[800, n r ] 37 / 46

42 Nonceless AE: Haddoc Haddoc features Processing: long messages: about 70 % of SHAKE128 short messages: 26 rounds if P is absent we get a MAC function: long messages: about 21 % of SHAKE128 short messages: 14 rounds Advantages decryption: random access encryption: PRF parallelizable Disadvantages encryption strictly two-pass message expansion by 2n-bit tag for n-bit security 38 / 46

43 Robust AE: Mr. Monster Burrito Outline 1 Authenticated encryption: what and why 2 An ideal AE scheme 3 Making it practical 4 Dealing with usage wishes and worries 5 Keyak and Ketje 6 Nonceless AE: Haddoc 7 Robust AE: Mr. Monster Burrito 39 / 46

44 Robust AE: Mr. Monster Burrito Mr. Monster Burrito: the concept P 0 C B TW K B -1 C P 0? Robust AE [Rogaway, ACNS 2014] inspired by AEZ [Hoang, Krovetz, Rogaway, Shrimpton 2014] wide tweakable block cipher variable key-, tweak- and blocksize: K, TW and B Best possible forgery resistance for given message expansion 40 / 46

45 Robust AE: Mr. Monster Burrito Inside Mr. Monster Burrito Pʹleft K TW Pʹright F 1 F 2 F 3 F 4 C left C right Based on [Naor Reingold 1997], thanks [DJB, Tenerife 2013] F 2 and F 3 : PRF F 1 and F 4 : constraint is max DP < / 46

46 Robust AE: Mr. Monster Burrito Building blocks of Mr. Monster Burrito Asymmetric Feistel: right part is single block F i : donkeysponge instances as in Haddoc PRF F i input: K: key M: injective coding of ( B, TW, S left/right, i) F i output length: F 1, F 3 and F 4 : single-block F 2 : same length as left part Permutations Keccak-p[1600, n r ] Keccak-p[800, n r ] 42 / 46

47 Robust AE: Mr. Monster Burrito Mr. Monster Burrito features Processing block length above rate: close to 100% of SHAKE128 short block length: 56 rounds Advantages minimum data expansion for given anti-forgery level can even exploit redundancy in plaintext Disadvantages: heavyweight crypto four-pass inefficient for small block lengths 43 / 46

48 Conclusions Conclusions Keccak-based AE: our preferred: CAESAR-candidate Keyak constrained platforms: CAESAR-candidate Ketje nonceless: Haddoc and Mr. Monster Burrito will not win beauty contest but performance degradation is not dramatic Inspired by [Rogaway on AE, ACNS 2014] Q? Thanks for your attention! 44 / 46

49 Conclusions Conclusions Our advice: don t repeat nonces don t release unverified plaintext Sponge-based authenticated encryption is symmetric crypto 2.0 exciting competitive 45 / 46

50 Conclusions Thank you for your attention! 46 / 46