1 / 28

CMSC 414 Computer and Network Security Lecture 4

CMSC 414 Computer and Network Security Lecture 4. Jonathan Katz. Review. If we want perfect secrecy, we face several inherent limitations Key as long as the message Key used only once Not secure against chosen-plaintext attacks

duff
Download Presentation

CMSC 414 Computer and Network Security Lecture 4

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. CMSC 414Computer and Network SecurityLecture 4 Jonathan Katz

  2. Review • If we want perfect secrecy, we face several inherent limitations • Key as long as the message • Key used only once • Not secure against chosen-plaintext attacks • Computational secrecy offers the potential to circumvent these limitations • E.g., the pseudo-one-time pad • Which drawbacks does this address?

  3. Attack taxonomy • So far, we have been considering only passive eavesdropping of a single ciphertext • aka, ciphertext-only attack • In practice, stronger attacks need to be considered • Known-plaintext attacks • Chosen-plaintext attacks • Implies security for multiple messages encrypted using the same key • Chosen-ciphertext attacks (by default, encompasses chosen-plaintext attacks)

  4. Enck(m2) m2 Definitions? c = Enck(m) Deck(c’) k k Enck(m1) In all cases, a bounded adversary should be unable to determine (with probability much better than ½) whether ma or mb was encrypted c’ m1 I know the message m is either ma or mb, but which one? Chosen-plaintext attack Chosen-ciphertext attack Ciphertext-only attack

  5. c Chosen-plaintext security • Is the definition too strong? Voters Enck(Obama) Enck(McCain)

  6. Chosen-plaintext security • Is security against chosen-plaintext attacks even possible?? • Deterministic encryption schemes cannot be secure against chosen-plaintext attacks • Nor can they be secure for encrypting multiple messages • To be secure against chosen-plaintext attack, encryption must be randomized • Moral: always use randomized encryption!

  7. Minimum requirements • The minimum level of security nowadays is security against chosen-plaintext attacks • But security against chosen-ciphertext attacks (or even stronger) is often necessary for certain applications • Make sure you are aware of this when deploying encryption! • We will revisit this issue after discussing message authentication

  8. Block ciphers • Keyed, invertible permutation F • Large key space, large block size • Indistinguishable from a random permutation • A block cipher is not an encryption scheme • A block cipher can be used to build an encryption scheme (and other things as well) • Example – the “trivial” encryption scheme: • C = FK(m) • This is not randomized…

  9. Data Encryption Standard (DES) • Developed in 1970s by IBM / NSA / NBS • Non-public design process • 56-bit key, 64-bit input/output • A 64-bit key is derived from 56 random bits • One bit in each octet is a parity-check bit • The short key length is a major concern… • The short block length is also a concern

  10. Concerns about DES • Short key length • DES “cracker”, built for $250K, can break DES in days • Computation can be distributed to make it faster • Does not mean “DES is insecure”; depends on desired security • Short block length • Repeated blocks happen “too frequently” • Some (theoretical) attacks have been found • Claimed known to DES designers 15 years before public discovery! • Non-public design process

  11. 3DES/triple-DES • Expands the key length • Now, key K = (K1, K2); |K| = 112 • Still has the short block length • The “new” block cipher is just: • EK1,K2(m) = DESK1(DES-1K2(DESK1(m))) • This is a permutation, and invertible • Fairly slow…but widely used in practice

  12. AES • Public contest sponsored by NIST in ’97 • 15 candidates submitted • Narrowed to 5 finalists in ’99 • Winner selected in 2000 • Entire contest open; intense cryptanalytic effort • Rijndael selected as the AES • Supports variety of block/key sizes, but defaults to 128-bit key length and 128-bit block length • 2128 is a huge number • Number of seconds since big bang (estimate): ~258 • Number of nanoseconds since big bang: ~290 • Both efficiency and security taken into account • The “most secure” finalist was not the one chosen

  13. Other block ciphers? • No compelling reason to use anything but AES • Unless (possibly) you have very severe performance requirements, or are paranoid about security • Even then, think twice • Same goes for stream ciphers (which are essentially PRNGs)

  14. Modes of encryption • Used for encrypting a long message m1, …, mn • ECB • Ci = FK(mi); the ciphertext is (C1, …, Cn) • CBC • IV; Ci = FK(mi Ci-1); the ciphertext is (IV, C1, …, Cn) • OFB (stream cipher mode) • IV; zi = FK(zi-1); Ci = zi mi; the ciphertext is (IV, C1, …, Cn) • CTR (stream cipher mode) • IV; zi = FK(IV+i); Ci = zi mi; the ciphertext is (IV, C1, .., Cn) • Others…

  15. Security? • ECB should not be used • Why?

  16. The effect of ECB mode original encrypted using ECB mode *Images from Wikipedia

  17. Security • CBC, OFB, and CTR modes are secure against chosen-plaintext attacks • CBC, OFB, and CTR modes are not secure against chosen-ciphertext attacks *Images from Wikipedia

  18. Message integrity

  19. Message integrity m m’

  20. Encryption does not provide integrity • “Since encryption garbles the message, decryption of a ciphertext generated by an adversary must be unpredictable” • WRONG • E.g., one-time pad, CBC-/CTR-mode encryption • Why is this a concern? • Almost always, integrity is needed in addition to secrecy • Lack of integrity can lead to lack of secrecy • Use message authentication codes (MACs)

  21. Message authentication code (MAC) • In the private-key setting, the tool for achieving message integrity is a MAC • Functionality: • MACK(m) = t (we call t the “tag”) • VrfyK(m, t) = 0/1 (“1” = “accept” / ”0”=“reject”) • Correctness…

  22. Bob Alice MAC usage m, t k k Vrfyk(m’,t’) ?? t = Mack(m) • Shared key k • Sender computes a tag t on the message m using k • Receiver verifies the message/tag pair using k

  23. Bob Bob K K MAC usage

  24. Defining security • Attack model: • A random key k is chosen • Attacker is allowed to obtain t1 = MACk(m1), …, tn = MACk(mn) for any messages m1, …, mn of its choice • “Break” of security Attacker “breaks” the scheme if it outputs a forgery; i.e., (m, t) with: • m ≠ mi for all i • VrfyK(m, t) = 1

  25. Defining security • A MAC is secure if for all attackers running for some time T (e.g., T=100 years), the probability that the attacker “breaks” the scheme is at most  (e.g.,  = 2-80) • The key length lower-bounds  as always • The tag length also lower-bounds  • Is the definition too strong? • When would an attacker be able to obtain tags on any messages of its choice?! • Why do we count it as a break if the adversary outputs a forgery on a meaningless message?!

  26. Replay attacks • A MAC inherently cannot prevent replay attacks • Replay attacks must be prevented at a higher level of the protocol! • (Note that whether a replay is ok is application-dependent.) • Replay attacks can be prevented using nonces, timestamps, etc.

  27. A MAC for short messages • Let F be a block cipher with n-bit output • To authenticate m using key k, compute t = Fk(m) • Vrfyk(m, t): output 1 iff t = Fk(m) • Why is this secure?

  28. (Informal) sketch of security • Replace Fk with a random permutation f • Can do this since F is a block cipher • Seeing f(m1), …, f(mt) does not help (much) to predict f(m) for any m{m1,…,mt} • If adversary outputs (m, t), the probability that t is correct is roughly 2-n • For n large enough, the probability of forgery is small

More Related