Transcript Slides for 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
 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