4. Map variable-length input to constant-length output.
HASH FUNCTIONS
h y
x
101011101011001…0010110100101 101110101001000110111100010101
5. Finding the pre-image of a given output is not easy.
HASH FUNCTIONS
h y
?
101011101011001…0010110100101 101110101001000110111100010101
6. Finding a colliding twin of a given input is not easy.
HASH FUNCTIONS
h y
x1
101011101011001…0010110100101
101110101001000110111100010101
x2
1100101001011001…110010100110
7. Finding any colliding pair of inputs is not easy.
It is of course possible, but not easy.
HASH FUNCTIONS
h y
x1
101011101011001…0010110100101
x2
1100101001011001…110010100110
101110101001000110111100010101
8. Minor input-mismatch to major output-mismatch.
HASH FUNCTIONS
h
y1
x1
101011101011001…0010110100101 101110101001000110111100010101
x2
101010101011001…0010110100101 y2 110010100101100100110010100110
11. Provably secure scheme for Commitment
Random nonce r must have a high min-entropy for this scheme to be secure.
APPLICATIONS
h y
x
r
commit(x) :
c = h(r || x)
verify(c,r,x) :
h(r || x) == c
12. Provably secure scheme for tamper-detection
APPLICATIONS
h y
x
record(x) :
c = h(x)
verify(c,x) :
h(x) == c
14. Tamper-evident linked data structure = Block
DATA STRUCTURES
h
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
15. Tamper-evident linked-list = Blockchain
DATA STRUCTURES
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
16. Tamper-evident linked-list = Blockchain
DATA STRUCTURES
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
Block
HP(block)
data
timestamp
17. Tamper-evident binary-tree = MerkleTree
DATA STRUCTURES
Node
HP(left)
data
timestamp
HP(right)
Node
HP(left)
data
timestamp
HP(right)
Node
HP(left)
data
timestamp
HP(right)
Node
HP(left)
data
timestamp
HP(right)
Node
HP(left)
data
timestamp
HP(right)
HP(root)
18. Tamper-evident binary-tree = MerkleTree
DATA STRUCTURES
Node
HP(left)
data
timestamp
HP(right)
Node
HP(left)
data
timestamp
HP(right)
Node
HP(left)
data
timestamp
HP(right)
Node
HP(left)
data
timestamp
HP(right)
Node
HP(left)
data
timestamp
HP(right)
HP(root)
19. DATA STRUCTURES
Properties Blockchain Merkle Tree Merkle Trie
Size of Commitment O(1) O(1) O(1)
Append a Block/Node O(1) O(log n) O(k)
Update a Block/Node O(n) O(log n) O(k)
Proof of Membership O(n) O(log n) O(k)
Structural Abstraction List of Objects Set of Objects Set of (key, value)
Used for Construction Bitcoin Bitcoin Ethereum
20. QUESTIONS
Can any pointer-based data structure
be efficiently converted into a
Hash-Pointer based data structure?
Will such an exercise be at all useful in any use case?
Do these structures provide any additional advantage?
22. Digital signature as a set of three algorithms
DIGITAL SIGNATURE
s = sign(sk,m) verify(pk,m,s)
pk
sk
?
keygen(n)
1
2 3
23. (sk, pk) = keygen(n) verify(pk,m,sign(sk,m)) = True
DIGITAL SIGNATURE
pk
sk
?
s = sign(sk,m) verify(pk,m,s)
keygen(n)
24. Given pk and access to sign(mi) as an oracle, an adversary should
not be able to create a valid fresh message-signature pair (m,s)
DIGITAL SIGNATURE
pk
sk
?
s = sign(sk,m) verify(pk,m,s)
keygen(n)
25. Elliptic Curve Digital Signature Algorithm (ECDSA)
ECDSA on curve E(Fp) : { (x,y) in Fp x Fp | y2 = x3 + 7 }
with base prime p = 2256 - 232 - 29 - 28 - 27 - 26 - 24 - 1
CONSTRUCTION
Fp
Q
26. Elliptic Curve group of size |E(Fp)| = q ~ p ~ 2256
ECDSA on curve E(Fp) : { (x,y) in Fp x Fp | y2 = x3 + 7 }
with base prime p = 2256 - 232 - 29 - 28 - 27 - 26 - 24 - 1
CONSTRUCTION
Parameters Format Range Bit-size
sk random Zq 256
pk sk x G E(Fp) 512
m hash(M) Zq 256
Signature (r, s) Zq x Zq 512
27. Publish the public key pk as your Identity
Use the secret key sk to prove your identity
APPLICATION
pk
sk
sk
verify(pk,m,sign(sk,m))
sk
?
63. Robin Yao (BW), Wang Chun (F2Pool), Marshall Long (FinalHash), Pan Zhibiao (Bitmain)
Liu Xiang Fu (Avalon), Sam Cole (KnCMiner) and Alex Petrov (BitFury)
73. BITCOIN
Transactions : Completely transparent and public
Identities : Opaque and pseudonymous addresses
~ 170 Million bitcoin addresses
~ 150 Million bitcoin transactions
~ 80 GB of compressed raw data
~ 80% of transactions have < 2 inputs
~ 90% of transactions have < 3 outputs
75. BITCOIN
Identities : Opaque and pseudonymous addresses
Anyone can create arbitrarily many identities
All identities “look” the same on the network
~ 170 Million bitcoin addresses
~ 150 Million bitcoin transactions
Provides “anonymity” of Bitcoin transactions.
81. BITCOIN
Identities : Opaque and pseudonymous addresses
Anyone can create arbitrarily many identities
All identities “look” the same on the network
~ 170 Million bitcoin addresses
~ 150 Million bitcoin transactions
Is it still possible to trace transactions and identities?
92. DE-ANONYMIZATION
Passive :Analytics on 80 GB of Bitcoin blockchain data
— Clustering of Bitcoin Addresses with suitable definition of Metrics
— Identification of the Clusters using known and/or leaked Addresses
Active : Injecting and tracking marked Bitcoin transactions
— Registering on Dark Marketplaces, Exchanges, and Mining Pools
— Using Addresses leaked from all these sources for Identification
Elliptic (https://www.elliptic.co/) does something similar in the UK.
We should try to build our own tool for de-anonymization.