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 –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 signer’s 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 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 HSign M 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