Cryptography Lecture 25 RSAbased PKE Recall Let p

Cryptography Lecture 25

RSA-based PKE

Recall… • Let p, q be random, equal-length primes • Compute modulus N=pq • Choose e, d such that e · d = 1 mod (N) • The eth root of x modulo N is [xd mod N] – I. e. , easy to compute given p, q (or d) • RSA assumption: given N, e only, it is hard to compute the eth root of a uniform c ℤN* 3

• This suggests a public-key encryption scheme!

“Plain” RSA encryption N, e c (N, e, d) RSAGen(1 n) pk = (N, e) sk = d m = [cd mod N] c = [me mod N]

Is this scheme secure?

Security? • This scheme is deterministic – Cannot be CPA-secure! • RSA assumption only refers to hardness of computing the eth root of a uniform c – c is not uniform unless m is – Why would m RSA be uniform? Plain should never be used! – Easy to compute eth root of c = [me mod N] when m is small • RSA assumption only refers to hardness of computing the eth root of c in its entirety – Partial information about the eth root may be leaked – (In fact, this is the case) 7

Chosen-ciphertext attacks • (Of course, plain RSA cannot be CCA-secure since it is not even CPA-secure… – …but chosen-ciphertext attacks are devastating here) • Given ciphertext c for unknown message m, can compute c’ = [ e c mod N] – What does this decrypt to?

How to fix plain RSA? • One approach: use a randomized encoding • I. e. , to encrypt m – First compute some reversible, randomized mapping M = E(m) – Then set c : = [Me mod N] • To decrypt c – Compute M : = [cd mod N] – Recover m from M

PKCS #1 v 1. 5 • Standard issued by RSA labs in 1993 • Idea: introduce random padding – E(m) = r|m • I. e. , to encrypt m – Choose random r – Compute the ciphertext c : = [ (r|m)e mod N] • Issues: – No proof of CPA-security (unless m is very short) – Chosen-plaintext attacks are known if r is too short – Chosen-ciphertext attacks possible 10

PKCS #1 v 2. 0 • Optimal asymmetric encryption padding (OAEP) applied to message first • This padding introduces redundancy, so that not every c ℤ*N is a valid ciphertext – Need to check for proper format upon decryption – Return error if not properly formatted 11

OAEP m | 0 … 0 r G H e c = s t mod N 12

Security? • RSA-OAEP can be proven CCA-secure under the RSA assumption, if G and H are modeled as random oracles • Widely used in practice… 13

RSA-based KEM • Idea: use plain RSA as before… …but on a random value! • Then use that random value to derive a key

RSA-based KEM • Encaps: – Choose uniform r ℤ*N – Ciphertext is c = [re mod N] – Key is k = H(r) • Decaps(c) – Compute r = [cd mod N] – Compute the shared key k = H(r)

Security? • This KEM can be proven CCA-secure under the RSA assumption, if H is modeled as a random oracle

Comparison to RSA-OAEP? • The RSA-KEM must be used with a symmetrickey encryption scheme • For very short messages (< 1500 bits), RSAOAEP will have shorter ciphertexts • For anything longer, ciphertexts will be the same length; RSA-KEM is simpler

Digital signatures

Digital signatures • Provide integrity in the public-key setting • Analogous to message authentication codes, but some key differences…

Digital signatures pk pk pk m, pk ? 1 = Vrfypk(m, ) pk, sk = Signsk(m)

Public-key encryption pk pk pk c pk pk, sk c Encpk(m) m = Decsk(c)

Security (informal) • Even after observing signatures on multiple messages, an attacker should be unable to forge a valid signature on a new message

Prototypical application pk patch’, ’ pk pk patch, pk, sk = Signsk(patch)

Comparison to MACs? t’ = Mack(patch’) k patch’, t’ patch, t k k k t = Mack(patch)

Comparison to MACs? k 1 patch, t 2 k 3 patch, t 3 k 1, k 2, k 3 t 1 = Mack 1(patch) t 2 = Mack 2(patch) t 3 = Mack 3(patch)

Comparison to MACs? • Public verifiability – “Anyone” can verify a signature – (Only a holder of the key can verify a MAC tag) Þ Transferability – Can forward a signature to someone else… Þ Non-repudiation

Non-repudiation • Signer cannot (easily) deny issuing a signature – Crucial for legal applications – Judge can verify signature using public copy of pk • MACs cannot provide this functionality! – Without access to the key, no way to verify a tag – Even if receiver gives key to judge, how can the judge verify that the key is correct? • Even if key is correct, receiver could have generated the tag also!