hash-cfb - authenticated encryption without a block cipher · hash-cfb, using a ﬁxed-input-length...

Hash-CFBAuthenticated Encryption Without a Block Cipher

Christian Forler1, Stefan Lucks1,David McGrew2, Jakob Wenzel1

1Bauhaus-Universität Weimar, Germany, 2Cisco Systems, USA

DIAC, Stockholm,July, 2012

–1– C. Forler, S. Lucks, D. McGrew, J. Wenzel: Hash-CFB

Outlook

GoalsFrom BC-CFB to Hash-CFBAlternativesSecurity Claims

. . . Beyond “Standard” AE

. . . Core Ideas for Proofs

. . . on Side ChannelsFinal Remarks and Summary


Goals

1. security (of course)2. feasible on constrained devices

one primitive to rule them all,one primitive to bind them . . .

3. simplicity:I easy to describeI easy to implementI easy to analyze

based on a “standard” primitive4. reasonable efficiency


From BC-CFB to Hash-CFB

0

tag

M[n]

C[n]

M[2]

C[2]

M[1]

C[1]

nonce

BC-CFB:I privacy: CFB encryptionI authenticity: trivial attacks!

1. make both T[i] = C[i] ⊕ M[I] and C[i] inputs for the(i + 1)st call

2. differentiate last primitive call from previous calls



M[1]

C[1]

M[2]

C[2]

M[n]

C[n]

0

tag

0

1 1 1 2nonce

Hash-CFB, using a fixed-input-length (FIL) hash function:I privacy: the same as CFB encryptionI authenticity: secure – see later

1. make both T[i] = C[i] ⊕ M[I] and C[i] inputs for the(i + 1)st call

2. differentiate last primitive call from previous calls–4– C. Forler, S. Lucks, D. McGrew, J. Wenzel: Hash-CFB


C[1] C[2] C[n]

M[1] M[2] M[n]

C[1] C[n]C[n−1]0

1 1 1T[1] T[n−1] T[n]T[0]

T[2]

0

S

assoc. data

tag

noncekey

2

I long-term key and nonce define message-secret S

I S is xor-ed to the previous hash output(recall that a hash function is unkeyed, by nature)

I use a VIL (variable input length) hash of theassociated data



C[1] C[2] C[n]

M[1] M[2] M[n]

C[1] C[n]C[n−1]0

1 1 1T[1] T[n−1] T[n]T[0]

T[2]

0

S

assoc. data

tag

noncekey

2

I long-term key and nonce define message-secret SI S is xor-ed to the previous hash output

(recall that a hash function is unkeyed, by nature)

I use a VIL (variable input length) hash of theassociated data



C[1] C[2] C[n]

M[1] M[2] M[n]

C[1] C[n]C[n−1]0

1 1 1T[1] T[n−1] T[n]T[0]

T[2]

0

S

assoc. data

tag

noncekey

2

I long-term key and nonce define message-secret SI S is xor-ed to the previous hash output

(recall that a hash function is unkeyed, by nature)I use a VIL (variable input length) hash of the

associated data–5– C. Forler, S. Lucks, D. McGrew, J. Wenzel: Hash-CFB

Alternativesprimitive solution

1. block cipher block cipher based hash fun.2. hash function generic composition

(e.g., counter mode & HMAC)3. compression function (whatever)

1. standard block cipher: AES, n = 128need 2n-bit hash function; plenty of goodDBL-hashes in literature, butwhat is the “standard” for DBL hashing?

2. how to deal with additional complexity andstorage? (two independent keys, two states, . . . )

3. cryptographers know the “compression functions”, butwhich standards or APIs actually define them?


Security ClaimsStandard AE Claims

message

(assoc. data)

ciphertext

auth. tag

key

nonce

I assume the hash function behaves like a good PRFI restrict the adversary to be nonce-respecting

I privacy: chosen plaintext attack (CPA) resistantI authenticity: integrity of ciphertexts (Int-CTXT)I more privacy: CPA and Int-CTXT⇒ CCA


Security Claims. . . Beyond “Standard” AE

message

(assoc. data)

ciphertext

auth. tag

key

nonce

I nonce misuse: the adversary is not always noncerespecting (e.g., due to implementation errors)

I privacy: still holds when using a new nonceI authenticity: not affected (!)

I weak assumptions:I privacy: requires the FIL HF to be a good PRFI authenticity: only requires “forgery resistance” of the

FIL HFI side-channel resistance: (see below)


Security Claims. . . Core Ideas for Proofs

I privacy: similar to block cipher based CFBI authenticity: for queries, the final hash input to

compute tag is always different:

C[n]

M[n]

C[n]C[n−1]

1T[n−1] T[n]

tag

2

I T[n] is a (keyed) hashof the message(⇒ no collisions), and

I the postfix 2 is onlyused for final hashfunction calls

so a forger would have to predict the output of thefinal FIL hash function call – even if the same noncehad been used repeatedly


Security Claims. . . on Side Channels

typical side-channel attacks:

I many measurements of a primitive operations underthe same key

I X messages, each of length L blocks:XL measurements for the same key


Security Claims. . . on Side Channels

C[1] C[2] C[n]

M[1] M[2] M[n]

C[1] C[n]C[n−1]0

1 1 1T[1] T[n−1] T[n]T[0]

T[2]

0

S

assoc. data

tag

noncekey

2

side-channel attacks against hash-CFB:I X messages, each of length L, nonce-respecting:

X measurements for key and L for each of SI even when not nonce-respecting:

adversary may find some S but only use it to tocompromise messages using that single nonce


Final Remarks and SummaryI in the paper

I SHA-224-based instantiation of HASH-CFB:I one FIL hash⇔ one compression function call

I our goals:I secure, feasable on constrained devices, simple,

efficient (in that order)I using a hash function seems to be a good approach

I security requirements (beyond “standard”):I authenticity even under nonce reuseI authenticity needs weaker assumption than privacyI some defense against side-channel attacks

I for discussion at DIAC:I Should such security requirements become a

standard for new generation AE schemes?


hash-cfb - authenticated encryption without a block cipher · hash-cfb, using a ﬁxed-input-length...

Documents