Slides for lecture 4

advertisement
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
 Assigned reading on course syllabus
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
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
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
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)
Definitions?
c = Enck(m)
k
k
c’
Ciphertext-only attack
Known/chosen-plaintext attack
Chosen-ciphertext attack
I know the message m
is either m0 or m1,
but which one?
Chosen-plaintext security
 Is the definition too strong?
 Voting example:
c
 Midway example
Voters
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!
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
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…
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…
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
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
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
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
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
Download