MATH/CMSC 456 :: UPDATED COURSE INFO

Instructor: Gorjan Alagic ([email protected]); ATL 3102, office hours: by appointment Textbook: Introduction to Modern Cryptography, Katz and Lindell;

Webpage: alagic.org/cmsc-456-cryptography-spring-2020/ (slides, reading posted here); Piazza: piazza.com/umd/spring2020/cmsc456 ELMS: active, slides and reading posted there, homework 2 due midnight Tonight. Gradescope: active, access through ELMS.

TAs (Our spot: shared open area across from AVW 4166) You can use AVW 4172 • Elijah Grubb ([email protected]) 11am-12pm TuTh (AVW); as a waiting room. • Justin Hontz ([email protected]) 1pm-2pm MW (AVW); Additional help: • Chen Bai ([email protected]) 3:30-5:30pm Tu (2115 ATL – inside JQI) • Bibhusa Rawal ([email protected]) 3:30-5:30pm Th (2115 ATL – inside JQI) RECAP: Merkle-Damgård transform

.Construction (Merkle-Damgård). 2푛 푛 Let 퐊퐞퐲퐆퐞퐧H, ℋ be a hash function, and suppose ℋ: 0,1 → 0,1 . Define a new hash function:

• 퐊퐞퐲퐆퐞퐧HMD: same as 퐊퐞퐲퐆퐞퐧H; ∗ 푛 • ℋMD: 0,1 → 0,1 defined as follows, on input 푥: 1. assume length |푥| of 푥 is divisible by 푛 (otherwise pad with 0s); 2. split 푥 as 푥 = (푥1, 푥2, … , 푥ℓ) and set 푥ℓ+1 ≔ |푥|. 푛 3. set 푧0 = 0 ; compute 푧푖 = ℋ(푥푖, 푧푖−1); 4. output 푧ℓ+1 .

푥1 푥2 푥3 푥ℓ+1

푛 퓗 퓗 퓗 … 퓗 ℋ 푥 0 푧 MD 푧0 푧1 2 푧ℓ 푧ℓ+1 RECAP: Merkle-Damgård transform

Remember: • critical property we needed for integrity checks… • … and for Hash-and-MAC… • … was collision-resistance!

What happens when we apply MD?

Theorem. If ℋ is a collision-free hash function, then so is its Merkle-Damgård transform ℋMD.

See book for proof. It’s fairly straightforward. RECAP: RANDOM ORACLES

Interesting: It seems like hash functions behave like random oracles! It’s as if someone sampled a uniformly random function 푹… … and then put it in an oracle!

1. Define 푹: 0,1 n → 0,1 푛 by setting 푹 푥 ← 0,1 푛 for each 푥. 2. Put 푹 “into a box” so everyone can query it, but only as an oracle. A strong hash function (like SHA-3) LOOKS LIKE is developed and standardized.

푥 푹 푹(푥) RECAP: RANDOM ORACLES ⇒ collision-resistant hashing

Random Oracle Model (ROM). 1. Define 푹: 0,1 n → 0,1 푛 What crypto can we build in this model? by setting 푹 푥 ← 0,1 푛 for each 푥. 2. Put 푹 “into a box” so everyone Collision-resistant hash: can query it, but only as an oracle. • recall: random functions are collision-resistant; • (because preimages are uniformly distributed) • so 푹 itself serves as a collision-resistant hash; 푥 푹 푹(푥) • if we want small outputs, can discard bits of output.

Note: • this is now statistical collision-resistance; • for normal hash functions, it was computational (i.e., against PPT adversaries.) • remember: collision-resistant ⇒ one-way. So we also get one-way functions! RECAP: RANDOM ORACLES ⇒ PRFs 푛 bits 푹 Random Oracle Model (ROM). 1. Define 푹: 0,1 n → 0,1 푛 What crypto can we build in this model? by setting 푹 푥 ← 0,1 푛 for each 푥. 2. Put 푹 “into a box” so everyone Pseudorandom functions: (0 ⋯ 00, 푘) can query it, but only as an oracle. • sample a key: 푘 ← 0,1 푛/2; • define 푛/2 푛/2 푭푘: 0,1 → 0,1 (0 ⋯ 01, 푘) 푥 푹 푹(푥) 푭푘 푥 ≔ 푹(푥, 푘) … Why is it pseudorandom? Note: 푨 knows 푹!

