Lecture 1

Intro to Crypto and Cryptocurrencies

Welcome

special guest:
Joseph Bonneau Ed Felten Arvind Narayanan
Andrew Miller
This lecture
Crypto background
hash functions
digital signatures
… and applications
Intro to cryptocurrencies
basic digital cash
 Lecture 1.1:

Cryptographic Hash Functions

Hash function:
takes any string as input
fixed-size output (we’ll use 256 bits)
efficiently computable
Security properties:
collision-free
hiding
puzzle-friendly
Hash property 1: Collision-free
Nobody can find x and y such that
x != y and H(x)=H(y)

H(x) = H(y)

y
Collisions do exist ...

possible outputs
possible inputs

… but can anyone find them?

How to find a collision

try 2130 randomly chosen inputs

99.8% chance that two of them will collide

This works no matter what H is …

… but it takes too long to matter
Is there a faster way to find collisions?
For some possible H’s, yes.
For others, we don’t know of one.

No H has been proven collision-free.

Application: Hash as message digest
If we know H(x) = H(y),
it’s safe to assume that x = y.

To recognize a file that we saw before,

just remember its hash.

Useful because the hash is small.

Hash property 2: Hiding

We want something like this:

Given H(x), it is infeasible to find x.

H(“heads”)
easy to find x!

H(“tails”)
Hash property 2: Hiding
Hiding property:
If r is chosen from a probability distribution that has high
min-entropy, then given H(r | x), it is infeasible to find x.

High min-entropy means that the distribution is “very

spread out”, so that no particular value is chosen with
more than negligible probability.
Application: Commitment
Want to “seal a value in an envelope”, and
“open the envelope” later.

Commit to a value, reveal it later.

Commitment API
(com, key) := commit(msg)
match := verify(com, key, msg)

To seal msg in envelope:

(com, key) := commit(msg) -- then publish com
To open envelope:
publish key, msg
anyone can use verify() to check validity
Commitment API
(com, key) := commit(msg)
match := verify(com, key, msg)

Security properties:
Hiding: Given com, infeasible to find msg.
Binding: Infeasible to find msg != msg’ such that
verify(commit(msg), msg’) == true
Commitment API
commit(msg) := ( H(key | msg), H(key) )
where key is a random 256-bit value
verify(com, key, msg) := ( H(key | msg) == com )

Security properties:
Hiding: Given H(key | msg), infeasible to find msg.
Binding: Infeasible to find msg != msg’ such that
H(key | msg) == H(key | msg’)
Hash property 3: Puzzle-friendly
Puzzle-friendly:
For every possible output value y,
if k is chosen from a distribution with high min-entropy,
then it is infeasible to find x such that H(k | x) = y.
Application: Search puzzle
Given a “puzzle ID” id (from high min-entropy distrib.),
and a target set Y:
Try to find a “solution” x such that
H(id | x) ∈ Y.

Puzzle-friendly property implies that no solving strategy is

much better than trying random values of x.
SHA-256 hash function
Padding (10* | length)
512 bits
Message Message Message
(block 1) (block 2) (block n)

256 bits 256 bits

c c c
IV Hash

Theorem: If c is collision-free, then SHA-256 is collision-free.

 Lecture 1.2:

Hash Pointers and Data Structures

hash pointer is:
* pointer to where some info is stored, and
* (cryptographic) hash of the info

if we have a hash pointer, we can

* ask to get the info back, and
* verify that it hasn’t changed
 H( )
(data) will draw hash pointers like this
 key idea:

build data structures with hash pointers

linked list with hash pointers = “block chain”
H( )

prev: H( ) prev: H( ) prev: H( )

data data data

use case: tamper-evident log

 detecting tampering
H( )

prev: H( ) prev: H( ) prev: H( )

data data data

use case: tamper-evident log

binary tree with hash pointers = “Merkle tree”

H( ) H( )

H( ) H( ) H( ) H( )

H( ) H( ) H( ) H( ) H( ) H( ) H( ) H( )

(data) (data) (data) (data) (data) (data) (data) (data)

proving membership in a Merkle tree
show O(log n) items
H( ) H( )

H( ) H( )

H( ) H( )

(data)
Advantages of Merkle trees
Tree holds many items
but just need to remember the root hash
Can verify membership in O(log n) time/space

Variant: sorted Merkle tree

