1 / 17

CMSC 414 Computer and Network Security Lecture 4

CMSC 414 Computer and Network Security Lecture 4. Jonathan Katz. Announcements. HW1 out Work in teams of two students Both students should contribute to all problems Material covered on HW1 is fair game for the exam Post on Piazza if you are looking for a partner

avian
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. Announcements • HW1 out • Work in teams of two students • Both students should contribute to all problems • Material covered on HW1 is fair game for the exam • Post on Piazza if you are looking for a partner • Assigned reading on course syllabus

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

  4. Stream ciphers • Basically PRNGs • Popular ones: • RC4 • A5/1 • Used for GSM cellphone encryption • Not very secure • Block ciphers can also be turned into stream ciphers

  5. Note • Which drawbacks of the one-time pad does the pseudo-OTP address? • What is the “right” threat model? • Multiple messages or a single message? • Passive/active adversary? • Ciphertext-only, known-plaintext, chosen-plaintext, chosen-ciphertext, … • The threat model matters! • The classical encryption schemes we have seen are immediately broken by a known-plaintext attack

  6. 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 (CPA-security) • Implies security for multiple messages encrypted using the same key • Chosen-ciphertext attacks (by default, encompasses chosen-plaintext attacks)

  7. Enck(m2) m2 Definitions? c = Enck(m) Deck(c’) k k Enck(m1) c’ m1 I know the message m is either m0 or m1, but which one? Ciphertext-only attack Known/chosen-plaintext attack Chosen-ciphertext attack

  8. c Chosen-plaintext security • Is the definition too strong? • Voting example: • Midway example Voters Enck(Obama) Enck(McCain)

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

  10. Minimum requirements • The minimum level of security nowadays is security against chosen-plaintext attacks • Implies security when multiple messages encrypted • Security against chosen-ciphertext attacks (or even stronger) is often necessary • Make sure you are aware of this when deploying encryption! • We will revisit this issue after discussing message authentication

  11. Block ciphers • Keyed, invertible permutation F • F is a deterministic function • Large key space, large block length • 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…

  12. Encryption from block ciphers • Enck(m) = <r, Fk(r)  m >, for random r • Randomized! • Theorem: If F is a secure block cipher, this is CPA-secure • Proof sketch…

  13. Data Encryption Standard (DES) • Developed in 1970s by IBM / NSA / NBS • Non-public design process • 56-bit key, 64-bit block length • 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

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

  15. 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 • Backward compatibility

  16. Adv. Encryption Standard (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 • Supports 128/192/256-bit keys (“default” is 128-bit keys) and 128-bit block length • 2128 is a huge number • Number of nanoseconds since big bang (estimate): ~290 • Both efficiency and security taken into account • The “most secure” finalist was not the one chosen

  17. Other block ciphers? • No compelling reason to use anything but AES • Unless (possibly) you have very severe performance requirements • Even then, think twice • In particular, AES (possibly in stream cipher mode) is usually a better choice than a dedicated stream cipher

More Related