Cryptography Lecture 3 Stefan Dziembowski www dziembowski net

Cryptography Lecture 3 Stefan Dziembowski www. dziembowski. net stefan@dziembowski. net

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 c 210=Enc(k, m. . . 0) 1 2 k k Alice Bob m 0 c 0=Enc(k, m 0) m 1 c 1=Enc(k, m 1) m 2 Eve c 2=Enc(k, m 2). . .

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

CPA-security Alternative name: CPA-secure 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 0. 5 + ε(n), where ε is negligible. Observation Every CPA-secure encryption has to be • randomized, or • “have a state”.

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” we are running out of water Midway BINGO! “. . . NF. . . ”

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 RC 4 in Microsoft Office [Hongjun Wu 2005] RC 4 – 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 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

Synchronized mode G : {0, 1}n → {0, 1}very large – a PRG. s G is computed “on fly” . . . G(s) m 0 m 1 m 2 m 3 c 0 c 1 c 2 c 3 xor Disadvantage: Alice and Bob need to know how much of G(s) was already used.

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

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 0, IV 1, IV 2. . . are random. IV s with a non-negligible advantage G G(IV, s) R or IV (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)) often: just concatenate IV and S where H is a “hash-function” (we will define cryptographic hash functions later) • A more modern approach: design such a G from scratch.

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 • RC 4 • A 5/1 and A 5/1 (used in GSM) • . . . not very secure completely broken 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 236 bytes of output) • e. Stream project (November 2004 – May 2008) will soon announce the winners

RC 4 • Designed by Ron Rivest (RSA Security) in 1987. RC 4 = “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 "ARC 4“. • Used in WEP and WPA and TLS. • Very efficient and simple, but has some security flaws

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

RC 4 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 don’t read it! PRGA i : = 0 j : = 0 while Generating. Output: 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

Problems with RC 4 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 768 -3072 bytes. 4. Other weaknesses are also known. . .

Use of RC 4 in WEP • WEP = “Wired Equivalent Privacy” • Introduced in 1999, still widely used to protect Wi. Fi communication. • How RC 4 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.

RC 5 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 5 Mbps 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 802. 11"

RC 5 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? RC 4 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 e. Stream project will be a success! List of the e. Stream finalists: Profie 1 (ciphers for the software applications): Crypt. MT, Dragon, HC, LEX, NLS, Rabbit, Salsa 20, SOSEMANUK Profile 2 (ciphers for the hardware applications): DECIM, Edon 80, 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 key k encryption ciphertext c key k decryption plaintext m Problem: the plaintexts m may be extremally long, and therefore it may be hard to analyse security of the cipher.

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

Block ciphers – an intuition For F : {0, 1}* × {0, 1}*→ {0, 1}* let Fk(m) denote F(k, m). A block cipher is a function F such that 1. It is a keyed-permutation, i. e. : 2. • for every k function Fk is a permutation on some {0, 1}n (for simplicity assume: n = |k|). • for every k functions Fk and Fk-1 are efficiently computable. for a random k and any m 1, . . . , mt the values Fk(m 1), . . . , Fk(mt) “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 security parameter 1 n distinguisher D m 1 є {0, 1}n Fk(m 1) m 2 є {0, 1}n Fk(m 2) . . . mt є {0, 1}n Fk(mt) outputs b є {0, 1} oracle chooses a random k є {0, 1}n.

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

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 length block length 56 64 128, 192 or 256 128 DES (1976) (Data Encryption Standard) IDEA (1991) (International Data Encryption Algorithm) AES (1998) (Advanced Encryption Standard) 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. 2. 3. 4. Electronic Codebook (ECB) mode ← not secure, Cipher-Block Chaining (CBC) mode, Output Feedback (OFB) mode, 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) random value that becomes part of a plaintext encryption decryption

CBC mode – properties • Error propagation? Error in block ci affects only ci and ci+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 encryption decryption

CBC mode – properties • Error propagation? Error in block ci affects only ci and ci+1. + but this mode is not self-synchronizing – • Can encryption be parallelized? No – (but 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 IV + 1 IV + 2 IV + 3 encryption IV + 1 IV + 2 decryption IV + 3

Properties of 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? Suppose that some “computational assumption A” holds scheme X is secure.

The following can be proven Suppose that X is a pseudorandom permutation scheme X-CBC is secure. scheme X-CTR is secure. scheme X-OFB 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.