Está en la página 1de 20

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
Enc
message
Enc
k
encapsulated
key
encrypted
message
c
i
p
h
e
r
t
e
x
t

Enc = public-key encryption scheme
Enc = private-key encryption scheme
pk
random!
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
Bleichenbachers 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 chosen-
ciphertext 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 chosen-
ciphertext 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 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
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)
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!
Functional definition
Key-generation algorithm: randomized algorithm
that outputs (pk, sk)
Signing algorithm:
Takes a private key and a message, and outputs a
signature; Sign
sk
(m)
Verification algorithm:
Takes a public key, a message, and a signature and
outputs a decision bit; b = Vrfy
pk
(m, )
Correctness: for all (pk, sk),
Vrfy
pk
(m, Sign
sk
(m)) = 1
Security?
Analogous to MACs
Except that adversary is given the signers public key
(pk, sk) generated at random; adversary given pk
Adversary given
1
= Sign
sk
(m
1
), ,

n
= Sign
sk
(m
n
) for m
1
, , m
n
of its choice
Attacker breaks the scheme if it outputs a
forgery; i.e., (m, ) with:
m m
i
for all i
Vrfy
pk
(m, ) = 1
Textbook RSA signatures
Public key (N, e); private key (N, d)
To sign message m Z
N
*
, compute = m
d
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 adversarys choice

También podría gustarte