CMSC 414Computer 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

– Transferability

– Non-repudiation

Not obtainedby 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; 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

H SignM H(M)

sk

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