Hybrid Encryption: Combining Public-Key and Private-Key Encryption for Efficiency and Security

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