Stronger Security Variants of GCMSIV Kazuhiko Minematsu (NEC - - PowerPoint PPT Presentation

Stronger Security Variants of GCMSIV

Kazuhiko Minematsu (NEC Corporation) Joint work with Tetsu Iwata (Nagoya University) To appear at FSE 2017

Recent Advances in Authenticated Encryption 2016 Kolkata, India

1

NonceBased AE

Noncebased authenticated encryption

GCM, CCM, OCB, EAX,... uses a nonce for security repeating the nonce has critical impact on security

CounterthenMAC (incl. GCM): leaks plaintext difference For GCM, even authentication key is leaked, allows universal forgery

MRAE, SIV, and GCMSIV

Noncereuse misuseresistance AE [RS06], MRAE

Provides bestpossible security even if a nonce is repeated SIV, HBS, BTM, a version of OMD CAESAR candidates (AEZ, HS1SIV, SCT,...)

SIV, Synthetic IV [RS06]

A general approach to construct MRAE use a PRF to generate IV (also used as a tag), use IV in IVbased encryption

• [RS06] Rogaway, P

., Shrimpton, T.: A ProvableSecurity Treatment of the KeyWrap Problem. EUROCRYPT 2006

MRAE, SIV, and GCMSIV

A: associated data (AD) M: plaintext C: ciphertext

GCMSIV

GCMSIV [GL15]

Gueron and Lindell, CCS ’15 instantiation of SIV using components from GCM

GHASH, AESCTR

Provable security, O(2(nk)/2)

Typically n=128, k=32 (throughout the talk)

Very fast AESNI implementations

• [GL15] Gueron, S., Lindell, Y.: GCMSIV: Full Nonce MisuseResistant Authenticated Encryption at Under One Cycle per
• Byte. ACM CCS 2015
• q: # of enc queries

q‘ : # of dec queries

GCMSIV

• = (L,K’,K)

HL(N,A,M) = GHASHL(A,M) xor N N: nonce, n bits

GCMSIV

= (L,K’,K) HL(N,A,M) = GHASHL(A,M) xor N N: nonce, n bits

The Security Bound Is Tight

• Attack = Counter collision search
• Fix A and M, make q = 2(nk)/2 queries (Ni,A,M) with distinct Ni’s
• For i and j with msbnk(Ti) = msbnk(Tj), we observe the same

ciphertext

Overview

GCMSIV has a stronger security guarantee than GCM, i.e. noncemisuseresistance a distinguishing attack with q=2 (nk)/2 queries is possible

q=248 when k=32 does not contradict the security claim of the designers Does not happen with GCM

If |N|=96, 96bit IV is N itself – no collision for encrypiton Even if |N| is not 96 still OK (see [NMI15])

Depending on the query length distribution, the security of GCMSIV can be lower than GCM

• [NMI15] Niwa, M, Iwata, GCM security bounds reconsidered. FSE 2015.

Overview

Can we design an MRAE scheme with n/2bit security?

standard birthday bound, O(2/2n)

: total length of queries in nbit blocks

there are plenty of examples, SIV, HBS, BTM,...

GCMSIV1

a minor variant of GCMSIV achieving O(2/2n) bound not a new design, simply use the original SIV as it is

Can we design an MRAE scheme with higher security?

GCMSIV2 with 2n/3bit security

(e.g. 86bit for n=128)

GCMSIVr for r>=3 with rn/(r+1)bit security

GCMSIV

GCMSIV1

• Full nbit counter increment

(i.e. inc(X) = X+1 mod 2n) No truncation

GCMSIV1

Provably secure, n/2bit security standard birthday bound follows from [RS06]

• !!

q: # of queries (sum of enc and dec queries) ℓ : max length of query in nbit blocks : # of total plaintext blocks

Comparing security bounds

For simplicity we assume

GCMSIV MRAE bound : q2/2n32 GCM AE bound : 2/2n GCMSIV1 MRAE bound : q2 ℓ/2n +2/2n

/q denotes “average query length (AVL)” We compare the bounds, ignoring the difference of AE and MRAE

Comparing security bounds

No single winner:

GCM is always better GCMSIV1

Almost no difference when AVL > ℓ0.5

GCMSIV is better than GCM when 216 < AVL GCMSIV1 is better than GCMSIV when AVL < (232 ℓ)0.5

Since AVL <= ℓ , the condition is roughly ℓ <= 216

GCMSIV is better than GCM and GCMSIV1 if all queries are 232 blocks

GCMSIV keeps 48bit security while 32bit security for

• thers

Implementation issue

GCMSIV1 needs full nbit arithmetic addition

can degrade performance from GCMSIV (how much?) Difference from GCM’s CTR – does not allow to use GCM components as is

Beyond the Birthday Bound

• Higher security?

Beyond the birthday bound (BBB) security Secure even ~ 2n/2

• generic approach : doubling data path and component

construct a 2nbit blockcipher (BBBsecure), plug it into an existing BBsecure scheme (e.g. SIV) defined over 2nbit blocks

• Increased implementation cost
• Also instantiation is nontrivial. Are there any “standard”

256bit blockciphers?

• EK

n "K 2n SIV[EK] n … … SIV["K] 2n … …