푭푘 1. take any algorithm 푨 . It makes some query 푥1; −푛/2 푛/2 2. Pr 푥1 = 푧, 푘 = 2 for any 푧; so response is uniformly random in 0,1 ; so 푭푘 is oracle indistinguishable 3. in particular, 푨푭푘 learned nothing with the first query. from a random function! 4. so we can repeat the argument starting from 1. RECAP: RANDOM ORACLES ⇒ lots of stuff

Random Oracle Model (ROM). What crypto can we build in this model? ROM

?

PRG PRF collision-resistant hash

IND-CPA unforgeable MAC encryption (fixed-length)

unforgeable MAC (arbitrary-length) RANDOM ORACLES ⇒ one-time authentication IMPORTANT! Lamport scheme. One-time MAC for messages of length ℓ. NEW IDEAS! Let 푹: 0,1 푛 → 0,1 푛 be a random oracle.

KeyGen: ퟎ 푥0 푥0 푥0 … 푥0 I. Sample 2ℓ random inputs to 푹: 1 2 3 ℓ 0 0 0 0 1 1 1 1 • 푥1 , 푥2 , 푥3 , … , 푥ℓ . ퟏ 푥1 푥2 푥3 … 푥ℓ 1 1 1 1 • 푥1 , 푥2, 푥3, … , 푥ℓ . 푏 푛 Note each 푥푗 ∈ 0,1 .

II. Now compute, for each 푗, 푏: 푹 푏 푏 푦푗 ≔ 푹 푥푗 ;

III. Output key consisting of two parts: 0 0 0 0 0 0 0 0 1 1 1 1 ퟎ 푦1 푦2 푦3 … 푦ℓ 1. 푥1 , 푥2 , 푥3 , … , 푥ℓ and 푥1 , 푥2, 푥3, … , 푥ℓ ; 푦0, 푦0, 푦0, … , 푦0 푦1, 푦1, 푦1, … , 푦1 1 1 1 1 2. 1 2 3 ℓ and 1 2 3 ℓ ; ퟏ 푦1 푦2 푦3 … 푦ℓ RANDOM ORACLES ⇒ one-time authentication

Lamport scheme. One-time MAC for messages of length ℓ. Key Let 푹: 0,1 푛 → 0,1 푛 be a random oracle. 0 0 0 0 ퟎ 푥1 푥2 푥3 … 푥ℓ Mac: 1 1 1 1 ퟏ 푥1 푥2 푥3 … 푥ℓ On input a message 푚 ∈ 0,1 ℓ: Output tag 푡 ∈ 0,1 푛ℓ like this: For each bit position 푗 = 1, 2, … , ℓ 푚푗 푹 output 푥푗 . Example: Suppose 푚 = 010110. 0 0 0 0 0 0 ퟎ 푦0 푦0 푦0 … 푦0 푥1 푥2 푥3 푥4 푥5 푥6 1 2 3 ℓ 1 1 1 1 1 1 ퟏ 푦1 푦1 푦1 … 푦1 푥1 푥2 푥3 푥4 푥5 푥6 1 2 3 ℓ

0 1 0 1 1 0 So tag is (푥1 , 푥2, 푥3 , 푥4, 푥5, 푥6 ). RANDOM ORACLES ⇒ one-time authentication

Lamport scheme. One-time MAC for messages of length ℓ. Key Let 푹: 0,1 푛 → 0,1 푛 be a random oracle. 0 0 0 0 ퟎ 푥1 푥2 푥3 … 푥ℓ Ver: 1 1 1 1 ퟏ 푥1 푥2 푥3 … 푥ℓ ℓ On input 푚 ∈ 0,1 and tag (푡1, 푡2, … , 푡ℓ): For each bit position 푗 = 1, 2, … , ℓ: 푚푗 If 푅 푡푗 ≠ 푦푗 output reject; output accept. 푹

