-
Notifications
You must be signed in to change notification settings - Fork 32
/
Week 6 : Bitcoin and Anonymity
620 lines (509 loc) · 31.8 KB
/
Week 6 : Bitcoin and Anonymity
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
----------------------------------------------------------------------------------------------------------------------------------------
6.1 Anonymity Basics
----------------------------------------------------------------------------------------------------------------------------------------
-> Anonymous = without a name.
-> Bitcoin addresses are public key hashes rather than real identities.
-> computer scientist call this "pseudonymity".
* Anonymity in computer science
---------------------------------
-> Anonymity = pseudonymity + unlinkability;
-> unlinkability - Different interactions of the same user with the system should not be linked with each other.
Pseudonymity vs anonymity in forums
------------------------------------
-> Reddit - pick a long-term pseudonym. (Pseudonymity)
-> 4Chan - make posts with no attribution at all. (Anonymity)
# With Pseudonomity profile -> easy to link back together to your real identity.
* Why is unlinkability needed?
------------------------------
1. Many Bitcoin services require real identity.
2. Linked profiles can be deanonymized by a variety of side channels.
* Defining unlinkability in Bitcoin
--------------------------------------
-> Hard to link different address to same users.
-> Hard to link different transactions of the same user.
-> Harder to link sender of a payment to its recipient.
* Quantifying anonymity
------------------------
-> Complete unlinkability (among "all" addresses/transactions) is hard.
-> Anonymity set : measurement parameter - the set of all transactions that are hidden. The crowd that one attempts to blend into.
-> To calculate anonymity set:
- define adversary model.
- reason carefully about: what the adversary knows, doesn't know, and cannot know.
* Why anonymous cryptocurrencies?
------------------------------------
-> Block chain based currencies are totally publicly, and permanently traceable.
-> Without anonymity, privacy is much worse than traditional banking!
* What about money laundering?
-------------------------------
-> Legitimate worry.
-> Bottleneck: moving large flows into and out of Bitcoin ("cashing out") - hard. (BTC -> money ($))
* Anonymous e-cash : history
------------------------------
- David Chaum, 1982
- Blind signatures - Two-party protocol to create digital signature without signer knowing the input.
# Consider a Bank with a protocol for Anonymous e-cash through blind signatures
--------------------------------------------------------------------------------
1. Consider there is a Bank and it stores various things in its database. It stores two tables.
-> Table 1 : Mapping between usera and their account balance.
-> Table 2 : Spent coins.
2. Suppose a user wants to withdraw an anonymous coins from the system.
- User wishes to withdraw an anonymous coin of standard denomination.
3. In response to the User's request the bank is gonna deduct the amount required my the user in the "Spent coins" table.
4. Then the bank and the user are gonna execute a "two party" protocol. (Blind) signature protocol.
- The user picks a random serial number of a coin.
- At the end the user receives a signature of the serial number, but the banks is unaware of the users's serial number.
- This signed number represents an anonymous token.
5. In can the current user wants to make payment to another user, then current user sends to the next user the "signed token" and the "plain text value of the token/serial number".
6. The receiving user will immediately contact the bank and try to deposit the anonymous coin. (Inorder to verify - no double spends, etc)
8. Tha bank gets the message to deposit the coin and also receives the "plain text" and "signature".
- It verifies the signature is valid.
- It also verifies the serial number that it received is not in the list of "spent coins". (double spend attack check);
- It then puts the serial number in the spent coins table so that no doble-spends can occur.
- It then adds the amount to next user's account and sends a message to the next user.
(Since the bank din't see the serial number initially, the bank doesn't know who is the owner of the coin);
7. On verification of the next coin the next user will allow the completion of the transaction.
**** Bank cannot link the two users.
* Drawbacks
--------------
Depends on trusting the bank.
(Anonymous e-cash: Model is different from Bitcoin)
Anonymous e-cash through blind signatures
--------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
# Bank model
------------------ ---------------
| User | Balance | | Spent coins |
------------------ ---------------
| ... | ... | | ... |
------------------ ---------------
| A | 10 | | |
------------------ ---------------
| ... | ... | | |
------------------ ---------------
| B | 5 | | |
------------------ ---------------
# User A Withdraw anonymous e-cash
-----------------------------------
User A ------Withdraw anonymous coin-----------------------> Bank
--------Serial Number(unknown to bank)-------------->
<------Signed Serial Number(unknown to bank)---------
{3574132415345454}
# User A wants to send the anonymous coin to user B
------------------------------------------------------
User A
|
|
|
\ /
User B ----- Deposit coin #3574132415345454 (plain text)--------> Bank
{3574132415345454} (signed serial number)
<---------------------OK----------------------------------
# Account balance
-------------------
(A withdraws $1 from account and gives it to B);
------------------ ---------------
| User | Balance | | Spent coins |
------------------ ---------------
| ... | ... | | ... |
------------------ ---------------
| A | 9 | | 35741... |
------------------ ---------------
| ... | ... | | |
------------------ ---------------
| B | 6 | | |
------------------ ---------------
* Anonymity and Decentralized : in conflict
---------------------------------------------
-> Interactive protocols with bank are hard to decentralize.
-> Decentralization often achieved via public traceability to enforce security.
Q. Unlinkability in Bitcoin could mean
1. It's hard to link different addresses owned by the same user - true.
2. It's hard to link different transactions made by the same user - true.
3. It's hard to link different transactions having the same output address.
----------------------------------------------------------------------------------------------------------------------------------------
6.2 How to de-anonymize Bitcoin
----------------------------------------------------------------------------------------------------------------------------------------
-> Bitcoin is pseudonymous and hence all your transactions many get linked together.
-> In order to makle sure that the transactions are unlinkable:
- Best practice - always receive a fresh address (transactions are always new addresses so no way to track coins).
- But is the above approach still unlinkable?
[* Say Alice has bitcoins at different transaction addresses - 5 , 3 , 6;
- Alice wants to buy a tea pot of 8 bit coins
- She has to combine her coins to make the purchase - the transaction addresses are combines - linking addresses
- The adversary can observe the transaction addresses and link it to the user];
* Linking Addresses
-----------------------
-> Shared spending - it is an evidence of joint control.
-> Addresses can be linked transitively.
* Change Addresses
---------------------
[* Say Alice has bitcoins at different transaction addresses - 5 , 3 , 6;
- Alice wants to buy a tea pot of 8.5 bit coins
- She has to combine her coins to make the purchase, but here denominations don't exactly match up the pot cost.
- So she is gonna make a change address.
- She combines 3, 6 and pays 8.5 for the tea pot and 0.5 to herself.
- Here the adversary is not sure which is the address to user and that of the mechant].
#### Trick - each address can be used as a change address only once. (Alice send 0.5 back to herself and hence uses the same transaction address as the change address - this can occur only once.);
# could have alot of false positives.
* In 2013 , a Bitcoin theft did occur - by using the principles of linking address and change addresses they were able to trace huge service providers and the block-chain the steal the bitcoins.
-> Research paper -> "A Fistful of Bitcoins: Characterizing Payments Among Men with No Names"
- They tried to identify the identities on the block-chain , retrace the Bitcoin theft.
- They were not able to do by looking at their websites since each time to make a transaction a new address is posted, and unless it is a valid transaction it doesn't end up in the block-chain.
- So the only way the authors were able to reveal the bitcoin service providers or users was through actually interacting with the service providers.
- They purchased about 344 bitcoins(transactions);
- Was they were interacting with the websites, then through the link address and changes address principles they were able to identify the service providers.
* From services to users
-------------------------
(How to identify individual users in the Bitcoin network?)
1. High centralization in service providers.
- Most flows pass through one of these - in a traceable way. (Each individual will in some manner be linked to major service providers);
2. Address - identity links in forums. (Users can post addresses in the links, and when one address is captured then through link address and change address - all transactions of the users can be found).
# Block-chain - > Application Layer;
# Peer-to-Peer netwrok -> Network Layer;
* Network-layer de-anonymization
-------------------------------------
-> Dan Kaminsky (Blackhat 2011 talk);
-> "The first node to inform you of a transaction is probably the source itself." (link between transactions and IP address -> close personal identity); (When a transaction is made, the source node send the message to the other nodes);
-> This issue of communicating anonymously can be solved : use Tor
* use Tor
-----------
-> Caveat : Tor is intended for low-latency activities such as web browsing. (response immediately);
-> Bitcoins - high latency (takes time for transactions to propagate through network and to get confirmed in the blockchain);
-> Mix nets - might provide better anonymity.
-> BUT Tor is deployed and works for now.
Q. Which of the following observations would suggest that addresses A and B may be controlled by the same user/entity?
1. There is a transaction with A as an input address and B as an output address
2. There is a transaction with both A and B as input addresses - Correct.
3. There is a transaction with both A and B as output addresses
----------------------------------------------------------------------------------------------------------------------------------------
6.3 Mixing
----------------------------------------------------------------------------------------------------------------------------------------
-> To protect anonymity, use intermediary.
- Users send transactions to intrermediary service.
- The intermediary doesn't keep track of the user and the transaction.
- When the user withdraws an amount it is drawn from a random address from the intermediary.
- So there is no link from the input transaction address to the output transaction address, and no one can identify it from an external public chain on something else.
User Input ----xx --> Intermediary --> yy---- Output.
-> Like online wallets - they store money until we need them.
* Dedicated mixing services
----------------------------
1. Promise not to keep records.
2. Don't ask for your identity.
* Online Wallets
-------------------
-> Reputable, often regulated businesses.
1. Typically require identity keep records -> no anonymity w.r.t wallet service.
2. If Users trust the online wallet service with their bitcoins
-> then users will keep bitcoins in the wallet service longer than they would have kept in mixing services.
-> It provides bigger anonymity set w.r.t everyone else. (The wallet service will know the identity, but anybody looking into the block-chain will have no idea);
"Online wallets - provide the anoanymity - as that of traditional banking system."
* Consider a user for whom the trust requirements and anonymity properties for online wallets are unacceptable.
------------------------------------------------------------------------
-> Mixing -> mix,mixer, laundry;
* Principles for mixing services
---------------------------------
1. Use a series of mixes
- Mixes should implement a standard API to make this easy.
Mix 1 Mix 2 Mix 3
---------- -------- ----------
| | | | | |
User A x----------|----X | | X----|------+-----|---x |
| | | | | |
| | | | | |
| X | | x | | x----|-----------User A
| | | | | |
| | | | | |
| X---|------+-------|---x | | x |
| | | | | |
---------- ---------- ----------
-> A series of address changes a user viewing the block-chain will not be able to figure out transaction / link identity.
2. Uniform transactions.
- In particular: all mix transactions must have the same value! (chunk size);
3. Client side must be automated.
- Built in desktop wallet softwares - so that the software automatically knows how to interact with the mixes in order to preserve the user's identity.
4. Fees must be all-or-nothing (Mixing services are a business and hence must be paid - 1/1000 hashes);
- Probabilistic fees:
0.1% mixing fee = mix will swallow chunk with 0.1% chance.
**** "Current mixes follow none of these principles."
* Remaining problem : trusting mixes
----------------------------------------
1. Stay in business , build up reputation.
2. Users can test for themselves. (users can have numerous small chunk size transactions with the mix - eventually if any of their transactions are lost they they will not trust the mix service (steal) - although the mixes have no way of knowing the user identity);
3. Cryptographic "warranties". (mix provides promises, incase the mix fails to keep that promise, then trust issue);
* Currently no reputable dedicated mix
----------------------------------------
Caution : Mixing services may themselves be operating with anonymity. As such, if the mixing output fails to be delievered or access to funds is denied there is no recourse. Use at your own discretion.
- Bitcoin Wiki
Q. Which of these techniques can improve the anonymity provided by mixing services? (Check all that apply)
1. Using a series of mixes - true;
2. Using the same "chunk" size for all mixing transactions - true;
3. Charging a constant percentage of the transaction value as a mixing fee
----------------------------------------------------------------------------------------------------------------------------------------
6.4 Decentralized Mixing
----------------------------------------------------------------------------------------------------------------------------------------
* Why decentralized Mixing?
-----------------------------
1. No bootstrapping problem - cause there is no dedicated mixed service.
- There is a community of peers who all want to do mixing and without a cental service that collects your funds. (Internal interest fromthe bitcoin community);
2. Theft impossible
- Enforce through technical means. No body is explicitly sending Bitcoins to another user.
3. Possibly better anonymity.
4. More philosophically alligned with Bitcoin.
* Coinjoin
------------
-> The main proposal for a decentralized mixing is called Coinjoin.
-> Proposed by Greg Maxwell, Bitcoin core developer.
-> Multiple users can interact in a single interaction , via different input addresses and output addresses.
-> An adversary looking at the block chain will not able to tell which transaction corresponds to which user.
-> This is 1 mixing round.
- > Mixing principle from the centralized mixing networks apply on top of the basic protocol.
--------------------------
| |
| |
A *----------|---- ----|----------* C
| |
| |
| Single |
B *----------|---- Transaction ----|----------* A
| |
| |
| |
C *----------|---- ----|----------* B
| |
| |
| |
----------------------------
* Principles for mixing services
---------------------------------
1. Use a series of mixes
- Mixes should implement a standard API to make this easy.
Mix 1 Mix 2 Mix 3
---------- -------- ----------
| | | | | |
User A x----------|----X | | X----|------+-----|---x |
| | | | | |
| | | | | |
| X | | x | | x----|-----------User A
| | | | | |
| | | | | |
| X---|------+-------|---x | | x |
| | | | | |
---------- ---------- ----------
-> A series of address changes a user viewing the block-chain will not be able to figure out transaction / link identity.
2. Uniform transactions.
- In particular: all mix transactions must have the same value! (chunk size);
3. Client side must be automated.
- Built in desktop wallet softwares - so that the software automatically knows how to interact with the mixes in order to preserve the user's identity.
4. Fees must be all-or-nothing (Mixing services are a business and hence must be paid - 1/1000 hashes);
- Probabilistic fees:
0.1% mixing fee = mix will swallow chunk with 0.1% chance.
* Coinjoin Algorithm
---------------------
1. Find peers who want to mix.
2. Exchange input/output addresses.
3. Construct transaction.
4. Send it around, collect signatures. (Before signing , each peers checks if her output is present). (Security property);
(Incase any of the peers don't sign the transaction, then it collapses);
5. Broadcast the transaction.
(Any number of valid peers can broadcast the transaction).
* Coinjoin : Remaining problems
---------------------------------
1. How to find peers?
2. Peers know your input-output mapping.
(Big problem - than centralized mixes) - one of the peer could be an attacker creating Sybil transactions which infiltrate into the network.
3. Denial of Service.
- After the input and output pairs are established for the coinjoin, it could be possible that one of the peer disappears or fails to sign the transaction then the transaction is invalid.
- It could also be possible that after the transaction is signed and befire it is broadcast to the network, one of the peer could consume it , in which case it will be treated as a double-spend attempt and hence rejected by the Bitcoin network.
* Solutions to above problems
------------------------------
1. Finding Peers - Use an untrusted server. Different users can connect and the server need not involve in running the protocol.
- A peer-to-peer protocol needs to run to find the coinjoin on top of the bitcoin protocol.
2. Peer anonymity
# Strawman solutions:
a. Exchange inputs
b. disconnect and reconnect over Tor. (Break the linkage between the input and the output)
c. Exchange outputs.
- Better solutions : special-purpose anonymous routing mechanism. (decryption mixnets);
3. Denial of service
# Proposed solutions:
a. Proof of work.
- Repurposing the algorithm to require each of the peer nodes to do a little bit of computation before they can join a Coinjoin protocol. If the adversary is gonna duisrupt the coinjoin then they will be burning out a lot of computation power - expensive.
b. Proof of burn. (Fidelity Bonds in Bitcoin)
- Allows to irreversibly destroy some Bitcoins that you own by sending it to an unspendable address.
c. Server kicks out malicious participants.
d. Cryptographic "blame" protocol -> (Coin shuffle : Practical Decentralized Coin Mixing for Bitcoin 2014);
[c, d points basically attempt to identiify the malicious node and eradicate them from the network.]
* High-level flows could be identifying
------------------------------------------
-> Example: Alice receives 43.12312 BTC / week as income . Always immediately transfers 5% to retirement account.
-> Irrespective of the input and output address pattern the transaction, value of it itself stands out and the pattern / transaction is identifiable.
* Means to solve the above problem (High-flow detection)
---------------------------------------------------------
# Heuristic : merge avoidance
-----------------------------
-> Instead of a single payment transaction.
-> Receiver provides multiple output addresses.
-> Sender avoids combining different inputs. (Can make a variety of transactions)
Q. Which of these is NOT an advantage of CoinJoin over centralized mixes?
1. Theft by mixes is impossible
2. Built-in protection against denial-of-service attacks - correct
3. Potentially better anonymity because centralized mines can e compromised by adversaries
----------------------------------------------------------------------------------------------------------------------------------------
6.5 Zerocoin and Zerocash
----------------------------------------------------------------------------------------------------------------------------------------
* Zerocoin : protocol-level mixing
----------------------------------
-> Mixing capabilities baked into protocol.
-> Advantage : cryptographic guarantee of mixing. (Don't need to trust a single mix or even a set of mixes or set of peers or etc, to esure anonymity);
-> Disadvantage: not currently compatible with Bitcoin. (Paper -> Zerocoin : anonymous Distribution E-Cash from Bitcoin 2013);
* Basecoin and Zerocoin
--------------------------
-> Basecoin : Bitcoin-like Altcoin.
-> Zerocoin : Extension of Basecoin.
-> Basecoins can be converted into Zerocoins and back.
-> When converted there is a break in the link between original and new basecoin.
* Zerocoin
------------
-> A Zerocoin is a cryptographic proof that you owned a Basecoin and made it unspendable.
-> Miners acn verify this proof.
-> Gives you the right to redeem a new Basecoin. (like poker chips).
* Two challenges
------------------
1. How to contruct the proof (For miners to verify)?
2. How to make sure thet each proof can only be spent once? (no double spends).
* Zero-knowledge proofs
------------------------
-> A way to prove a statement without revealing any other information.
e.g I know an input that hashes to some hash in the following set.
* Minting zerocoins
-----------------------
-> Zerocoins come in standard denominations. (Let's assume 1 basecoin.)
-> Anyone can make a Zerocoin. They don't have value until put into the block-chain.
-> They have value once put on the blockchain. That costs one basecoin.
-> Putting the Zerocoin on the blockchain is as expensive as the zerocoins value.
* Minting a Zerocoin: "commitment"
----------------------------------
-> Generate a serial number S (eventually made public);
-> Generate a random secret r (never public, ensures unlinkability);
-> Compute the Hash H(S, r);
-> Put the H(S, r) commitment on the block-chain - at this point it is real, has value.
-> To put H(S,r) on the bloc chain
- Create Mint Tx with 1 basecoin input (burning a basecoin and making it unspendable);
(Spend the basecoin to mint the Zerocoin)
-----------------------------------------------------------------------------
| |
\ / |
------------ ------------- ------------- |
| | | | | | /-----------------|----
------------ ------------- ------------- /| Signed by Alice | |
| | <-------| | <-------| Mint | -----------------|----
------------ ------------- ------------- \ | H(S, r) H(|) |
| | | | | | \----------------------
------------ ------------- -------------
| | | | | |
------------ ------------- -------------
* To spend a zerocoin S:
---------------------------
-> Reveal S - serial number (miners will verify S hasn't been spent before).
-> Create zero-knowledge proof that:
"I know a number r such that H(S,r) is one of the zerocoins in the blockchain."
-> Pick arbitrary zerocoin in block chain and use it as input to the new transaction.
* Zerocoin is anonymous
------------------------
-> Since r is secret, no one can figure out which zerocoin corresponds to which serial number. H(S, r);
* Zerocoin is "efficient"
---------------------------
- Not linear, logarithmic - logN;
-> I know r such that
H(S, r) = h(1) OR
H(S, r) = h(2) OR
H(S, r) = h(3) OR
.
.
.
H(S, r) = h(N) OR
-> Very long - lenth proportional to the length of Zerocoins on the blockchain.
* Zerocash
--------------
-> It uses a cryptographic tool called Snarks.
-> Zerocoin without Basecoin.
-> Upshot
1. Different crypto for proofs (More efficient);
2. Proposal to run system without Basecoin.
* Zerocash: untraceable e-cash
---------------------------------
-> All transactions are zerocoins.
-> Splitting and mergining supported.
-> Put transaction value inside the envelope (H(S, r));
-> Ledger merely records the existence of the transactions.
* Zerocash : the catch
-----------------------
-> Random, secret inputs are required to generate public parameters.
-> Theses secret inputs must then be securely destroyed.
-> No one can know them (secret) (anyone who is aware - can break the sytem - create zerocoins for themselves);
* 5 Levels of Anonymity
------------------------
System Type Anonymity attacks Deployability
--------------------------------------------------------------------------------------
Bitcoin Pseudonymous Tx graph analysis Default
Single Mix Mix Tx graph analysis, bad mix Usable today
Mix chain Mix Side channels, bad mixes, peers Bit-coin compatible
Zerocoin Cryptographic mix Side channels (possible) Altcoin
Zerocash Untraceable None Altcoin, tricky setup
# Tx graph analysis - unlinkability test - linking address and change address.
Q. What is “zero knowledge” about a zero-knowledge proof?
1. It takes no outside knowledge to verify the correctness of the proof
2. It is a proof that doesn’t reveal any knowledge other than the statement’s truth - correct.
3. It is a proof that requires no knowledge to create
4. It is a proof that you have no knowledge of something
----------------------------------------------------------------------------------------------------------------------------------------
6.6 Tor and the Silk Road
----------------------------------------------------------------------------------------------------------------------------------------
* Anonymous communications
----------------------------
-> Bunch of senders and bunch of recipients, and messages are routed from senders through recipients through the anonyous network.
-> There might be an attacker, in the threat model , the attacker controls many things.
-> Certain nodes on the network are compromised by the attacker.
-> Some of the edges/links between the nodes and the network are also controlled by the attacker.
-> Some of the recepient nodes the links between the nodes and the networks could also be controlled by the attacker.
-> A few of the internal nodes on the anonymous communication network could also be controlled by the attacker.
Tor
--------
-> Tor helps to achieve anonymity(pseudonomity + unlinkability) in the network.
How Tor Works
-------------
# Alice wants to communicate with Bob, she pre-selects a path through a set of routers (3 routers - fixed number) - Tor routers.
# Security property : Safish if atleast one router is honest - anonymity can be achieved.
-> Key challenge -> Hiding routing information. (each routing information wou;ld have timestamp, destination and source ip address,
therefore the addresses and the information are encrypted);
* Solution: Layered Encryption
--------------------------------
# Alice and router 1 share a symmetric key;
# Alice and router 2 share another symmetric key;
# Alice and router 3 share another symmetric key;
# The symmetric keys are not stored for long on any of the nodes, they are established as necessary using key exchange.
# Only persistent keys are the long-term public keys to the routers.
# Alice doesn't need to have long-term public key, when she picks a path of these routers she finds their public keys executes the key
exchange protocols, and obtains these shared symmetric keys.
# When she sends the message to R1, it's gonna be triply encrypted.
# When router 1 peels out the 1st layer of encryption, it's gonna find the IP address of the router two and the encrypted message is forwarded to router two.
# Then router 2 peels of the second layer of encryption and forwrds the messga eto the third router.
# The third router then peels the third encrypted layer and the message is now unencrypted consisting of plain text message and Bob's IP address.
# The router then forwards the message to Bobs IP address.
-> Side Effects : Contents encrypted from Alice to exit node but, unencrypted from exit node to Bob.
* Silk Road
-----------------
-> It's a Hidden service that provided anonymity.
# What if the server wants to hide its address?
-> Connect to "rendezvous point" through Tor.
-> Publish name -> rendezvous point mapping.
- Not normal DNS (Domain Name System);
- It 's mapped to onion addresses
- http://3rtgerhgrhtr4klok454542gh.onion/
- On a Tor enabled browser.
-> Client connects to rendezvous point.
# Communication : Tor hidden service
# Payment : Bitcoin
# Security : Had a reputation
# Anonymous Shipping : The buyers provided an anonymous PO Box example to ship goods to.
---------------------------------------------------------------------------------------------------------------------------------------