Beyond the Birthday Bound

Provablysecure transformation of nbit BC into 2nbit BC :

Classical LubyRackoff does not work

3 or 4 Feistel rounds, up to BB security

: possible in theory, not really practical (e.g. many Feistel rounds)

Our approach :

• SIV[EK]

… n SIV[EK1] … n SIV[EK2] … n

GCMSIV2

• Two GCMSIV1 instances, taking the output sum (in a

sense)

• Independentlykeyed

Proving security

Game 1: we first focus on MAC function F2, which takes (N,A,M) > T

Assuming BCs are random permutations

We prove F2’s PRF bound

• F2

Proving security

• Game 2: we assume F2 is a perfect random function
• Proving encryption part’s security

Since (N,A,M) is unique while encryption, 2nbit IVs (T[1],T[2]) are uniformly random Similar as the analysis of F2

• Taking the sum of bounds obtained at Games 1 and 2
• F2

Analysis of F2

The proof is based on SUMECBC proposed by Yasuda [Y10] for BBBsecure MAC (in fact PRF) Essentially two EMACs with final addition of two MAC tags

EMAC = Encrypted CBCMAC Independent keys Already standardized ! (ISO 97971 algorithm 5 )

• EK1

n EK1 M[1] M[2] EK1 M[3] EK1 M[4]||pad EK2 EK3 n EK3 M[1] M[2] EK3 M[3] EK3 M[4]||pad EK4 T

[Y10] Yasuda, K.: The Sum of CBC MACs Is a Secure PRF. CTRSA 2010

Analysis of F2

PRF bound [Y10]: 12ℓ4q3 /22n Thus 2n/3bit security (ignoring ℓ)

• EK1

n EK1 M[1] M[2] EK1 M[3] EK1 M[4]||pad EK2 EK3 n EK3 M[1] M[2] EK3 M[3] EK3 M[4]||pad EK4 T

[Y10] Yasuda, K.: The Sum of CBC MACs Is a Secure PRF. CTRSA 2010

Analysis of F2

Generalize SUMECBC in two ways :

arbitrarily message hashing (not only CBCMAC) [O12]

Universal Almost Universal (AU)

2 output blocks

• EK1

EK1 M[1] M[2] EK1 M[3] EK1 M[4]||pad EK3 EK3 n EK3 M[1] M[2] EK3 M[3] EK3 M[4]||pad EK4 T1 AU H_K1 AU H_K2 EK5 EK6 T2

[O12] Osaki. A Study on Deterministic Symmetric Key Encryption and Authentication. Master's thesis at Nagoya U

The game used for F2

Gameplaying technique [Y10] introduced the game consisting of 4 cases (Case A,B,C,D) we do the same for r=2, for both T[1] and T[2]

Case A : (V[1],V[2]) = (new, new) Case B : (V[1],V[2]) = (old, new) Case C : (V[1],V[2]) = (new, old) Case D : (V[1],V[2]) = (old, old)

• F2

V[1] ∉ the previous ∉ EK’1 inputs V[2] ∉ the previous ∉ EK’3 inputs

Case A

Let #1 and #2 be the two random permutations for the finalizations of F2 Let Y(1) and Y(2) be the set of #1 and #2

• utputs never appeared before

y = (y(1), y(2)) is uniform over Y(2) =Y(1) x Y(2)

• #1

n V[1] #2 n V[2] T[1] y(1) y(2)

Case A

We need to know when T[1] = #1(V[1]) xor #1(V[2]) is uniform Fair set over S = ({0,1}n)r [L00] : a subset of X s.t.

|{(s1,…,sr) ∈ S : s1 ⊕s2 ⊕… ⊕ sr = z}| is |S|/2n for any z

[L00] : Fair set is constructed by subtracting a set C of size ir from Y(r) when r is even

i denotes the number of points queried done so far For odd r , exists a set C s.t. |C| = ir and the union of C and Y(r) yields a fair set Not necessarily unique, any construction will work

Case A

We need to know when T[1] = #1(V[1]) xor #1(V[2]) is uniform Given the condition that y = (y(1), y(2)) is in the fair set, T[1]= y(1) ⊕ y(2) is uniform In other words, we let the adversary win (“bad”) if y is not in the fair set. each point in Y(2) has prob <= 1/(2nq)2 Pr[bad] is at most i2 (2n−q)

• < in Case A
• Y(2) =Y(1) x Y(2)

C |C| = ir fair

Pr[Adv enters Case A] . Pr[Adv invokes Bad | Case A] < Pr[Adv invokes Bad | Case A]

Case A

We need to know when T[1] = #1(V[1]) xor #1(V[2]) is uniform Given the condition that y = (y(1), y(2)) is in the fair set, T[1]= y(1) ⊕ y(2) is uniform In other words, we let the adversary win (“bad”) if y is not in the fair set. each point in Y(2) has prob <= 1/(2nq)2 Pr[bad] is at most i2 (2n−q)