Example: Suppose 푚 = 010110. Honestly generated 0 0 0 0 0 0 0 0 0 푡1 푥2 푡3 푥4 푥5 푡6 푥1 푥2 푥3 푥4 푥5 푥6 0 0 0 0 ퟎ 푦1 푦2 푦3 … 푦 1 1 1 1 1 1 1 1 1 ℓ 푥1 푡2 푥3 푡4 푡5 푥6 푥1 푥2 푥3 푥4 푥5 푥6 ퟏ 푦1 푦1 푦1 … 푦1 푹 ? 푹 1 2 3 ℓ

0 0 0 0 0 0 0 0 0 0 0 0 푦1 푥2 푦3 푥4 푥5 푦6 푦1 푥2 푦3 푥4 푥5 푦6 1 1 1 1 1 1 1 1 1 1 1 1 푥1 푦2 푥3 푦4 푦5 푥6 푥1 푦2 푥3 푦4 푦5 푥6 RANDOM ORACLES ⇒ one-time authentication

Lamport scheme. One-time MAC for messages of length ℓ. Key Let 푹: 0,1 푛 → 0,1 푛 be a random oracle. 0 0 0 0 ퟎ 푥1 푥2 푥3 … 푥ℓ Check correctness: 1 1 1 1 ퟏ 푥1 푥2 푥3 … 푥ℓ • for message 푚 ∈ 0,1 ℓ …

푚1 푚2 푚3 푚ℓ • … tag is 푥1 , 푥2 , 푥3 , … , 푥ℓ ; • at the verification stage, we do this check for each 푗: 푹 푚푗 푚푗 푹 푥푗 = 푦푗 푏 • but in KeyGen this is exactly how we defined 푦푗 for 푏 ∈ {0,1}. • so verification succeeds. 0 0 0 0 ퟎ 푦1 푦2 푦3 … 푦ℓ 1 1 1 1 ퟏ 푦1 푦2 푦3 … 푦ℓ So scheme is correct. Is it unforgeable? RANDOM ORACLES ⇒ one-time authentication

Lamport scheme. One-time MAC for messages of length ℓ. Key Let 푹: 0,1 푛 → 0,1 푛 be a random oracle. 0 0 0 0 So scheme is correct. Is it unforgeable? ퟎ 푥1 푥2 푥3 … 푥ℓ Let’s look at the adversary’s view. It has two things: 1 1 1 1 ퟏ 푥1 푥2 푥3 … 푥ℓ 푚 = 푚0푚1푚2 … 푚ℓ

0 0 0 0 0 0 푥1 푥2 푥3 푥4 푥5 푥6 푡 = 1 1 1 1 1 1 푹 푥1 푥2 푥3 푥4 푥5 푥6

Now adversary tries to forge on 푚∗ ≠ 푚. There’s a bit 푗 where 푚∗ differs from 푚. Say 푗 = 2. Then… ∗ ∗ 0 0 0 0 푚 = 푚0푚1푚2 … 푚ℓ ퟎ 푦1 푦2 푦3 … 푦ℓ ퟎ 0 0 0 But0 풙0ퟐ is 0random ퟏ 푦1 푦1 푦1 … 1 푥1 푥2 푥3 푥4 푥5 푥6 1 2 3 푦ℓ 푡∗ = and unknown. 1 1 1 1 1 1 푥1 푥2 푥3 푥4 푥5 푥6 RANDOM ORACLES ⇒ one-time authentication

Lamport scheme. One-time MAC for messages of length ℓ. Key Let 푹: 0,1 푛 → 0,1 푛 be a random oracle. 0 0 0 0 So Lamport is a one-time MAC. So what? ퟎ 푥1 푥2 푥3 … 푥ℓ Look at verification again: 1 1 1 1 ퟏ 푥1 푥2 푥3 … 푥ℓ Ver: ℓ On input 푚 ∈ 0,1 and tag (푡1, 푡2, … , 푡ℓ): For each bit position 푗 = 1, 2, … , ℓ: 푚푗 푹 If 푅 푡푗 ≠ 푦푗 output reject; output accept.

0 0 0 0 푏 ퟎ 푦1 푦2 푦3 … 푦ℓ It only requires knowledge of the 푦푗 ! 1 1 1 1 ퟏ 푦1 푦2 푦3 … 푦ℓ RANDOM ORACLES ⇒ one-time authentication

