Cryptography Lecture 3 Stefan Dziembowski

Plan 1.Encryption of multiple messages. 2.Stream ciphers 3.Block ciphers (an introduction) Some images in this document are take from From Wikipedia, the free encyclopedia.

On the previous lecture: cryptographic PRGs semantically-secure encryption

Multiple messages Eve AliceBob m0m0 m2m2 m1m1 c 0 =Enc(k,m 0 ) c 1 =Enc(k,m 1 ) c 2 =Enc(k,m 2 ) c 1 =Enc(k,m 1 )c 2 =Enc(k,m 2 ) k k...

A chosen-plaintext attack (CPA) oracle chooses m’ 1 m’ 1 c 1 = Enc(k,m’ 1 ) has to guess b chooses m’ t m’tm’t c t = Enc(m’ t ) m 0,m 1 c = Enc(k,m b ) chooses m 0,m 1 the interaction continues... security parameter 1 n 1.selects random k = Gen(1 n ) 2.chooses a random b = 0,1... challenge phase:

CPA-security Security definition: We say that (Gen,Enc,Dec) has indistinguishable encryptions under a chosen-plaintext attack (CPA) if any randomized polynomial time adversary guesses b correctly with probability at most ε(n), where ε is negligible. Observation Every CPA-secure encryption has to be randomized, or “have a state”. Alternative name: CPA-secure

CPA in real-life Q: Aren’t we too pessimistic? A: No! CPA can be implemented in practice. A historical example: the battle of Midway (1942) The Amercans suspected that Enc(“Midway island”) = “NF” Midway we are running out of water “...NF...” BINGO!

How to encrypt multiple messages using pseudorandom generators? Of course we cannot just reuse the same seed (remember the problem with the one-time pad?) It is not just a theoretical problem!

Misuse of RC4 in Microsoft Office [Hongjun Wu 2005] RC4 – a popular PRG (or a “stream cipher”) “Microsoft Strong Cryptographic Provider” (encryption in Word and Excel, Office 2003) The seed s is a function of a password and an initialization vector. These values do not change between the different versions of the document! Suppose Alice and Bob work together on some document: Enc(k,m) Enc(k,m’) The adversary can compute m xor m’

What to do? There are two solutions: 1.The synchronized mode 2.The unsynchronized mode

c3c3 Synchronized mode G : {0,1} n → {0,1} very large – a PRG. m0m0 s G(s) m1m1 m2m2 m3m3... xor c0c0 c1c1 c2c2 G is computed “on fly” Disadvantage: Alice and Bob need to know how much of G(s) was already used.

Unsynchronized mode mimi s G(IV i,s) IV i xor IV i Enc(s,m i ) Idea Randomize the encryption procedure. Assume that G takes as an additional input an initialization vector (IV). The Enc algorithm selects a fresh random IV i for each message m i. Later, IV i is included in the ciphertext

We need an “augmented” PRG We need a PRG such that the adversary cannot distinguish G(IV,s) from a random string even if she knows IV and some pairs (IV 0,G(IV 0,s)), (IV 1,G(IV 1,s)), (IV 2,G(IV 2,s)),... where s,IV,IV 0,IV 1,IV 2... are random. s G(IV,s) G IV R ? with a non-negligible advantage or (IV 0,G(IV 0,s)), (IV 1,G(IV 1,s)), (IV 2,G(IV 2,s)),...

How to construct such a PRG? An old-fashioned approach: 1.take a standard PRG G 2.set G(IV,s) := G(H(IV,S)) where H is a “hash-function” (we will define cryptographic hash functions later) A more modern approach: design such a G from scratch. often: just concatenate IV and S

Constructions of PRGs A theoretical result: a PRG can be constructed from any one-way function [Håstad, Impagliazzo, Levin, Luby A Pseudorandom Generator from any One-way Function] (very elegant, impractical, inefficient) Based on hardness of some number-theoretic problems, e.g.: [Lenore Blum, Manuel Blum, and Michael Shub. A Simple Unpredictable Pseudo-Random Number Generator] (elegant, more efficient, still rather impractical) “Stream ciphers” (ugly, very efficient, widely used in practice)

