- By
**duff** - Follow User

- 98 Views
- Uploaded on

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

### CMSC 414Computer and Network SecurityLecture 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
- Computational secrecy offers the potential to circumvent these limitations
- E.g., the pseudo-one-time pad
- Which drawbacks does this address?

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)

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

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

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…

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

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

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

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)

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…

Security?

- ECB should not be used
- Why?

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

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)

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…

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

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?!

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.

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?

(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

Download Presentation

Connecting to Server..