cmsc 414 computer and network security lecture 4 n.
Skip this Video
Loading SlideShow in 5 Seconds..
CMSC 414 Computer and Network Security Lecture 4 PowerPoint Presentation
Download Presentation
CMSC 414 Computer and Network Security Lecture 4

Loading in 2 Seconds...

play fullscreen
1 / 28

CMSC 414 Computer and Network Security Lecture 4 - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'CMSC 414 Computer and Network Security Lecture 4' - duff

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




c = Enck(m)





In all cases, a bounded adversary should be unable to determine (with probability much better than ½)

whether ma or mb was encrypted



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


Chosen-plaintext security
  • Is the definition too strong?




chosen plaintext security1
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
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
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
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
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
  • 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
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
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…
  • ECB should not be used
    • Why?
the effect of ecb mode
The effect of ECB mode


encrypted using ECB mode

*Images from Wikipedia

  • 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
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
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…
mac usage



MAC usage

m, t



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
defining security
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 security1
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
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
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
(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