1 / 20

CMSC 414 Computer and Network Security Lecture 8

CMSC 414 Computer and Network Security Lecture 8. Jonathan Katz. Hybrid encryption. Public-key encryption is “slow” Encrypting “block-by-block” would be inefficient for long messages

tom
Download Presentation

CMSC 414 Computer and Network Security Lecture 8

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 8 Jonathan Katz

  2. Hybrid encryption • Public-key encryption is “slow” • Encrypting “block-by-block” would be inefficient for long messages • Hybrid encryption gives the functionality of public-key encryption at the (asymptotic) efficiency of private-key encryption!

  3. Enc’ Enc Hybrid encryption message pk “encrypted message” ciphertext “encapsulated key” k random! Enc = public-key encryption scheme Enc’ = private-key encryption scheme

  4. Security • If public-key component and private-key component are secure against chosen-plaintext attacks, then hybrid encryption is secure against chosen-plaintext attacks

  5. Extension • How should hybrid encryption be done when sending the same message to multiple recipients (e.g., email encryption)?

  6. Malleability • All the public-key encryption schemes we have seen so far are malleable • Given ciphertext c that encrypts (unknown) message m, possible to generate a ciphertext c’ that encrypts a related message m’ • In the public-key setting, security against chosen-ciphertext attacks implies non-malleability • In many scenarios, malleability/chosen-ciphertext attacks are problematic • E.g., auction example; password example; Bleichenbacher attack…

  7. Bleichenbacher’s attack • RSA PKCS #1 v1.5 is actually defined as: c = (00 || 02 || r || 0 || m)e mod N • When decrypting, return an error if formatting is not obeyed • This enables a chosen-ciphertext attack that relies only on the ability to detect errors upon decryption

  8. Malleability • All the public-key encryption schemes we have seen so far are malleable • Given a ciphertext c that encrypts an (unknown) message m, possible to generate a ciphertext c’ that encrypts a related message m’ • Note: the problem is not integrity (there is no integrity in public-key encryption, anyway), but malleability and/or the ability to conduct a chosen-ciphertext attack

  9. Malleability in private-key setting • Malleability is an issue in the private-key setting as well • Recall that CBC and CTR mode are both vulnerable to chosen-ciphertext attacks, and are malleable • Authenticated encryption schemes (e.g., “encrypt-then-authenticate”) are secure against chosen-ciphertext attacks (and non-malleable)

  10. Non-malleable public-key enc. • RSA-based: OAEP (PKCS #1 v2.1) • Can be proven secure against chosen-ciphertext attacks based on the RSA assumption and the assumption that underlying hash functions are “truly random” • Diffie-Hellman based • There exist variants of El Gamal encryption that can be proven secure against chosen-ciphertext attacks based on the DDH assumption • Factor of ~2 less efficient than El Gamal

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

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

  13. Signature schemes

  14. 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 signer’s 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

  15. Typical application • Software company wants to periodically release patches of its software • Doesn’t want a malicious adversary to be able to change even a single bit of the legitimate patch • Solution: • Bundle a copy of the company’s 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)

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

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

  18. Security? • Analogous to MACs • Except that adversary is given the signer’s 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

  19. “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?

  20. 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 one signature on a message of the adversary’s choice

More Related