• < in Case A
• Y(2) =Y(1) x Y(2)

C |C| = ir fair

Using ineq.

• 2
• =

()()

• and the assumption

q <= 2n1

, Pr[bad] is

at most 2q3/22n

Pr[Adv enters Case A] . Pr[Adv invokes Bad | Case A] < Pr[Adv invokes Bad | Case A]

Case B (and C)

• V[1] collides with a previous sample, and V[2] does not
• V[1]’s collision prob <=
• In the “ideal” game we use, “bad” happens if y(2) collides

with uniform sampling (over {0,1}n)

Ideal game implementes Rand(N,A,F)>(T[1],T[2]) The probability is at most q/2n (as at most q sampled points)

• Pr[Bad] is at most
• ⋅ q

2n

• < ⋅q3

2n

in Case B

• By symmetry, the same for Case C
• #1

n V[1] #2 n V[2] T[1] y(1) y(2)

Case D

V[1] and V[2] collide with previous samples Independentlykeyed hashes – Simultaneous collision has prob 2 Always “bad”

• i.e. Pr[bad]= the probability to enter Case D

Pr[bad] is at most

• ϵ2
• < ϵ2q3 in

Case D

Taking a sum

We do the same for (V[1],V[2]) > T[2] The bound for F2 is q3/22n + q3/2n + 2q3, ignoring

constants

• Analysis of encryption part in Game 2 : (as mentioned)

mostly the same

Pseudorandomness of key stream (KS2) = security term w.r.t. encryption Counter inputs instead of V[i] In Game 2 all initial counter values are random

• F2

Concrete bound of GCMSIV2

• 2n/3bit security

Generalization to r > 2

Analysis of Fr : now r cases for each T[i] for i= 1,…, r ( in total r2 cases) We introduce X =(x1,…,xr) ∈ {0,1}r where xi =1 denotes “V[i] is old”, xi=0 denotes “V[i] is new” Case analysis based on X

Generalization to r > 2

• Case X=(0,0,..,0) : different games for even r and odd r (the

fair set construction and “bad” condition)

• Pr[bad] is bounded by (2r/2nr) qr+1
• Case X=(1,1,..,1) : for each i = 2,..,q, rtimes collision
• Pr[bad] is bounded by rqr+1
• Case X=(1,1..,1,0,..,0), weight p :

Depends on even/odd of (rp) p determines Pr[bad]

• Pr[bad] is bounded by (2r−pp/2n(rp)) qr+1
• Do the same for T[1],…,T[r], taking the sum of Pr[bad]
• Do the similar analysis for encryption (KS(r))
• …not much difficult but needs careful work

GCMSIVr (r=3), the concrete bound

3n/4bit security, in general, rn/(r+1)bit security

GCMSIVr (r=3), the concrete bound

Key size

• r hash keys and r2 + r blockcipher keys

Number of blockcipher keys can be reduced to 2r, if universal hash function is incremental No security degradation

• Hash_K1

N,A,M V[1] 1 2 Hash_K2 N,A,M V[2] T[1] Hash_K1 N,A,M V[1] 3 4 Hash_K2 N,A,M V[2] T[2] $%

Key size

• r hash keys and r2 + r blockcipher keys

Number of blockcipher keys can be reduced to 2r, if universal hash function is incremental No security degradation

• &_K1

N,A,M V[1] 1 2 &_K2 N,A,M V[2] T[1] &_K1 N,A,M 1 V[1] 1 2 &_K2 N,A,M 1 V[2] T[2]

Key size

• r hash keys and r2 + r blockcipher keys

Number of blockcipher keys can be reduced to 2r, if universal hash function is incremental No security degradation

• N,A,M

T[1] PRF_K1, K’1, K’2 N,A,M 1 T[2] PRF_K1, K’1, K’2

Key size

• r hash keys and r2 + r blockcipher keys

Number of blockcipher keys can be reduced to 2r, if universal hash function is incremental No security degradation

• &_K1

N,A,M V[1] 1 2 &_K2 N,A,M V[2] T[1] &_K1 N,A,M 1 V[1] 1 2 &_K2 N,A,M 1 V[2] T[2] $'% ( )**+

Key size

• r hash keys and r2 + r blockcipher keys

Number of blockcipher keys can be reduced to 2r, if universal hash function is incremental No security degradation

• Hash_K1

A,M V[1] 1 2 Hash_K2 A,M V[2] T[1] Hash_K1 A,M V[1] 1 2 Hash_K2 A,M V[2] T[2] $'% (N||0) (N||0) (N||1) (N||1)

Practical aspects

r determines the security and efficiency and the bandwidth May or may not be practical – for large r certainly impractical Allows reusing GCM components in close to blackbox way As far as we know the first concrete MRAE scheme to achieve BBB (rn/r+1 –bit ) security based on standard blockcipher

Thank you !