1. Cryptography
Lecture 26

2. RSA-based PKE

3. Recall… (informal) Choose random, equal-length primes p, q
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] (xd)e = xde = x[ed mod (N)] = x mod N
RSA assumption: given N, e only, it is hard to compute the eth root of a uniform cℤN*

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

5. Is this scheme secure?

6. Plain RSA should never be used!
Security?
This scheme is deterministic
Cannot be CPA-secure!
RSA assumption only refers to hardness of computing the eth roots of uniform c
c is not uniform unless m is
Easy to recover “small” m from c
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)
Plain RSA should never be used!

7. PKCS #1 v1.5 Standard issued by RSA labs in 1993
Idea: add random padding
To encrypt m, choose random r
c = [ (r|m)e mod N]
Issues:
No proof of CPA-security (unless m is very short)
Chosen-plaintext attacks known if r is too short
Chosen-ciphertext attacks possible

8. PKCS #1 v2.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

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

10. 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…

11. Digital signatures

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

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

14. Public-key encryptionpk pk pk c pk
pk, sk
c  Encpk(m)
m = Decsk(c)

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

16. Prototypical applicationpk
patch’, ’
patch, 
pk, sk pk
 = Signsk(patch) pk

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

18. Comparison to MACs? patch, t1 k1 patch, t2 k1, k2, k3 patch, t3 k2
t1 = Mack1(patch)
t2 = Mack2(patch)
t3 = Mack3(patch) k3

19. Comparison to MACs? Public verifiability Transferability
“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

20. 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 leaks 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!