Transcript
Page 1: David Evans cs.virginia/~evans

David Evanshttp://www.cs.virginia.edu/~evans

CS588: Security and PrivacyUniversity of VirginiaComputer Science

Lecture 14:Digital Cash, Randomness

Page 2: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 2

Menu

• Randomness

• Cannibalistic Voting Protocols

• Digital Cash

Page 3: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 3

Random Numbers

For numbers in range 0...2n-1, an observer with the first m - 1 numbers, cannot guess the mth with probability better than 1/2n.

Page 4: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 4

Good Random Numbers

• Lava Lamps (http://www.lavarnd.org)

• Gieger Counter and Radioactive stuff

Page 5: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 5

Pseudo-Random Number Generators

1. Start in a hard-to-guess state

2. Run an algorithm that generates an unpredictable sequence from that state

Page 6: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 6

Typical Random Numbers

• random ()– Doesn’t give cryptographic random numbers

• Using system clock in milliseconds to seed (even a good PRNG)– There are only 24*60*60*1000 = 86.4M

• Fine for video games, not fine for protecting nuclear secrets.

srandom (time (NULL));

for (...) random ();Doesn’t satisfy either property!

Page 7: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 7

Jefferson Wheel Key Generator

long key[NUMWHEELS]; int i, j;

srandom ((unsigned)time (NULL));

for (i = 0; i < NUMWHEELS; i++) key[i] = random ();

for (i = 0; i < NUMWHEELS; i++) {

long highest = -1;

int highindex = -1;

for (j = 0; j < NUMWHEELS; j++) {

if (key[j] > highest) { highindex = j; highest = key[j]; }

}

fprintf (stdout, "%d\n", highindex);

key[highindex] = -1;

}

Reduces key space from 36! (3.7 * 1041) to 86M!Challenge is now 2.3 * 1034 easier!

Page 8: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 8

Tiny, Yarrow-160• Accumulate Entropy

– Unspecified how: implementer decides• Recent Linux systems have /dev/random

– User keystrokes, disk seek times, network activity (be careful!), etc.

• Use entropy and SHA1 hash function produce unpredictable K.

• Calculate random numbers:

C = (C + 1) mod 2n

R = EK (C)• EK is AES (Tiny); 3DES (Yarrow-160)

Page 9: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 9

Jon Erdman

Page 10: David Evans cs.virginia/~evans

Erdman Sand Encryption

Or, Why I Don’t Need to Take the Midterm

Page 11: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 11

Problem

• Our survivors need to reveal their public keys without revealing who owns which key.

• All messages must be exchanged through a public forum (the sand).

Page 12: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 12

The solution

• Players encrypt their message with the public keys of two other players.

• Secretly pass the encrypted message at random through the group until the two encryptions are removed.

Page 13: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 13

Before we get started:

• Each pair of people needs to establish a secret key to communicate with each other.

• They could use the Diffie-Hellman key exchange or …

the Erdman Key Exchange

Page 14: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 14

Erdman Key Exchange

• Each player generates a RSA key pair.• Encrypt secret key using their private key

followed by player X’s public key.• Send encrypted message to player X by

writing it in the sand.• Decrypt using your private key and other

player’s public key.• Each player sends a key to every other player

using this method: the pair key is the xor of the keys the players sent to each other.

Page 15: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 15

Erdman Key Exchange (ctd.)

• Encrypting with your private key verifies to the other person that the message is coming from you.

• Encrypting with their public key verifies to you that only the other person can read the message.

• Can add check bits to the end to ensure message was not tampered with.

Page 16: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 16

Step 1: Encryption• Player generates a random bit string (which I’ll

call the messer) equal in length to the RSA keys.• Player does a RSA encryption on their public

key,KUx, xored with the messer.• Concatenate result with the messer and the

check bits (CB) corresponding to the word “final”.• Encrypt result using the public key (KU2y) of a

random player of their choosing. C1 = EKU2y[(M xor messer1) || messer1 || CB]

Page 17: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 17

Step 2: More Encryption

• Repeat step one using C1 instead of M, choosing a different person, different messer, and using the check bits for “middle.”

C2 = E KU2z[C1 xor messer2 || messer2 || CB]

Page 18: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 18

Step 3: Passing

• Each player does a 3DES encryption on the resulting messages and some check bits, using the unique key they made with yet another random player

• Write the result in the sand for all to see

C3 = 3DES (C2 || CB, Kxq)

Page 19: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 19

Step 4:Gathering

• Players need to find messages sent to them

• Decrypt the messages in the sand using the Kxy established earlier. If the check bits are valid they know the message was ment for them.

Page 20: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 20

Step 5: Decrypting (maybe)

• Players take messages sent to them and attempt to decrypt using their private key.

• If they see the check bits “middle” they know they have C1. If they see the check bits “final” they have one of the keys.

• If they have one of the keys, they can write it in the sand for all to see.

Page 21: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 21

Mathematical Interlude

• C = E KUz[M xor messer || messer || CB]

• attempt to decrypt using E KRz

D KRz[C] = D KRz[E KUz[M xor messer || messer || CB]] = M xor messer || messer || CB

• CB will only be valid if the decryption key is the pair to the encryption key.

• M = M xor messer xor messer

Page 22: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 22

Step 6: Repeat

• If the messages players received are not a final message, send it to another random player.

• Repeat until all keys have been found.

Page 23: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 23

Why the messer?• What if there is no messer?• The first person is being passed a message

encrypted with two public keys. • After final messages are revealed they can try

encrypting the messages with various public key combinations and find the one that produces the same message they got on the first pass.

• Only N choose 2 combinations!• The messer introduces a random factor into the

encryption so this will not be possible.

Page 24: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 24

Shortest Path Example

• A encrypts the message with the keys of C then B.

• A then passes to D• D who passes to B who takes of one lock• B passes to C who takes off other lock

• Each person knows who passed it to them and who they passed it to.

Page 25: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 25

Shortest Path (continued)

• Path: A -> D -> B -> C

• D does not know who B passed to so can not know the message C writes is A’s.

• B does not know that it was A that passed to D.

• C does not know the identity of D or A.

Page 26: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 26

Shortest Path (continued)

• Path: A -> D -> B -> C

• If D and B decide to share information they can figure out A’s message.

• This depends on the random passes being very lucky.

• Can improve the algorithm by adding more encryptions at the beginning.

Page 27: David Evans cs.virginia/~evans

Questions?

Page 28: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 28

Digital Cash

Page 29: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 29

Properties of Physical Cash• Universally recognized as valuable• Easy to transfer• Anonymous• Big and Heavy

– Average bank robbery takes $4552– 500 US bills / pound– Bill Gates net worth would be 400 tons in $100 bills

• Moderately difficult to counterfeit in small quantities

• Extremely difficult to get away with counterfeiting large quantities (unless you are Iran or Syria)

Page 30: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 30

Bank IOU Protocol

Alice{KUA, KRA}

Trusty Bank

{KUTB, KRTB}

M

M = “The Trusty Bank owes the holder of

this message $100.”

EKRTB[H(M)]

Page 31: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 31

Bank IOU Protocol

Alice{KUA, KRA}

Trusty Bank

{KUTB, KRTB}M EKRTB

[H(M)]

Bob

M EKRTB[H(M)]

Bob’s secret curry recipeEKUA[Bob’s secret curry recipe]

Page 32: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 32

Bank IOU Protocol

Trusty Bank

M EKRTB[H(M)]

Bob

M EKRTB[H(M)]

M EKRTB[H(M)]

Page 33: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 33

Bank IOU ProtocolUniversally recognized as valuableEasy to transferAnonymous

x Heavy

x Moderately difficult to counterfeit in small quantities

x Extremely difficult to get away with counterfeiting large quantities

Page 34: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 34

Bank Identifiers• Bank adds a unique tag to each IOU it

generates• When someone cashes an IOU, bank

checks that that IOU has not already been cashed

• Can’t tell if it was Alice or Bob who cheated

• Alice loses her anonymity – the bank can tell where she spends her money

Page 35: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 35

Digital Cash, Protocol #11. Alice prepares 100 money orders for

$1000 each.

2. Puts each one in a different sealed envelope, with a piece of carbon paper.

3. Gives envelopes to bank.

4. Bank opens 99 envelopes and checks they contain money order for $1000.

5. Bank signs the remaining envelope without opening it (signature goes through carbon paper).

Page 36: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 36

Digital Cash, Protocol #1 cont.

6. Bank returns envelope to Alice and deducts $1000 from her account.

7. Alice opens envelope, and spends the money order.

8. Merchant checks the Bank’s signature.

9. Merchant deposits money order.

10.Bank verifies its signature and credits Merchant’s account.

Page 37: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 37

Digital Cash, Protocol #1• Is it anonymous?

• Can Alice cheat?– Make one of the money orders for $100000, 1%

chance of picking right bill, 99% chance bank detects attempted fraud.

• Better make the penalty for this high (e.g., jail)

– Copy the signed money order and re-spend it.

• Can Merchant cheat?– Copy the signed money order and re-deposit it.

Page 38: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 38

Digital Cash, Protocol #2

• Idea: prevent double-spending by giving each money order a unique ID.

• Problem: how do we provide unique IDs without losing anonymity?

• Solution: let Alice generate the unique IDs, and keep them secret from bank.

Page 39: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 39

Digital Cash, Protocol #21. Alice prepares 100 money orders for

$1000 each, adds a long, unique random ID to each note.

2. Puts each one in a different sealed envelope, with a piece of carbon paper.

3. Gives envelopes to bank.

4. Bank opens 99 envelopes and checks they contain money order for $1000.

5. Bank signs the remaining envelope without opening it.

Page 40: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 40

Digital Cash, Protocol #2 cont.6. Bank returns envelope to Alice and

deducts $1000 from her account.7. Alice opens envelope, and spends the

money order.8. Merchant checks the Bank’s signature.9. Merchant deposits money order. 10.Bank verifies its signature, checks that the

unique random ID has not already been spent, credits Merchant’s account, and records the unique random ID.

Page 41: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 41

Digital Cash, Protocol #2

• Is it anonymous?

• Can Alice cheat?

• Can Merchant cheat?

• Can bank catch cheaters?

Page 42: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 42

Mimicking Carbon Paper

• How does bank sign the envelope without knowing what it contains?

• Normal signaturesAlice sends bank M

Bank sends Alice, SM = EKRBank (M)

Alice shows SM to Bob who decrypts with banks public key.

Page 43: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 43

Blind Signatures

• Alice picks random k between 1 and n.

• Sends bank t = mke mod n. (e from Bank’s public key).

• Bank signs t using private key d. Sends Alice:

td = (mke mod n)d mod n

= (mke)d mod n mdked mod n

= (mke)d mod n mdked mod n

What do we know about ked mod n?

Page 44: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 44

Blind Signatures

• Alice getstd mdk mod n

• Alice divides by k to getsm mdk / k md mod n.

• Hence: bank can sign money orders without opening them!

Page 45: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 45

Digital Cash Protocol #2

• Instead of envelopes, Alice blinds each money order using a different randomly selected ki.

• The bank asks for any 99 of the ki’s. The bank unblinds the messages (by dividing) and checks they are valid.

• The bank signs the other money order.

• Still haven’t solved the catching cheaters problem!

Page 46: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 46

Anonymity for Non-Cheaters

• Spend a bill once – maintain anonymity

• Spend a bill twice – lose anonymity

• Have we seen anything like this?

Page 47: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 47

Digital Cash1. Alice prepares n money orders each

containing:Amount Uniqueness String: X

Identity Strings: I1 = (h(I1L), h(I1R))

...

In = (h(InL), h(InR))

Each In pair reveals Alice’s identity (name, address, etc.). I = IiL IiR.

h is a secure, one-way hash function.

Page 48: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 48

Digital Cash, cont.

2. Alice blinds (multiplies by random k) all n money orders and sends them to bank.

3. Bank asks for any n-1 of the random kis and all its corresponding identity strings.

4. Bank checks money orders. If okay, signs the remaining blinded money order, and deducts amount from Alice’s account.

Page 49: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 49

Digital Cash, cont.5. Alice unblinds the signed note, and

spends it with a Merchant.6. Merchant asks Alice to randomly reveal

either IiL or IiR for each i. (Merchant chooses n-bit selector string.)

7. Alice sends Merchant corresponding IiL’s or IiR’s.

8. Merchant uses h to confirm Alice didn’t cheat.

Page 50: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 50

Digital Cash, cont.

9. Merchant takes money order and identity string halves to bank.

10.Bank verifies its signature, and checks uniqueness string. If it has not been previously deposited, bank credits Merchant and records uniqueness string and identity string halves.

Page 51: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 51

Digital Cash, cont.

11. If it has been previously deposited, bank looks up previous identity string halves. Finds one where both L and R halves are known, and calculates I. Arrests Alice.

12. If there are no i’s, where different halves are known, arrest Merchant.

Page 52: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 52

Digital Cash ProtocolUniversally recognized as valuableEasy to transferAnonymous

x HeavyModerately difficult to counterfeit in

small quantities

? Extremely difficult to get away with counterfeiting large quantities

Page 53: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 53

Digital Cash Summary• Preserves anonymity of non-cheating

spenders (assuming large bank and standard denominations)

• Doesn’t preserve anonymity of Merchants• Requires a trusted off-line bank• Expensive – lots of computation for one

transaction• Other schemes (Millicent, CyberCoin,

NetBill, etc.) proposed for smaller transactions

Page 54: David Evans cs.virginia/~evans

22 Oct 2001 University of Virginia CS 588 54

Charge

• Cryptographers can make infinite amounts of money! (but can’t make it heavy)

• Midterm is Wednesday– “Flood” Handout– You may discuss this with anyone you want, but

course staff will not answer specific questions about it.

• Review session: tonight at 7:00, Olsson 005