Model

Players

Alice and bob want to have a conversation
Eve can listen in, she can't alter messages
Mallory can modify messages, sub in his own messages replay messages etc.
E and M are computationally limited.

Goals of Cryptography (services provided)

Confidentiality/Privacy

Make sure E and M don't understand whats appearing on the channel.
only those authorized to read, can read
done by physical security and algorithms which make data unintelligible

Example

https, ssh, encrypting communication over a wire
write a word doc, don't want anyone else to read it, so encrypt it

Data Integrity

Messages sent between A&B appear in tact (vs M). A and B should know that a message has been modified.
Written data should not be altered. If it is, we should know about it.

Example

Write a doc on aug 12, 2004, read it on Oct 22, 2008. Can I be sure that it was not modified.

Authentication

Ensure that A knows that she is talking to B and vice versa
Difficult to define well
- Data: verification of the origin of the data
- Entity: verification of the identity of the entity
Multi Factor Authentication
- What you know: user id/password
- What you have:
- What you are:

Example

Log into a workstation

Non-Repudiation

Ensure that, if A says that she will meet B at 8:30 in Tim Hortons, she can't later say 'I did not say that'.
prevents an entity from denying previous commitments/actions

Example

Agree to pay $1000 for an HP6400 at Future Shop using my Master Card. How does Future Shop and Master Card ensure that I can't later say that I did not purchase the item?

Things that fall outside

Software registration
Digital rights managment

These are usually impossible to implement, mostly rely on security by obscurity (using secrecy of design/implementation to ensure security).

Questions

Which is more important for a bank account, secrecy or authentication

Other things we would like to do

Flip a coin in a distributed way or play black jack when A and B do not trust eachother.
Exchange information over an insecure, faulty channel in a secure way. (ie) At the end of the protocol A and B agree on X, but E and M don't know X.
Digital watermarking
Online auctions and Voting

Cryptosystems

Requirements for Cryptosystems

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. This is one of...

Kerckhoff principles

The system must be practically, if not mathematically, indecipherable;
It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience;
Its key must be communicable and retainable without the help of written notes, and changeable or modifiable at the will of the correspondents;
It must be applicable to telegraphic correspondence;
It must be portable, and its usage and function must not require the concourse of several people;
Finally, it is necessary, given the circumstances that command its application, that the system be easy to use, requiring neither mental strain nor the knowledge of a long series of rules to observe.

Parts of a Cryptosystem

