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 Hybrid encryption gives the functionality of public-key encryption at the (asymptotic) efficiency of private-key encryption! Hybrid encryption message pk Enc’ Enc k random! “encapsulated key” Enc = public-key encryption scheme Enc’ = private-key encryption scheme ciphertext “encrypted message” Security If public-key component and private-key component are secure against chosen-plaintext attacks, then hybrid encryption is secure against chosen-plaintext attacks Extension How should hybrid encryption be done when sending the same message to multiple recipients (e.g., email encryption)? 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… 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 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 chosenciphertext attack 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 chosenciphertext attacks (and non-malleable) 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 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 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! Signature schemes 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 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) Signatures vs. MACs Could MACs work in the previous example? – Computing one signature vs. multiple MACs – Managing one key vs. multiple keys – Public verifiability Not obtained – Transferability by MACs! – Non-repudiation 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 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 “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? 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