Popular stream ciphers RC4 A5/1 and A5/1 (used in GSM)... Competitions for new stream ciphers NESSIE (New European Schemes for Signatures, Integrity and Encryption, 2000 – 2003) project failed to select a new stream cipher (all 6 candidates were broken) (where “broken” can mean e.g. that one can distinguish the output from random after seeing 2 36 bytes of output) eStream project (November 2004 – May 2008) will soon announce the winners not very secure completely broken

RC4 Designed by Ron Rivest (RSA Security) in RC4 = “Rivest Cipher 4”, or “Ron's Code 4”. Trade secret, but in September 1994 its description leaked to the internet. For legal reasons sometimes it is called: "ARCFOUR" or "ARC4“. Used in WEP and WPA and TLS. Very efficient and simple, but has some security flaws

RC4 – an overview key k key-scheduling algorithm (KSA) array Sij in each round this is updated and 1 byte is output |k| = 40 – 256 bits |S| = 256 bytes indices (this is called a “pseudo-random generation algorithm (PRGA)”) note: no IV

RC4 KSA for i from 0 to 255 S[i] := i end for j := 0 for i from 0 to 255 j := (j + S[i] + key[i mod keylength]) mod 256 swap(S[i],S[j]) endfor PRGA i := 0 j := 0 while GeneratingOutput: i := (i + 1) mod 256 j := (j + S[i]) mod 256 swap(S[i],S[j]) output S[(S[i] + S[j]) mod 256] endwhile don’t read it!

Problems with RC4 1.Doesn’t have a separate IV. 2.It was discovered that some bytes of the output are biased. [Mantin, Shamir, 2001] 3.First few bytes of output sometimes leak some information about the key [Fluhrer, Mantin and Shamir, 2001] Recommendation: discard the first bytes. 4.Other weaknesses are also known...

Use of RC4 in WEP WEP = “Wired Equivalent Privacy” Introduced in 1999, still widely used to protect WiFi communication. How RC4 is used: to get the seed, the key k is concatenated with the IV –old versions: |k| = 40 bits, |IV| = 24 bits (artificially weak because of the US export restrictions) –new versions: |k| = 104 bits, |IV| = 24 bits.

RC5 in WEP – problems with the key length |k| = 40 bits is not enough: can be cracked using a brute-force attack IV is changed for each packet. Hence |IV| = 24 bits is also not enough: –assume that each packet has length 1500 bytes, –with 5Mbps bandwidth the set of all possible IVs will be exhausted in half a day Some implementations reset IV := 0 after each restart – this makes things even worse. see Nikita Borisov, Ian Goldberg, David Wagner (2001). "Intercepting Mobile Communications: The Insecurity of "

