1 / 46

Cryptography

Cryptography. Lecture 3 Stefan Dziembowski www.dziembowski.net stefan@dziembowski.net. Plan. Encryption of multiple messages. Stream ciphers Block ciphers (an introduction) Some images in this document are take from From Wikipedia, the free encyclopedia. On the previous lecture:.

colby
Télécharger la présentation

Cryptography

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Cryptography Lecture 3Stefan Dziembowskiwww.dziembowski.net stefan@dziembowski.net

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

  3. On the previous lecture: cryptographic PRGs semantically-secure encryption

  4. Multiple messages . . . c0=Enc(k,m0) c1=Enc(k,m1) c2=Enc(k,m2) k k Alice Bob m0 c0=Enc(k,m0) m1 c1=Enc(k,m1) Eve m2 c2=Enc(k,m2) . . . . . .

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

  6. CPA-security Alternative name:CPA-secure • Security definition: • We say that (Gen,Enc,Dec)hasindistinguishable encryptions under a chosen-plaintext attack (CPA)if any • randomized polynomial timeadversary • 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”.

  7. “. . .NF. . .” 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 runningout of water Midway BINGO!

  8. 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!

  9. 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’

  10. What to do? There are two solutions: • The synchronized mode • The unsynchronized mode

  11. Synchronized mode G : {0,1}n→ {0,1}very large – a PRG. s G is computed “on fly” . . . G(s) m0 m1 m2 m3 xor c0 c1 c2 c3 Disadvantage: Alice and Bob need to know how much of G(s) was already used.

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

  13. 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 andsome pairs (IV0,G(IV0,s)), (IV1,G(IV1,s)), (IV2,G(IV2,s)), . . . where s,IV,IV0,IV1,IV2... are random. with a non-negligible advantage IV s G G(IV,s) R or ? IV (IV0,G(IV0,s)), (IV1,G(IV1,s)), (IV2,G(IV2,s)), . . .

  14. How to construct such a PRG? • An old-fashionedapproach: • take a standardPRGG • 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

  15. 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](veryelegant, 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)

  16. 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 236 bytes of output) • eStream project (November 2004 – May 2008) will soon announce the winners not very secure completely broken

  17. RC4 • Designed by Ron Rivest(RSA Security)in 1987. 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

  18. RC4 – an overview note: no IV key k |k| = 40 – 256 bits key-schedulingalgorithm(KSA) indices i j array S |S| = 256 bytes in each round this is updatedand1 byte is output (this is called a “pseudo-random generation algorithm (PRGA)”)

  19. 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 don’t read it! • 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

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

  21. 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.

  22. 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 1500bytes, • 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 802.11"

  23. 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.]

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

  25. 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-bitIV). 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

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

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

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

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

  30. 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”.

  31. Scenario 1 security parameter 1n oraclechooses a random kє {0,1}n. distinguisher D m1 є {0,1}n Fk(m1) m2 є {0,1}n Fk(m2) . . . mt є {0,1}n Fk(mt) outputs b є {0,1}

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

  33. 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

  34. 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: 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.

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

  36. Electronic Codebook mode encryption decryption

  37. 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

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

  39. 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) –

  40. Output Feedback (OFB) mode encryption decryption

  41. 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 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 +

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

  43. 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. +

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

  45. 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”.

  46. 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.

More Related