Lamport scheme. One-time MAC for messages of length ℓ. Mac Key Let 푹: 0,1 푛 → 0,1 푛 be a random oracle. for tag 0 0 0 0 So Lamport is a one-time MAC. So what? generation ퟎ 푥1 푥2 푥3 … 푥ℓ Look at verification again: 1 1 1 1 ퟏ 푥1 푥2 푥3 … 푥ℓ Ver: ℓ On input 푚 ∈ 0,1 and tag (푡1, 푡2, … , 푡_ℓ): For each bit position 푗 = 1, 2, … , ℓ: 푚푗 푹 If 푅 푡푗 ≠ 푦푗 output reject; output accept. Ver Key

0 0 0 0 푏 for tag ퟎ 푦1 푦2 푦3 … 푦ℓ It only requires knowledge of the 푦푗 ! verification 1 1 1 1 ퟏ 푦1 푦2 푦3 … 푦ℓ So can split key into a Mac key, and a Ver key. RANDOM ORACLES ⇒ one-time authentication

Lamport scheme. One-time MAC for messages of length ℓ. Mac Key Let 푹: 0,1 푛 → 0,1 푛 be a random oracle. for tag 0 0 0 0 So Lamport is a one-time MAC… generation ퟎ 푥1 푥2 푥3 … 푥ℓ With a separate Mac key, and a Ver key. 1 1 1 1 ퟏ 푥1 푥2 푥3 … 푥ℓ So what?

푏 Security only rested on unknowability of the 푥푗 . 푹 So only the Mac Key needs to be kept secret! Ver Key

In other words, we can make Ver Key public! 0 0 0 0 for tag ퟎ 푦1 푦2 푦3 … 푦ℓ verification ퟏ 푦1 푦1 푦1 … 푦1 (Mac Key stays secure because 푹 is one-way.) 1 2 3 ℓ DIGITAL SIGNATURES

Old setting: one key, shared privately.

Alice Bob 푘 (푚, 푡) 푘

PUBLIC-KEY New setting: private signing key, public verification key. CRYPTOGRAPHY!

Alice 푣푘 푠푘 (푚, 푡) • only Alice can sign • anyone can verify LAMPORT SIGNATURE SCHEME

New setting: private signing key, public verification key.

Alice PUBLIC 푥0 푥0 푥0 0 1 2 3 … 푥ℓ 푹 1 1 1 1 푥1 푥2 푥3 … 푥ℓ

푹

0 0 0 0 푦1 푦2 푦3 … 푦ℓ 1 1 1 1 푦1 푦2 푦3 … 푦ℓ LAMPORT SIGNATURE SCHEME

New setting: private signing key, public verification key.

Alice PUBLIC 푥0 푥0 푥0 0 1 2 3 … 푥ℓ 푹 1 1 1 1 푥1 푥2 푥3 … 푥ℓ by one-way property of 푹

0 0 0 0 푦1 푦2 푦3 … 푦ℓ 1 1 1 1 푦1 푦2 푦3 … 푦ℓ LAMPORT SIGNATURE SCHEME

New setting: private signing key, public verification key.

Alice PUBLIC 푥0 푥0 푥0 … 푥0 푦0 푦0 푦0 0 1 2 3 ℓ 1 2 3 … 푦ℓ 푹 푥1 푥1 푥1 … 1 1 1 1 1 1 2 3 푥ℓ 푦1 푦2 푦3 … 푦ℓ 푚 = 0 1 0 … 1 ∈ 0,1 ℓ

0 0 0 0 푥1 푥2 푥3 … 푥ℓ 1 1 1 1 푥1 푥2 푥3 … 푥ℓ LAMPORT SIGNATURE SCHEME

New setting: private signing key, public verification key.

Alice PUBLIC 푥0 푥0 푥0 … 푥0 푦0 푦0 푦0 0 1 2 3 ℓ 1 2 3 … 푦ℓ 푹 푥1 푥1 푥1 … 1 1 1 1 1 1 2 3 푥ℓ 푦1 푦2 푦3 … 푦ℓ 푚 = 0 1 0 … 1 ∈ 0,1 ℓ

0 0 0 0 푥1 푥2 푥3 … 푥ℓ 1 1 1 1 푥1 푥2 푥3 … 푥ℓ LAMPORT SIGNATURE SCHEME

New setting: private signing key, public verification key.