RC5 in WEP – the weak IVs [Fluhrer, Mantin and Shamir, 2001] (we mentioned this attack already) For so-called “weak IVs” the key stream reveals some information about the key. In response the vendors started to “filter” the weak IVs. But then new weak IVs were discovered. [see e.g. Bittau, Handley, Lackey The final nail in WEP's coffin.]

This attacks are practical! [Fluhrer, Mantin and Shamir, 2001] attack: Using the Aircrack-ng tool one can break WEP in 1 minute (on a normal PC) [see also: Tews, Weinmann, Pyshkin Breaking 104 bit WEP in less than 60 seconds, 2007]

How bad is the situation? RC4 is still rather secure if used in a correct way. Example: Wi-Fi Protected Access (WPA) – a successor of WEP: several improvements (e.g. 128-bit key and a 48-bit IV). Let’s hope the eStream project will be a success! List of the eStream finalists: Profie 1 (ciphers for the software applications): CryptMT, Dragon, HC, LEX, NLS, Rabbit, Salsa20, SOSEMANUK Profile 2 (ciphers for the hardware applications): DECIM, Edon80, F-FCSR, Grain, MICKEY, Moustique, Pomaranch, Trivium

Is there an alternative to the stream ciphers? Yes! the block ciphers

Let’s start from scratch: plaintext m encryption ciphertext c key k decryption plaintext m key k Problem: the plaintexts m may be extremally long, and therefore it may be hard to analyse security of the cipher.

An idea! 1.Desing ciphers that work on small blocks (e.g. of length 128 bits) 2.Then, build the real encryption schemes out of them. plaintext m encryption ciphertext c key k decryption plaintext m key k this will be called: a block cipher warning : of course, as a stand-alone cipher it is not CPA- secure

Block ciphers – an intuition For F : {0,1}* × {0,1}*→ {0,1}* let F k (m) denote F(k,m). A block cipher is a function F such that 1.It is a keyed-permutation, i.e.: for every k function F k is a permutation on some {0,1} n (for simplicity assume: n = |k|). for every k functions F k and F k -1 are efficiently computable. 2.for a random k and any m 1,...,m t the values F k (m 1 ),...,F k (m t ) “look random”

How to formalize it? Remember: stream ciphers ≈ pseudorandom generators We will have block ciphers ≈ pseudorandom permutations Intuition: a pseudorandom permutation should not be distinguishable from a “completely random permutation”.

Scenario 1 oracle chooses a random k є {0,1} n. m 1 є {0,1} n F k (m 1 ) m 2 є {0,1} n F k (m 2 )... m t є {0,1} n F k (m t ) security parameter 1 n distinguisher D outputs b є {0,1}

Scenario 2 oracle chooses a random function F : {0,1} n → {0,1} n m 1 є {0,1} n F k (m 1 ) m 2 є {0,1} n F k (m 2 )... m t є {0,1} n F k (m t ) security parameter 1 n This of course cannot be done efficiently, but it doesn’t matter distinguisher D outputs b є {0,1}

Pseudorandom permutations – the definition We say that a keyed-permutation F : {0,1}* × {0,1}*→ {0,1}* is a pseudorandom permutation if any polynomial-time randomized distinguisher D cannot distinguish scenario 1 from scenario 2 with a non-negligible advantage: That is: | P(D outputs “1” in scenario 1) - P(D outputs “1” in scenario 2) | is negligible in n

How to construct such pseudorandom permutations? Theoretical constructions: A pseudorandom permutation can be constructed from any one-way function. Practical constructions: block ciphers. Famous block ciphers: key lengthblock length DES (1976) (Data Encryption Standard) 5664 IDEA (1991) (International Data Encryption Algorithm) AES (1998) (Advanced Encryption Standard) 128, 192 or Other: Blowfish, Twofish, Serpent,... “Practical security requirement”: the best attack should be the brute-force attack. We will discuss these constructions on the next lecture.

Block cipher modes of operation Block ciphers cannot be used directly for encryption. They are always used in some “modes of operation”: 1.Electronic Codebook (ECB) mode ← not secure, 2.Cipher-Block Chaining (CBC) mode, 3.Output Feedback (OFB) mode, 4.Counter (CTR) mode,...

Electronic Codebook mode encryption decryption

Electronic Codebook mode should not be used! This mode was used in the past. It is not secure, and should not be used. Example: ECB

Cipher-Block Chaining (CBC) encryption decryption random value that becomes part of a plaintext

CBC mode – properties Error propagation? Error in block c i affects only c i and c i+1. So, errors don’t propagate (This mode is self-synchronizing) + Can encryption be parallelized? No – Can decryption be parallelized? Yes + What if one bit of plaintext is changed (somewhere at the beginning)? Everything needs to be recomputed (not so good e.g. for disc encryption) –

Output Feedback (OFB) mode decryption encryption

CBC mode – properties Error propagation? Error in block c i affects only c i and c i+1. + but this mode is not self-synchronizing – Can encryption be parallelized? No – (but we can we can use precomputation) + Can decryption be parallelized? The same answer + What if one bit of plaintext is changed (somewhere at the beginning)? Only one block needs to be recomputed +

Counter (CTR) mode decryption encryption IV + 1IV + 2IV + 3 IV + 2IV + 1

Properties of CTR CTR has all advantages of OFB. Additionally it has the following property: random access – it is possible to decrypt one block without decrypting anything else. +

Provable security Remember the “provable security” idea? scheme X is secure. Suppose that some “computational assumption A” holds

The following can be proven Suppose that X is a pseudorandom permutation scheme X-CBC is secure. scheme X-OFB is secure. scheme X-CTR is secure. Of course, to get any information about practical relevance of these results one needs to look at the concrete parameters hidden in the “asymptotics”.

Stream ciphers vs. block ciphers Stream ciphers are a bit more efficient. But they appear to be “less secure”. It is easier to misuse them (use the same stream twice). If you encrypt a stream of data you can always use a block cipher in a CTR mode. Probably at the moment block ciphers are a better choice.