can verify non-membership in O(log n)
(show items before, after the missing one)
More generally ...

can use hash pointers in any pointer-based

data structure that has no cycles
 Lecture 1.3:

Digital Signatures
What we want from signatures

Only you can sign, but anyone can verify

Signature is tied to a particular document

can’t be cut-and-pasted to another doc
API for digital signatures

(sk, pk) := generateKeys(keysize)

sk: secret signing key can be
pk: public verification key
randomized
algorithms
sig := sign(sk, message)

isValid := verify(pk, message, sig)

Requirements for signatures

“valid signatures verify”

verify(pk, message, sign(sk, message)) == true

“can’t forge signatures”

adversary who:
knows pk
gets to see signatures on messages of his choice
can’t produce a verifiable signature on another message
 (sk, pk)

challenger attacker
m0

sign(sk, m0)

m1

sign(sk, m1)

...
M, sig

M not in { m0, m1, … }

verify(pk, M, sig)

if true, attacker wins

Practical stuff...

algorithms are randomized

need good source of randomness
limit on message size
fix: use Hash(message) rather than message
fun trick: sign a hash pointer
signature “covers” the whole structure
Bitcoin uses ECDSA standard
Elliptic Curve Digital Signature Algorithm

relies on hairy math

will skip the details here --- look it up if you care

good randomness is essential

foul this up in generateKeys() or sign() ?
probably leaked your private key
 Lecture 1.4:

Public Keys as Identities

Useful trick: public key == an identity

if you see sig such that verify(pk, msg, sig)==true,

think of it as
pk says, “[msg]”.

to “speak for” pk, you must know matching secret key sk

How to make a new identity

create a new, random key-pair (sk, pk)

pk is the public “name” you can use
[usually better to use Hash(pk)]
sk lets you “speak for” the identity

you control the identity, because only you know sk

if pk “looks random”, nobody needs to know who you are
Decentralized identity management

anybody can make a new identity at any time

make as many as you want!

no central point of coordination

These identities are called “addresses” in Bitcoin.

Privacy

Addresses not directly connected to real-world identity.

But observer can link together an address’s activity over

time, make inferences.

Later: a whole lecture on privacy in Bitcoin ...

 Lecture 1.5:

Simple Cryptocurrencies
GoofyCoin
Goofy can create new coins

New coins belong to me.

signed by pkGoofy
CreateCoin [uniqueCoinID]
A coin’s owner can spend it.

Alice owns it now.

signed by pkGoofy
Pay to pkAlice : H( )

signed by pkGoofy
CreateCoin [uniqueCoinID]
The recipient can pass on the coin again.

signed by pkAlice Bob owns it now.

Pay to pkBob : H( )

signed by pkGoofy
Pay to pkAlice : H( )

signed by pkGoofy
CreateCoin [uniqueCoinID]
 double-spending attack

signed by pkAlice signed by pkAlice

Pay to pkBob : H( ) Pay to pkChuck : H( )

signed by pkGoofy
Pay to pkAlice : H( )

signed by pkGoofy
CreateCoin [uniqueCoinID]
 double-spending attack

the main design challenge in digital currency

ScroogeCoin
Scrooge publishes a history of all transactions
(a block chain, signed by Scrooge)
H( )

prev: H( ) prev: H( ) prev: H( )

transID: 71 transID: 72 transID: 73

trans trans trans

optimization: put multiple transactions in the same block

CreateCoins transaction creates new coins

Valid, because I said so.

transID: 73 type:CreateCoins

coins created
num value recipient

0 3.2 0x... coinID 73(0)

1 1.4 0x... coinID 73(1)

2 7.1 0x... coinID 73(2)

PayCoins transaction consumes (and destroys) some coins,
and creates new coins of the same total value

transID: 73 type:PayCoins

consumed coinIDs:
68(1), 42(0), 72(3)
Valid if:
coins created -- consumed coins valid,
-- not already consumed,
num value recipient
-- total value out = total value in, and
0 3.2 0x... -- signed by owners of all consumed coins

1 1.4 0x...

2 7.1 0x...

signatures
Immutable coins

Coins can’t be transferred, subdivided, or combined.

But: you can get the same effect by using transactions

to subdivide: create new trans
consume your coin
pay out two new coins to yourself
Don’t worry, I’m honest.

Crucial question:

Can we descroogify the currency,

and operate without any central,
trusted party?