Alice PUBLIC 푥0 푥0 푥0 … 푥0 푦0 푦0 푦0 0 1 2 3 ℓ 1 2 3 … 푦ℓ 푹 푥1 푥1 푥1 … 1 1 1 1 1 1 2 3 푥ℓ 푦1 푦2 푦3 … 푦ℓ

verification: check that 푹 푚 = 0 1 0 … 1 ∈ 0,1 ℓ

0 0 0 0 푥1 푥2 푥3 … 푥ℓ 1 1 1 1 푥1 푥2 푥3 … 푥ℓ

digital signature of document 푚 LAMPORT SIGNATURE SCHEME

Is it unforgeable? Let’s look at the adversary’s view. It has three things: 푚 = 푚0푚1푚2 … 푚ℓ

0 0 0 0 0 0 0 0 0 0 푥1 푥2 푥3 푥4 푥5 푥6 푦1 푦2 푦3 … 푦ℓ 푡 = 1 1 1 1 1 1 1 1 1 1 푥1 푥2 푥3 푥4 푥5 푥6 푦1 푦2 푦3 … 푦ℓ

∗ Now adversary tries to forge on 푚 ≠ 푚. an inversion occurred here! There’s a bit 푗 where 푚∗ differs from 푚. Say 푗 = 2. Then…

∗ ∗ 푚 = 푚0푚1푚2 … 푚ℓ

0 0 0 0 0 0 To do a formal proof: 푥1 푥2 푥3 푥4 푥5 푥6 푡∗ = • build an algorithm for inverting 푹… 1 1 1 1 1 1 • … which internally simulates 1-EUF-CMA 푥1 푥2 푥3 푥4 푥5 푥6 • … with the Lamport scheme. The inversion will be at any bit where the query and the forgery differ. DIGITAL SIGNATURES

Definition. A digital signature scheme is a triple of PPT algorithms:

• (key generation) 퐊퐞퐲퐆퐞퐧: on input 1푛, outputs a secret key 푠푘 and a public key 푣푘; ∗ • (tag generation) 퐒퐢퐠퐧: on input a secret key 푠푘 and message 푚 ∈ 0,1 , outputs signature 퐒퐢퐠퐧푠푘(푚); • (verification) 퐕퐞퐫: on input a public key 푣푘 and a message-signature pair (푚, 푠), outputs ퟏ or ퟎ.

satisfying correctness: for all s푘, 푣푘 ← 퐊퐞퐲퐆퐞퐧 and all 푚, 퐕퐞퐫푣푘 푚, 퐒퐢퐠퐧푠푘(푚) = ퟏ.

Compare to MACs:

Definition. A message authentication code (MAC) is a triple of PPT algorithms:

• (key generation) 퐊퐞퐲퐆퐞퐧: on input 1푛, outputs a key 푘 ∈ 0,1 푛; ∗ • (tag generation) 퐌퐚퐜: on input a key 푘 and message 푚 ∈ 0,1 , outputs a tag 퐌퐚퐜푘(푚); • (verification) 퐕퐞퐫: on input a key 푘 and a message-tag pair (푚, 푡), outputs ퟏ or ퟎ;

satisfying correctness: for all 푘 and all 푚, 퐕퐞퐫푘 푚, 퐌퐚퐜푘 푚 = 1. PUBLIC-KEY CRYPTOGRAPHY (a teaser) SO FAR… Eve Alice Bob 푘 푘 Until we saw Lamport…

• all schemes used shared secret keys; • this comes with a problem: how do you share the secret safely? • you can’t use crypto…

• … so you’re left with some physical method • … and if that’s intercepted (or searched without you knowing), all your crypto is pointless. SO FAR… Eve Alice Bob 푘 푘 There’s other problems with secret keys…

Like symmetry!

Consider authentication: • with a MAC, generating tags and verifying tags are coupled together; • if Alice shares a key with Bob… • … she doesn’t just grant Bob the ability to verify the authenticity of her messages; • … she also grants him the ability to authenticate them with her key!

So, to a third party, Bob could pretend to be Alice! How do we solve that problem?

(By the way, this is also why secret-key crypto is sometimes called symmetric-key crypto.) COMMUNICATION OVER PUBLIC CHANNELS? Alice Maybe the problem is just unavoidable?

