CMSC 414
Computer and Network Security
Lecture 7
Jonathan Katz
Malleability/chosen-ciphertext
security
 All the public-key encryption schemes we have
seen so far are malleable
– Given a ciphertext c that encrypts an (unknown)
message m, it is possible to generate a ciphertext c’ that
encrypts a related message m’
 In many scenarios, this is problematic
– E.g., auction example; password example
 Note: the problem is not integrity (there is no
integrity in public-key encryption, anyway), but
malleability
Malleability/chosen-ciphertext
security
 In the public-key setting, security against chosen-
ciphertext attacks is equivalent to non-malleability
 In general, always use a public-key encryption
scheme secure against chosen-ciphertext attacks!
– E.g., RSA PKCS #1 v2.1
 When using hybrid encryption, if both
components are secure against chosen-ciphertext
attacks then the combination it also secure against
chosen-ciphertext attacks
Signature schemes
Basic idea
 A signer publishes a public key pk
– As usual (for now), 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 (informally): no one should be able to generate a
valid signature other than the legitimate signer
Prototypical 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 path
 Solution:
– Bundle a copy of the company’s public key along with
initial copy of the software
– Software patches signed (perhaps 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
– 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
two signatures of the adversary’s choice
Hashed RSA
 Public key (N, e); private key (N, d)
 To sign message m, compute  = H(m)d mod N
 To verify signature  on a message m, check
whether e = H(m) mod N
 Why does this prevent previous attacks?
Security of hashed RSA
 Can we prove that hashed RSA is secure?
– Take CMSC456!
 Hashed RSA signatures can be proven secure
based on the hardness of the RSA problem, if the
hash is modeled as a random function
 Variants of hashed RSA are used in practice
DSA/DSS signatures
 Another popular signature scheme, based on the
hardness of the discrete logarithm problem
– Introduced by NIST in 1992
– US government standard
 I will not cover the details, but you need to know
that it exists
Hash-and-sign
 Say we have a secure signature scheme for “short”
messages (e.g., hashed RSA, DSS, …)
– How to extend it for longer messages?
 Hash and sign
– Hash message to short “digest”; sign the digest
 Used extensively in practice
M
H
H(M)
sk
Sign

Crypto pitfalls
Cryptography is not a “magic bullet”
 Crypto can be difficult to get right
– Must be implemented correctly
– Need expertise; “a little knowledge can be a dangerous
thing…”
– Must be integrated from the beginning
– Use only standardized algorithms and protocols
– No security through obscurity!
Cryptography is not a “magic bullet”
 Crypto alone cannot solve all security problems
– Key management; social engineering; insider attacks
– Develop (appropriate) threat/trust models
– Need to analyze weak links in the chain…
– Adversary may not be able to eavesdrop, but can it:
• Access your hard drive?
• See CRT emissions?
• Go through your trash?
– “Side channel attacks” on cryptosystems
Cryptography is not a “magic bullet”
 Human factors
– Crypto needs to be easy to use both for end-users and
administrators
– Important to educate users about appropriate security
practices
 Need for review, detection, and recovery
 Security as a process, not a product
Random number generation
 Do not use “standard” RNGs; use cryptographic
RNGs instead
 E.g., srand/rand in C:
– srand(seed) sets state=seed (|state| = 32 bits)
– rand():
• state = f(state), where f is some linear function
• return state
 Generating a 128-bit key using 4 calls to rand()
results in a key with only 32 bits of entropy!
More on random number generation
 Netscape v1.1:
– rv = SHA1(pid, ppid, time)
– return rv
 Problem: the input to SHA1 has low entropy