CMSC 414 Computer and Network Security Lecture 9

1
CMSC 414Computer and Network SecurityLecture 9

• Jonathan Katz

2
Non-malleable public-key enc.

• RSA-based OAEP
• Diffie-Hellman based

3
PKCS 1 v2.1 (e.g., OAEP)
m 00
r
e
m1
m2
c
mod N
4
Status of OAEP

• Can be proven secure against chosen-ciphertext
  attacks based on the RSA assumption and the
  assumption that the hash functions G, H are
  truly random

5
Other alternatives

• There exist variants of El Gamal encryption that
  can be proven secure against chosen-ciphertext
  attacks based on the DDH assumption (and no
  unrealistic assumptions regarding hash functions)
• Factor of 2 less efficient than El Gamal

6
Hybrid encryption

• When using hybrid encryption, if both components
  are secure against chosen-ciphertext attacks then
  the combination is also secure against
  chosen-ciphertext attacks

7
Recommendations

• Always use authenticated encryption in the
  private-key setting
• E.g., encrypt-then-authenticate
• Always use a public-key encryption scheme secure
  against chosen-ciphertext attacks!
• E.g., RSA PKCS 1 v2.1
• When using hybrid encryption, combine them!

8
Signature schemes
9
Basic idea

• A signer publishes a public key pk
• As usual, we assume everyone has a correct copy
  of pk
• To sign a message m, the signer uses its private
  key to generate a signature ?
• Anyone can verify that ? is a valid signature on
  m with respect to the signers public key pk
• Since only the signer knows the corresponding
  private key, we take this to mean the signer has
  certified m
• Security no one should be able to generate a
  valid signature other than the legitimate signer

10
Typical application

• Software company wants to periodically release
  patches of its software
• Doesnt want a malicious adversary to be able to
  change even a single bit of the legitimate patch
• Solution
• Bundle a copy of the companys public key with
  initial copy of the software
• Software patches signed (with a version number)
• Do not accept patch unless it comes with a valid
  signature (and increasing version number)

11
Signatures vs. MACs

• Could MACs work in the previous example?
• Computing one signature vs. multiple MACs
• Managing one key vs. multiple keys
• Public verifiability
• Transferability
• Non-repudiation

Not obtained by MACs!
12
Functional definition

• Key generation algorithm randomized algorithm
  that outputs (pk, sk)
• Signing algorithm
• Takes a private key and a message, and outputs a
  signature ? ? Signsk(m)
• Verification algorithm
• Takes a public key, a message, and a signature
  and outputs a decision bit b Vrfypk(m, ?)
• Correctness for all (pk, sk),
  Vrfypk(m, Signsk(m)) 1

13
Security?

• Analogous to MACs
• Except that adversary is given the signers
  public key
• (pk, sk) generated at random adversary given pk
• Adversary given ?1 Signsk(m1), , ?n
  Signsk(mn) for m1, , mn of its choice
• Attacker breaks the scheme if it outputs a
  forgery i.e., (m, ?) with
• m ? mi for all i
• Vrfypk(m, ?) 1

14
Textbook RSA signatures

• Public key (N, e) private key (N, d)
• To sign message m ? ZN, compute ? md mod N
• To verify signature ? on message m, check whether
  ?e m mod N
• Correctness holds
• what about security?

15
Security of textbook RSA sigs?

• Textbook RSA signatures are not secure
• Easy to forge a signature on a random message
• Easy to forge a signature on a chosen message,
  given two signatures of the adversarys choice

16
Hashed RSA

• Public key (N, e) private key (N, d)
• To sign message m, compute ? H(m)d mod N
• To verify signature ? on a message m, check
  whether ?e H(m) mod N
• Why does this prevent previous attacks?
• Note has the added advantage of handling long
  messages for free

17
Security of hashed RSA

• Hashed RSA signatures can be proven secure based
  on the hardness of the RSA problem, if the hash
  is modeled as a random function
• Proof in CMSC456
• Variants of hashed RSA have been standardized,
  and are used in practice

18
DSA/DSS signatures

• Another popular signature scheme, based on the
  hardness of the discrete logarithm problem
• Introduced by NIST in 1992
• US government standard
• I will not cover the details, but you should know
  that it exists

19
Hash-and-sign

• Say we have a secure signature scheme for short
  messages (e.g., hashed RSA, DSS, )
• How to extend it for longer messages?
• Hash and sign
• Hash message to short digest sign the digest
• Used extensively in practice

20
Crypto pitfalls and recommendations
21
Crypto pitfalls?

• Crypto deceptively simply
• Why does it so often fail?
• Important to distinguish various issues
• Bad cryptography, bad implementations, bad
  design, etc.
• Even good cryptography can often be
  circumvented by adversaries operating outside
  the model
• Even the best cryptography only shifts the
  weakest point of failure to elsewhere in your
  system
• Systems are complex
• Avoid the first be aware of 2-4

22
Cryptography is not a magic bullet

• Crypto is difficult to get right
• Must be implemented correctly
• Must be integrated from the beginning, not added
  on after the fact
• Need expertise a little knowledge can be a
  dangerous thing
• Cant be secured by Q/A, only (at best) through
  penetration testing and dedicated review of the
  code by security experts

23
Cryptography is not a magic bullet

• Crypto alone cannot solve all security problems
• Key management social engineering insider
  attacks
• Need to develop appropriate threat/trust models
  for the system as a whole
• Defense in depth
• Need for review, detection, and recovery
• Security as a process, not a product

24
Human factors

• Crypto needs to be easy to use both for end-users
  and administrators
• Important to educate users about appropriate
  security practices

25
General recommendations

• Use only standardized algorithms and protocols
• No security through obscurity!
• Dont implement your own crypto
• If your system cannot use off-the-shelf crypto
  components, re-think your system
• If you really need something new, have it
  designed and/or evaluated by an expert
• Dont use the same key for multiple purposes
• E.g., encryption and MAC or RSA encryption and
  signatures
• Use sufficient entropy when choosing keys