At first… • it might seem like this is just how things are… Bob • after all, if you and another party don’t share a secret… • … how can you possibly communicate securely?

Lamport is certainly interesting, but it’s one time, and only a signature scheme.

• what about encryption? • and what about the key sharing problem? • are these problems even solvable? COMMUNICATION OVER PUBLIC CHANNELS?

If you think this sounds impossible… … you’re in good company! (you could be a professor at Berkeley!)

In 1974, an undergrad named Ralph Merkle took a security course at UC Berkeley. For the course project, he proposed the following: COMMUNICATION OVER PUBLIC CHANNELS?

If you think this sounds impossible… … you’re in good company! (you could be a professor at Berkeley!)

In 1974, an undergrad named Ralph Merkle took a security course at UC Berkeley. • for the course project, he proposed this exact problem; • the prof told him to pick a different project… • … so Merkle dropped the course, but continued working on his idea.

He eventually came up with something called “Merkle puzzles.” • it allowed two honest parties to share a secret over public channels in 푛 timesteps… • but any adversary who wanted to find the secret had to spend 푛2 timesteps.

He wrote a paper, but it was rejected. The expert review said: “Experience shows that it is extremely dangerous to transmit key information in the clear.” COMMUNICATION OVER PUBLIC CHANNELS?

A few years earlier...

In 1969, cryptographers in GCHQ (British NSA) discovered a protocol for public-key crypto! (This was not known to the public until 1997.)

In the public world...

• two years after Merkle’s discovery… • in 1976, Whitfield Diffie and Martin Hellman discovered a key-exchange protocol. • What does Diffie-Hellman key exchange do? Something magical! KEY EXCHANGE

Diffie-Hellman key-exchange. What does Diffie-Hellman key exchange do? Something magical! • two parties are separated by an insecure channel (just like in encryption); • but they do not share any secret information! • and yet, after sending a few (insecure) messages in the open… • they suddenly share a secret key! • WHAT?

Alice Bob 풌 풌 KEY EXCHANGE → SECRET-KEY CRYPTO

What then? • after key exchange is performed… • … we are now in the setting we assumed for: 1. secret-key encryption 2. message authentication

So: we can then use all the tools we learned about so far!

Alice Bob 풌 풌 ASYMMETRIC CRYPTO

Is there another way? Alice 푣푘 푠푘 Recall how Lamport worked. (푚, 푡) • no key exchange required; • one private key, one public key; • asymmetric roles: private key enables signing, public key enables verification. This can be extended to digital signatures for any number of messages!

What about encryption? • can there be an asymmetric encryption scheme too? • what’s the right asymmetry? • public key encrypts; private key decrypts. ASYMMETRIC CRYPTO

Public-key encryption

Alice 푑푘 푒푘 ASYMMETRIC CRYPTO

Public-key encryption

Alice 푒푘 푑푘

Bob

푚 푒푘

푚 ASYMMETRIC CRYPTO

Public-key encryption

For two-way communication, Bob can do the same thing Alice did.

Alice 푒푘 푑푘

Bob

푑푘 푚 푚 푒푘

푚 PUBLIC-KEY CRYPTOGRAPHY

Clearly… … public-key crypto is awesome!

How do we get there? • we don’t know how to build it out of “generic things”… • … like PRGs or PRFs. • we need specific computational assumptions… • … and these assumptions require some math.

Specifically, some number theory. So some work will be involved, but it will be very worthwhile! THE PLAN

Clearly… … public-key crypto is awesome!

How do we get there? • we don’t know how to build it out of “generic things”… • … like PRGs or PRFs. • we need specific computational assumptions… • … and these assumptions require some math.

Specifically, some elementary number theory! So some work will be involved, but it will be very worthwhile! THE PLAN

Next 6 weeks:

Topic Dates

Intro and symmetric-key cryptography (8 lectures) January 28 – February 20

RSA and Diffie-Hellman (4 lectures + 1 hwk) Carl Miller February 25 – March 5

Secret sharing (2 lectures + 1 hwk) Bill Gasarch March 10 - 12

Fun guest lecture March 24

Midterm review March 26 Midterm March 31 Fun guest lecture (blockchain, likely) April 2

I’m back. April 7 - end