Sigma: The alphabet (ie Sigma={a,b,c,...x,y,z, ,0,...,9} or Sigma={0,1}
M <= Sigma^*, the message space
C <= Sigma^*, the cyphertext space
K the keyspace
for each e in K, E_e(x):M->C, E_e(x) is a bijection (1-1, onto)
for each d in K, D_d(x):C->M, D_d(x) is a bijection (1-1, onto)
forall e in K, exists d in K such that D_d=E_e^-1, that is,
forall m in M D_d(E_e(m))=m

Picture of a cryptosystem

+-------------+ +---------------+ | | E (m) | | | | e | | | |------------------------>| | | M | | C | | Message |<------------------------| Cyphertext | | Space | D (c) | Space | | | d | | | hi bob | | kl ere | | | | | +-------------+ +---------------+ E (hi bob)=kl ere D (kl ere)=hi bob 3 -3

Question:Why use keys? Why not just a single pair of functions E and D such that forall m in M, D_d(E_e(m))=m?
Answer: In practise E and D get discovered. For example, when a person leaves the secure group.

Example Cryptosystems

Substitution Cypher

Define a map between letters 1 A -> Z 26 2 B -> X 25 3 C -> W 23 . . . 26 Z -> E 5 call this map k (the key). This map (essentially, the right side) is the key (K, the keyspace, is the set of all permutations of {1,...,26}). |K|=26!. We can write the above key as (ZXW...E) where we understand that A->Z, B->X, ... We naturally extend E_k to strings m in M by applying E_k to each letter of m. What is D? Actually it is the same function. For a given e in K, what is the inverse key d?

Caesar Cipher

This is a special case of the Substitution cypher.
Let D_k(x)=E_k(x)=[(x-'A')+k mod 26]+'A'.
Here we consider the keyspace K={0,...,25}.

Example

k=3 This is essentially a substitution cypher with the following permutation (DEFG..BC). So A->D, B->E, etc. E (HI BOB)----->KL ERE--------->D (KL ERE)=HI BOB 3 23 Alice --------+-----+---------- Bob | | | | | Mallory (malicious attacker) | Eve (eavesdropper) Question:Where did 23 come from?

Problem with this cypher: Eve simply trys all keys (just 26 of them) and looks for english. Eve discovers the key and the message.
Solution: Use a true substitution cypher. |K|=26! around 2⁸⁸ keys, not as easy to check all possible keys.

Problem with Substitution Cypher

It is vulnerable to frequency analysis.

One Time Pad: Provably perfect secrecy

First a few preliminaries: the XOR operation is defined by the following truth table...

XOR Truth Table

p q p XOR q --------------------- 1 1 0 1 0 1 0 1 1 0 0 0

Imagine Alice and Bob both have the same secret random sequence of bits r₀, r₁, ..., r_n-1 (the One Time Pad). Alice has a binary message m₀, m₁, ..., m_n-1 which she wants to securely (against Eve) send to Bob. Alice does the following:

One Time Pad

Alice computes s[i]=m[i] XOR r[i] and then sends the s[i] across the channel in order. m[2] m[1] m[0] ... XOR XOR XOR r[2] r[1] r[0] =s[2]-> =s[1]-> =s[0] -> Alice --------+------------------------- Bob | | | | Eve (eavesdropper) When Bob receives the s[i], he decripts by XORing s[i] with r[i]. Remember that Bob and Alice have the same secret One Time Pad (the key). That is, Bob computes s[i] XOR r[i]=((m[i] XOR r[i]) XOR r[i]) = m[i].

This is called a one time pad since perfect security can only be guaranteed for a single message sent with the key. Repeatedly using the same one time pad can allow Eve to decrypt the s[i] she sees flying across the channel.

One Time Pad is Secure

First we have to discuss what we mean by secure. We will say that a scheme is secure against Eve, if, when Bob and Alice are using this scheme, the sequence of bits Eve sees flying across the channel is indistinguishable from a random sequence of bits.

We argue below that, using the One Time Pad scheme, the sequence of bits flying across the channel is a random sequence of bits.

r[i] | 0 | 1 --+--------+-------- 0 | s[i]=0 | s[i]=1 m[i] --+--------+-------- 1 | s[i]=1 | s[i]=0 | | The events (s[i]=0 intersect m[i]=0) and (r[i]=0 intersect m[i]=0) are the same so Pr(s[i]=0|m[i]=0)=Pr(r[i]=0|m[i]=0). Now events r[i]=0 and m[i]=0 are independent, so Pr(r[i]=0|m[i]=0)=Pr(r[i]=0)=1/2. Putting these together we have Pr(s[i]=0|m[i]=0)=1/2 Similarly Pr(s[i]=1|m[i]=0)=1/2. So Pr(s[i]=0 intersect m[i]=0)=Pr(s[i]=1 intersect m[i]=0) (by definition of conditional probability). We will call this number x.

A similar argument establishes that Pr(s[i]=0 intersect m[i]=1)=Pr(s[i]=1 intersect m[i]=1). We call this number y.

Now Pr(s[i]=0)=Pr(s[i]=0 intersect m[i]=0)+Pr(s[i]=0 intersect m[i]=1) since these are mutually exclusive events. So Pr(s[i]=0)=x+y. Similarly Pr(s[i]=1)=x+y. So Pr(s[i]=0)=Pr(s[i]=1)=1/2. That is, the s[i] is a random stream of bits and the one time pad scheme is secure.

Using a Pseudo Random Number Generator

The obvious problem with a One Time Pad is communicating the key (the one time pad). Unfortunately, the key is as long as the message it is used to encrypt and it can only be used one time. One way to work around this is to use a pseudo random number generator. To use the pseudo random number generator, set its initial state by executing seed(r), for some number r called the random seed. Subsequent calls to nextRandomBit() results in a sequence of bits that 'appears' random. If we had such a function, then to generate the one time pad for use in the above scheme, Alice and Bob would only need to share the initial secret seed. Note: The sequence of bits nextRandomBit(), nextRandomBit(), ... is determined by the initial call to seed(r).

Imagine Alice and Bob both have the same secret number r (this is the key or the random seed). Alice has a binary message m₀, m₁, ..., m_n-1 which she wants to securely (against Eve) send to Bob. Alice does the following:

Alice executes seed(r) to initialize the random number generator. Alice computes s[i]=m[i] XOR nextRandomBit() and then sends the s[i] across the channel in order. =s[2]-> =s[1]-> =s[0] -> Alice --------+------------------------- Bob | | | | Eve (eavesdropper) To start Bobs side of the protocol, Bob executes seed(r) to initialize the pseudo random number generator on his side. Bob will now be generating the same sequence of pseudo random bits that Alice did. When Bob receives s[i], he decripts by XORing s[i] with nextRandomBit(). Remember that Bob and Alice have the same secret key (r). That is, Bob computes s[i] XOR nextRandomBit()= m[i].

Block Ciphers (DES, Blowfish, IDEA)

Data Encryption Standard (DES)

Also known as DES, DEA (A=Algorithm).
Symmetric key ('essentially' same key used to encrypt/decrypt)
Block Cypher
Uses 64 bit "key" = 56 bit key + 8 bits for error checking
DES(k,b)=b' where b and b' are 64 bits
The computation of DES(k,b) is complex, but each step is reversible so DES(K,x) is 1-1, onto function from {0,1}⁶⁴ to {0,1}⁶⁴.
DES can be used in many different ways... ECB (Electronic Code Book), CBC (Cypher Block Chaining)

ECB (Electronic Code Book)
Message M broken into 64 bit chunks m1 m2 m3 m4 m5 ... DES(k, ) applied to each block independently Vulnerable to frequency analysis for known language.

CBC (Cipher Block Chaining)
Message M broken into 64 bit chunks m1 m2 m3 m4 m5 ... DES(k, ) applied to each block XORed with the previous ciphertext.
RSA had a DES challenge, DES broken by parallel computation (trying all possible keys).
DES no longer considered secure enough, instead 3DES (Triple-DES) is used when it matters.
3DES Key=(k₁, k₂, k₃) (3 DES keys).
3DES(k,b)=DES(k₃,DES^-1(k₂,DES(k₁, b)))
3DES is again a 64bit block cipher.

Diffie Hellman Key Exchange

The above scheme (using a pseudo random number generator to generate a onetime pad) relies on a shared secret random seed (called r above). You might wonder how Alice and Bob can exchange such a secret in the presence of Eve. Of course, Alice could physically visit Bob to exchange the secret. It turns out that Alice and Bob can agree on a secret number using the insecure channel and that, under some cryptographic assumnptions, Eve will not know the secret. This is the Diffie Hellman Key Exchange, see this. Additional references: The DH Paper,

Preliminaries

The Diffie Hellman Key Exchange relies, in some sense, on the difficulty of the Discrete Log problem (in NP intersect coNP if formulated properly). See also: these lecture notes if you don't remember NP, coNP etc. Assume you know number g and large prime p. I have x in {1,...,p-1} If I give you g^x mod p can you find x? This problem (under certain assumptions about g,x and p) is believed to be computationally difficult to solve.

The protocol

Alice Bob choose g,p and send to Bob -------------------->g,p choose secret a send g^a mod p to Bob ------------------------->g^a mod p choose secret b g^b mod p<------------------------------------- send g^b mod p to Alice compute (g^b mod p)^a mod p =g^{ab} mod p compute (g^a mod p)^b mod p =g^{ab} mod p Both Alice and Bob have a shared secret. That is g^{ab} mod p. At the completion of the Diffie Hellman Key Exchange, Eve knows, g,p,g^a mod p, g^b mod p. It is believed to be computationally difficult to compute g^{ab} mod p from this information. Of course, if Eve could solve the Discrete Log problem, then Eve could compute g^{ab} mod p.

Exercise

Why does the following algorithm not effectvely solve the discrete log problem? // return a in {1,...,p-1} such that g^a mod p==z // return -1 if no such a exists integer solveDiscreteLog(g,p,z){ for(a=1;a<p;a++){ if(g^a mod p == z) return z; } return -1; } Hint, think of p being a 300 bit number.

Diffie Hellman Vulnerability

The Diffie Hellman Key Exchange is vulnerable to Mallory. That is, Mallory can run a Man in the Middle Attack. Mallory hijacks the channel, placing himself between Alice and Bob. A ----------------- M ---------------- B Mallory executes two Diffie Hellman Key Exchanges, one between Mallory and Alice and another between Mallory and Bob. At the end of this, Mallory and Alice share a secret key, Mallory and Bob share another secret key. Alice and Bob are none the wiser.

Exercise

Write up a detailed example of a man in the middle attack against the Diffie Hellman Key Exchange. Do this by writing down specific g1, p1 and running an exchange between Alice and Mallory. Similarly for g2 and p2, Mallory and Bob.

Additionally, see Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice

Using Cryptography

Confidentiality

Send encrypted messages across the wire. just decrypt m' and read. m->E (m)---------------------->m' D (m') e d Alice --------+-----+---------- Bob | | | | | Mallory (malicious attacker) | Eve (eavesdropper) Note: Keys must be secret! This is private key cryptography.

Data Integrity

Remember, we want to ensure that data has not changed since I stored it on disk. In terms of the Alica/Bob model, we want to defend against Mallory. The best we can do is to 'ensure' that, if Bob recieves a message, then Bob can determine that it was created with Alices encryption key and not subsequently altered.

Alice sends m as well as E_e(m) to Bob. Bob verifies that the message m1 recieved and the encrypted version m2 satisfy D_d(m2)=m1. If these match then Bob has confidence that the message recieved was encrypted using Alices private key e. Note: It is still possible for Mallory to resend a pair previously seen. This technique protects against Mallory manipulating the message m parts of a message.

m----------------------->m1 Check that m->E (m)---------------------->m2 D (m2)=m1 e d Alice --------+-----+---------- Bob | | | | | Mallory (malicious attacker) | Eve (eavesdropper) In what follows, we will see that instead of sending both m and E_e(m) we will send m and hash(m). Note: We will use a keyed hash function.

Hash Functions and their properties

You might ask, why does Alice need to send m as well as E_e(m)? That was just the setup for hash functions. A hash function is a one way function from larger finite strings to typically smaller, fixed length strings. To be a cryptographic hash function, there are a few properties we would like to have.

For an unkeyed hash function h, we would like to have

preimage resistance: given y, it is computationally difficult to find x such that h(x)=y.
2nd-preimage resistance: given x, it is computationally difficult to find x1 such that h(x)=h(x1).
collision resistence: it is computationally difficult to find x0 and x1 such that h(x0)=h(x1).

Example

f(b b b b b ... b )=b +b +b +b +b ... +b 1 2 3 4 5 n 1 2 3 4 5 n where + here is exclusive OR In this example, f maps arbitrary bit strings to a single bit {0,1}. Note: In this example, there are no keys.

Exercise: Which of the above 3 properties does this hash function violate (it is not a good choice for a cryptographic hash function).

Example

SHA1

Example

MD5 takes an arbitrary string and returns 128bits (usually written as 32 hex digits).

MD5 has been broken by using Rainbow tables (rainbow report). The idea: let MD5^k be MD5 run on itself, k times. So MD5³("this is something")= MD5(MD5(MD5("this is something"))). Create a table as follows... (intuition only, details are not necessarily correct, in fact reduce(MD5(x)) is computed in each round)...

To use this table, say I want to find a pre-image of y, do the following

let t=y while(t is not a target in the rainbow table){ t=MD5(t) } we now know a chain that y appears in assume t is in the row with seedp last=seedp y'=MD5(seedp) while(true){ if(y'==y){ return last } else { last=y' y'=MD5(y') } } Note: If I use a larger number (>10,000) then the rainbow table becomes smaller. Each row covers a potentially longer chain. The question is, how does one go about computing the table in the first place. This has already been done and has to be done only one time.

We have left out the issue of whether there actually is a cryptographically secure hash function. None has yet been proven secure (whatever that means).

Application of Hash functions to Data Integrity

Say I want to distribute software. I want to have a main distribution site as well as mirrors. I want to ensure to be able to ensure that downloaders of my software from mirrors will be confident that they have good, unmolested copies of my software. What do I do? I keep a MD5 hash of my file a the main distribution site. Those interested in the software can download it from any of the mirrors and verify their download by computing the MD5 hash of the download and comparing it with the MD5 fingerprint downloaded from the main site. file.zip file.zip.md5=MD5(file.zip) -----+ MAIN | | +----> file.zip.md5 check whether file.zip.md5=MD5(file.zip (from MIRROR4)) file.zip MIRROR1 +----------> file.zip (from MIRROR4) | | file.zip | MIRROR2 | | | file.zip | MIRROR3 | | | file.zip -----------------+ MIRROR4 Note: For this to work, we need 2nd preimage resistence. Why?

Data Integrity (continued)

We left off with the question of how Alice convinces Bob that the data has arrived in tact. Alice and Bob have a secret key k (salt possibly). Instead of using a simple hash function, they used a keyed hash function (for example MD5(salt+message)). To ensure data integrity, Alice sends Bob the pair (m,h(k,m)). Bob receives (m',h') and checks whether h(k,m')=h'. Note:This does not prevent Mallory from replaying a past message. It prevents Mallory from manipulating the message. m----------------------->m' h(k,m)---------------------->h' Bob now verifies h'=h(k,m') Alice --------+-----+---------- Bob has secret | | has secret key k key k | | | Mallory (malicious attacker) | Eve (eavesdropper)

In terms of MD5, Alice and Bob would have the same secret string (called salt). Alice would send m as well as MD5(salt+m) (+ is string concatenation). Bob receives m' and h' and checks whether MD5(salt+m')=h'.

Authentication

Alice wants to convince Bob that Alice is on the other end of the line. Alternatively, you want to login to your computer. First attempt: E ('Im Alice'))------------>m' Bob checks D (m')='Im Alice' e d Alice --------+-----+---------- Bob | | | | | Mallory (malicious attacker) | Eve (eavesdropper) While Bob is fairly certain that no one else could have encrypted the message 'Im Alice', Mallory could replay the authentication. An alternative...challenge/responce. Bob chooses a random number, sends it to Alice, Alice encrypts the random number and returns it. Each round gives Bob more confidence that the individual on the other end of the line is capable of encrypting using key e. Remember, Bob has key d and Alice has key e. choose a random number x1 send it to Alice <-------------------x1 encrypt and return E (x1) -------------------->m' Bob checksD (m')=x1 e d choose a random number x2 send it to Alice <-------------------x1 encrypt and return E (x2) -------------------->m'' Bob checksD (m'')=x2 e d . . . Alice --------+-----+---------- Bob | | | | | Mallory (malicious attacker) | Eve (eavesdropper)

Example

Authentication in unix and /etc/shadow, /etc/passwd

As you already know, /etc/passwd is world readable. Passwords are no longer stored there. They are instead hashed into /etc/shadow (root readable, not world readable). In many systems, they are hashed into /etc/shadow using MD5. In light of the preimage vulnerability (via Rainbow Tables), how can we use MD5?

When a users password is created, random salt (for this users password) is computed. MD5(salt+password) is computed and both the salt and MD5(salt+password) are stored in the /etc/shadow file. When a user attempts a logs in, their entry in /etc/shadow is fetched (if it exists). The random salt appears in that entry and this is added to the supplied password. This is compared with the entry in /etc/shadow and, if they match, the user is allowed to log in.

Below is a few lines taken from /etc/shadow. $1$ indicates that MD5 is used. For arnold the salt used is $1$BrsaVm9R$. The result of salting and MD5ing arnolds password is pAmsCoQfoijNt6H/DuRjF0. hacker's salt is $1$ufns7sR1$.

arnold:$1$BrsaVm9R$pAmsCoQfoijNt6H/DuRjF0:14178:0:99999:7::: hacker:$1$ufns7sR1$ryQ4O4JmtrPjzJ/X2eLp01:14178:0:99999:7:::

The following PHP script actually verifies arnold...given the password and the salt, it produces the above hash.

<?php echo crypt('stfftatvotse','$1$BrsaVm9R$'); ?>

In terms of Rainbow tables, this means that to crack a particular password (knowing the salt and MD5(salt+password)) you would actually need to create a rainbow table specifically for this one password. You could not use an existing rainbow table.

Exercise: How does adding salt prevent a hacker from authenticating even though they have stolen the /etc/shadow file?

Public Key Cryptography (RSA)

A special case of assymmetric key cryptography where knowing an encryption key does not allow one to derive the decryption key and vice versa. The security of RSA relies on the infeasibility of factoring large numbers.

Alice gets a public, private key pair (k_e, k_d). Knowing one does not easily lead to knowing the other. Alice publishes her public key k_e and keeps the private key securely hidden. k_e and k_d are inverses with respect to RSA, that is

RSA(k_d, RSA(k_e, m))= RSA(k_e, RSA(k_d, m))=m

RSA Details

Alice chooses two large primes, p,q and e relatively prime to (p-1)(q-1). Alice then finds natural number d such that ed =1 mod(p-1)(q-1).

Alice now has private key (p,q,d) and public key (pq,e)

Bob has message M (a natural number) and wants to send it encrypted to Alice. He does the following

Bob computes C=M^emod pq and sends C to Alice
Alice computes M=C^d mod pq

RSA is not known to be more secure than block ciphers. The difference here is that RSA is not symmetric AND it is difficult to find the private key given the public key and vice versa.

RSA calculations are time consuming. Typically RSA is used to exchange a session key (ie for 3DES).

An Introduction from Verisign

Digital Certificates (X.509)

An X.509 digital certificate is a way for Alice to publish her public key, such that everyone that reads the certificate 'knows' that it really is Alices public key. In order to make this happen, we need a trusted third party. Companies like entrust, verisign and thwate (see compare certificates) play this role. They have well known public keys and will verify your public key (that the public key is under your control). You can make up a public/ private key pair, then submit a Certificate Signing Request (CSR). They (the Certificate Authority (CA) then creates an x.509 digital certificate signed with the CAs private key.

Example: Decoding an X.509

The Entrust.netSecureServerCertificationAuthority digital certificate came pre-installed in my browser. I exported it and then decoded it using openssl. openssl x509 -in Entrust.netSecureServerCertificationAuthority -inform PEM -text -noout The result is this.

Chain of Trust

When I visit https://cs.utm.utoronto.ca my browser establishes a secure, trusted connection with the web server.

The web server sends its signed certificate (decoded).
My browser notices that this is signed by CA=UTN-USERFirst-Hardware
My browser has the digital certificate for CA=UTN-USERFirst-Hardware (decoded) pre-installed. Note: This certificate comes from a Certificate Authority (CA:TRUE), so this is a self signed certificate.
My browser de-crypts the signature at the bottom of the cs.utm.utoronto.ca certificate using the UTN-USERFirst-Hardware public key.
My browser verifies that this de-crypted signature is the SHA1 hash of the rest of the cs.utm.utoronto.ca certificate.
If this checks out, then my browser uses the cs.utm.utoronto.ca public key (see below) to establish a secure connection with cs.utm.utoronto.ca.

Chain of Trust (untrusted certificate)

If you use https to visit a web server with a digital certificate that is not signed by a known certificate authority, your browser alerts you and asks if you want to trust the certificate.

Committment Schemes

We provide intuition only. For a more formal presentation, you should see this.

Players

(unsecured channel) Prover --------+---------------- Verifier | | | | Eve (eavesdropper)

Prover claims to have made a choice X but wants it kept secret
Verifier wants to make sure that Prover does not change their mind later
Some computation and communication happens under the assumption that Prover made choice X.
At the end of the computation/communication, verifier wants to make sure that they have not been cheated. Verifier asks prover for proof that they did not change their initial choice.

Playing Blackjack Over the Web

The dealer shuffles cards (Prover), the verifier is dealt hands from the shuffled deck, playing blackjack. When they are done with the deck, the verifier wants to make sure that the prover did not change the order of the dealt cards during play.

A committment scheme typically works by having Prover commit to message m by first sending message c. Later Prover shows Verifier that c committed Prover to m, that is m really was previously chosen. Typically c and m have the following properties:

Hiding: c gives Verifier no information about m
Binding: Prover cannot open c in two different ways

Flipping a coin

Prover flips coin
Prover tells verifier I have flipped
Verifier chooses heads/tails and tells prover.
Prover tells verifier whether they have won or not

Flipping a coin with committment

Prover flips coin
Prover writes the flip on a piece of paper.
Prover tells verifier I have flipped
Prover sends the paper to the verifier
Verifier chooses heads/tails
Verifier tells prover of their choice
Prover tells verifier whether they have won or not
Verifier checks the paper

Problems! Committment, no hiding.

Flipping a coin with committment and hiding

Prover flips coin
Prover writes the flip on a piece of paper.
Prover places it in a locked box.
Prover tells verifier I have flipped
Prover sends the locked box.
Verifier chooses heads/tails
Verifier tells prover of their choice
Prover tells verifier whether they have won or not
Prover sends verifier the key to the locked box.
Verifier unlocks the box with the key
Verifier checks the paper

Committment + Hiding!

Flipping a coin with committment and hiding using hash function

Prover flips coin
Prover writes the flip on a piece of paper.
Prover computes BOX = hash(flip)
Prover tells verifier I have flipped
Prover sends BOX
Verifier chooses heads/tails
Verifier tells prover of their choice
Prover tells verifier whether they have won or not
Prover sends verifier the flip (the key)
Verifier computes hash(flip)
Verifier checks whether BOX = hash(flip)

Problems!!

Is there committment?
Is there hiding?
What are assumptions made about hash(x)

Flipping a coin with committment and hiding using hash function (fixed)

Prover flips coin
Prover writes the flip on a piece of paper.
Prover computes BOX = hash(flip)
Prover tells verifier I have flipped
Prover sends BOX
Verifier chooses heads/tails
Verifier tells prover of their choice
Prover tells verifier whether they have won or not
Prover sends verifier the flip (the key)
Verifier computes hash(flip)
Verifier checks whether BOX = hash(flip)

Better, but still!!! Need to think carefully about whether there really is committment and hiding, and the assumptions made about the 'magic' hash function.

Zero Knowledge Proofs

Lots of intuition here, not so much math!! More intuition The real paper

The Players

Players (unsecured channel) Prover --------+---------------- Verifier | | | | Eve (eavesdropper)

Prover wants to convince Verifier that they know something
Verifier wants is skeptical, wants real evidence
Prover does not want to give away what they know, either to Eve, or to Verifier
After execution of protocol, Verifier knows nothing other than whether Prover knows X.
Eve can't distinguish the conversation from a similar random conversation generated by Verifier. This is an interesting point!!! The essence to establishing zero knowledge.
There are some other assumptions about computational limitations of Prover and Verifier, later!

Example

Wheres waldo

Example

Graph 3-colorability

Prover randomly permutes colors
Show graph to verifier with shells over the colored nodes
Verifier chooses an edge
Prover shows both nodes on the edge
Verifier checks that both have different color
Repeat until verifier is satisfied

Note: If the prover does not have a 3-coloring of the graph, then Pr(Fool verifier for one round)<= (E-1)/E <1 Pr(Fool verifier for two rounds)<=((E-1)/E)^2 Pr(Fool verifier for k rounds)<=((E-1)/E)^k Now for z=(E-1)/E, the sequence z^k->0 as k-> infinity So say Verifier wants to be very certain that they were not fooled, for example, the Pr(Fooled verifier for k rounds)<=1000000000 then verifier runs protocol for k rounds such that ((E-1)/E)^k<1000000000 That is k*log((E-1)/E)<log(1000000000) k<log(1000000000)/log((E-1)/E) Question: How do we actually do this cryptographically? Answer: Use a comittment scheme

Example

Discrete Log

Tools/References