OnionCoin: Peer-to-Peer Anonymous Messaging with Incentive System
by
Tianri Gu
A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE
in
THE FACULTY OF GRADUATE AND POSTDOCTORAL STUDIES
(Computer Science)
THE UNIVERSITY OF BRITISH COLUMBIA
(Vancouver)
August 2018
c Tianri Gu, 2018
i The following individuals certify that they have read, and recommend to the Faculty of Graduate and Postdoctoral Studies for acceptance, a thesis/dissertation entitled:
OnionCoin: Peer-to-Peer Anonymous Messaging with Incentive System
submitted by Tianri Gu in partial fulfillment of the requirements for
the degree of Master of Science
in Computer Science
Examining Committee:
Mike Feeley Supervisor
Alan Wagner Supervisory Committee Member
Supervisory Committee Member
Additional Examiner
Additional Supervisory Committee Members:
Supervisory Committee Member
Supervisory Committee Member
Abstract
The "free-riders" issue happens in many peer-to-peer system, and this issue severely damages the liveness of the system especially for the system that heav- ily relies on coordination of multiple peers. Many peer-to-peer system assumes that the peers are willing to volunteer their resources to support functionality of the system, such as content storage and traffic relay. However, the assumption is hardly true in real Internet world, in which most of the users are trying to maximize their profit playing to take advantages from the system without pro- viding corresponding services to others in the system. The notable decentralized anonymous network, TOR[1], also does not have any explicit incentives for the peer to host Onion Router as infrastructures relaying secure traffics to protect the other peers’ anonymity. Therefore, eventually the behaving users lose their faith in the system due to the unfairness, and the system may cease to properly run. OnionCoin(OC) is the first decentralized peer-to-peer anonymous messag- ing system based on Onion Routing with the integration of currency system attempting to resolve such issues in Onion Routing based systems. A peer in OC will have to "pay" for using the anonymous messaging service, and will "gain" by helping other peers. The purpose of this currency system is to record the transactions of "pay" and "gain" in order to provide incentives for peers to participate more in the system. Several protocols are designed so that the in- troduction of the currency system does not compromise any existing protection in Onion Routing on the anonymity of the communicating parties.
iii Lay Summary
This paper presents the design of an peer-to-peer anonymous messaging system named OnionCoin(OC). In OC, for an user to send an anonymous message to another, the message is going to passed through multiple other users till reaching the final destination, so that the path of the message is hard to discover by the adversary. OC also provide a solution to resolve the "free-rider" issue in such system by introducing a currency system. A "Coin" represents a token for services. Any user will have to "pay" a Coin for the service to deliver its own message, and every time a peer helps delivering the message from other peer, it gets "paid" anonymously with one Coin. As a result, every peer trades its contribution to the community to earn Coins saved for future communication and be able to communicate with anonymity.
iv Preface
This dissertation is original, unpublished, independent work by the author, Tianri Gu.
v Table of Contents
Abstract ...... iii
Lay Summary ...... iv
Preface ...... v
Table of Contents ...... viii
List of Tables ...... ix
List of Figures ...... x
Acknowledgement ...... xi
Dedication ...... xii
1 Introduction ...... 1
2 System Overview ...... 3 2.1 Decentralized Identity Provider ...... 3 2.2 Roles and Duties ...... 3 2.3 Global Ledger ...... 4 2.4 Message Encoding Scheme ...... 6 2.5 Routing Table ...... 6 2.6 ThreatModel...... 7 2.7 Challenges...... 7
3 Currency System: No Pay No Gain ...... 9 3.1 CoSignProtocol ...... 9 3.2 WhatExactlyisaCoin?...... 10 3.3 Blind Signature Review ...... 11 3.4 CoinExchange ...... 12 3.5 FailToExchangeCoin...... 14
4 Join and Discover ...... 15 4.1 Register Protocol ...... 15 4.2 Registration Failures ...... 17 4.3 Finding Peers ...... 17 4.4 Active Advertisement ...... 18 4.5 Potential Threat on Peer Discovery ...... 18
5 Anonymous Message Delivery ...... 19 5.1 Preparation Stage ...... 20 5.2 Messaging Model Adjustment ...... 20 5.3 Message Forwarding Protocol ...... 24 5.4 Failure on Delivery ...... 25
vi 6 The Ledger ...... 26 6.1 Records ...... 26 6.1.1 Registration Record ...... 26 6.1.2 CoinExchangeRecord...... 26 6.1.3 Coin Reward Record ...... 27 6.2 Bank Selection ...... 27 6.3 Ledger Synchronization Protocol ...... 28 6.4 Block Generation ...... 30 6.4.1 Proposing Stage ...... 30 6.4.2 Pushing Stage ...... 31 6.4.3 Pulling Stage ...... 31
7 Threat Case Analysis ...... 32 7.1 PassiveThreatonMessaging ...... 32 7.2 Single Malicious Node ...... 32 7.3 Multiple Malicious Intermediate Nodes ...... 33
8 Cheating on Currency ...... 36 8.1 ForgingCoinsandRecords ...... 36 8.2 CheatingSenderandIntermediateNode ...... 38
9 Analysis of Encryption Steps ...... 39 9.1 Encryptions in OMSG ...... 39 9.2 Encryptions in Protocols ...... 39 9.2.1 SignaturesInTheRecords ...... 40 9.2.2 Onioned Messages ...... 40 9.2.3 Blind Signature ...... 40 9.3 Analysis Summary ...... 41 9.3.1 Extra Cost in Coin Exchange ...... 41 9.3.2 ExtraCostinMessaging...... 42
10 Prototype Evaluation ...... 43 10.1 Implementation...... 43 10.2 Experiments ...... 43 10.3 Evaluation ...... 48
11 Limitation and Future Work ...... 51 11.1 Unidirectional Message ...... 51 11.2 Delivery Failure Detection ...... 51 11.3 Performance as of a Messaging System ...... 52 11.4 Re-usabilityofaCoin ...... 52 11.5 Features in Future Work ...... 53
12 Related Works ...... 54
13 Conclusion ...... 56
vii Bibliography ...... 57
viii List of Tables
1 The probabilities that an adversary can forge Coins ...... 37 2 Number of Messages and Encryption Steps Summary for Coin Exchange in OC compare with NACE ...... 41 3NumberofMessagesandEncryptionStepsSummaryforaMes- sage Delivery through L intermediate nodes compared with TOR 42
ix List of Figures
1 RolesSwitchesinOCwith5Nodesand2asBank ...... 5 2OMSGGeneralFormat...... 5 3 CoSignProtocolwithNC=3...... 10 4 ContentofaCoin...... 11 5 CoinExchangeProtocolwithNC=3 ...... 12 6 RegisterProtocolwithNC=3 ...... 16 7MessageDeliveryfromStoRthrough2intermediatenodes...19 8 Message Delivery from S to R through 2 intermediate nodes with Coins"paid-in-advance" ...... 21 9 Message Delivery from S to R through 2 intermediate nodes with Coins"paid-afterward"...... 22 10 Message Delivery from S to R through 2 intermediate nodes with Coins "paid-afterward" and Feedbacks ...... 23 11 Ledger Synchronization with d0 =3and d1 =5 ...... 29 12 Number of Messages To Deliver 1000 message as Number of CoSignerschanges ...... 44 13 Number of Encryptions To Deliver 1000 message as Number of CoSignerschanges ...... 45 14 Number of Messages To Deliver 1000 message as length of Epoch changes ...... 46 15 Number of Encryptions To Deliver 1000 message as length of Epoch changes ...... 47 16 Number of Messages To Deliver 1000 message as Number of Banks changes ...... 48 17 Number of Encryptions To Deliver 1000 message as Number of Banks changes ...... 49
x Acknowledgement
I offer my sincere gratitude to the faulty of Computer Science, staffand my brilliant peers, who have inspired me to continue my study in Computer Science. Also, thanks to my graduated friends on providing precious suggestions. I owe my particular thanks to Dr. Mike Feeley, whose wisdom and guidance had greatly helped me on the path of becoming a better researcher and critical thinker in the field of Distributed Systems design. It was always a wonderful memory when discussing the ideas and thoughts in your office on the third floor at ICICS.
xi Dedication
To my beloved ones.
xii 1 Introduction
The significance of anonymous communication system is getting more attention for its capability on protecting the identity of the communication parties under the pervasive network traffics monitoring. Many researchers have proposed dif- ferent approaches designing application level anonymous communication overlay network to protect user’s anonymity. Majority of these [3, 19, 16] are based on the centralized server or a group of servers as the proxy to provide covers for their users. Although many of these system can provide strong guarantee on anonymity, they are relatively more vulnerable to be attacked on the availability such as Denial-of-Service(DoS) compared to the systems with more decentral- ized designs such as TOR [1], instead simply shutting down these messaging servers would prevent the anonymous communication from happening. When the servers are distributed across the globe, it makes the attack on availabil- ity much more difficult to perform but are only able to monitor the traffics at best effort to try to expose the connection among some of the suspecting users. Therefore, for practical use, decentralized anonymous systems are more stable choice despite they might not provide such strong protection on security due to their distributed design. TOR[1], as one of the most famous and infamous decentralized anonymous networks, has proved its guarantees on anonymity is sufficient for multi-purpose discrete communication at geo-distributed scale. However, in TOR, it requires many users to volunteer for hosting Onion Router as traffic relay to help re-direct the other TOR traffic in order to provide cover for the communication ends. In such peer-to-peer style system, the incentives for the user to volunteer providing free help can be questionable. In the original TOR paper, the authors state that hosting an Onion Router would provide better protection on anonymity. As an Onion Router, there will be foreign TOR traffic in and out, which could behave as the cover traffic when the host is sending secure messages, thus the adversary would require more resources to capture suspicious behavior of the Onion Router host. Nevertheless, this type of incentives may also attract more attention from the adversary than the other users that only use TOR as proxies. Also, in the aspect of resource consumption, the user hosting Onion Routing would definitely consume some resources on helping other users rather than saving the resources for itself. This encourages the "free-riders" behavior in TOR for there is no regulation on how much resource an user can consume on the public Onion Router. Is it possible to introduce fairness to anonymous messaging system based on Onion Routing while still remain its guarantee on anonymity? In this paper, a peer-to-peer anonymous messaging system combined with a currency system named OnionCoin(OC) is designed to answer this question. In OC, no peer is "free" to use the system for anonymous message delivery, but have to spend some currency as a proof of providing services for the community in the past. Each time a user provides help for the other peers would grant it with a token for messaging service in the future. The currency system is to store such transaction records and provides the proof of this help. The records are designed so that the communication related to these records will remain anony-
1 mous. The goal of OC is to add an incentive system on top of Onion Routing based messaging system without introducing additional security concerns. The following sections start with the general view of OC, and systematic assump- tions. Then each part of the system is discussed in details stating how various consistency and security needs are met to keep the communication anonymous. Afterwards, the paper discusses several cases regarding the attacks on OC and possible cheating behaviors to the currency, and how these cases are handled with anonymity protected.
2 2 System Overview
OnionCoin(OC) is an application level P2P overlay network designed to provide anonymous messaging service in decentralized design and no other external ser- vices are required except utility services such as DNS. Each OC node is acting both as a client using messaging service and a server handing requests from other OC nodes. The anonymous communication is achieved by encrypting the message in layers and re-directing multiple times through other OC nodes till reaching the destination like the ones in TOR[1] and Tarzan[2]. Whenever a forwarding node helps delivered a message to next node, it would get paid with a reward Coin from the sender to honor its help. The information regarding the currency transactions are recorded in the global Ledger.Everytransaction requires being digitally signed by certain numbers(NC) of authorized nodes to be considered as a valid transaction record. This section will give a general picture of components in OC and how they are connected together to provide incentives for the nodes making contribution to the community.
2.1 Decentralized Identity Provider Every currency system would require an identity system to link the ownership of currency to users. Many crypto-currency systems [42, 43, 44] use public key as the identity of the user based on the security guarantee that it is computationally hard to find the corresponding private key, so that the id of a user is hard to be imitated. Yet, there is no public records indicating which users are using the system nor which public keys are involved. In OC, this kind of identity provider is not enough since the identities of users need to be verifiable by other users in the system in some operations. Therefore, OC itself is a standalone identity provider to satisfy the identity authentication requirements among nodes so that no third-party Certificate Authority is required to authenticate, which makes OC is pruned to the CA-related attacks. In OC, every operational message is public-key encrypted and therefore the public key information of all the members are publicly accessible. Each node Ni in the system must be identified by its registered public key PKi recorded on the global Ledger, and each node will sign with the same corresponding secret key SKi. The record also includes the unique ID of the node, which could be the domain name or simply a string. The identity authentication can simply be performed by any nodes in the system by checking the presence of the corresponding public key record in the Ledger. The verification of the identity of an OC node can be done by validating its digital signature in the operational messages exchanged in various situation.
2.2 Roles and Duties In OC, the publication of every currency-related transaction requires the ap- provals from multiple authorized OC nodes to prevent cheating behaviors such as forging transactions. The authority however, should not stay as the same group of nodes since the corruption may happen. Instead of granting some Su-
3 per/Leader nodes constantly present privilege over the others all the time, in OC, there are frequent leadership exchanges. A different subsets of nodes are selected as leaders in different time interval, so that no fixed group of nodes would stay as the authority at the time. There are two Roles that all nodes are expected to play over time with likely equal possibility, Normal node or Bank node. The time line in OC will be divided into small equal-length time intervals named epoch,andineachepoch, there are certain number of nodes are selected to be the Bank Nodes, and the rest of nodes remain Normal Nodes. The number of Bank Nodes(NB)isa system parameter configured at boot time of OC. As a Bank node, its primary duty is to perform the Ledger-related operations such as Coin Exchange and Identity Registration, which will generate transaction records appended onto the Ledger indicating the record is published. Each time a record is successfully published, the corresponding signing Bank Nodes are rewarded with one Coin as incentives. To perform any such operations, the Bank node must have the latest stable version of the Ledger acquired from the set of Bank nodes in previous epoch. At any point of time, the majority of nodes in OC are playing as Normal Nodes who are able to send anonymous messages or help the other Normal Nodes forwarding their messages, but has no authority to modify the Ledger. In the following sections, the Bank nodes will be named as Bank or Bi,andnodeor Ni for the non-bank nodes for simplicity. The Bank Selection Algorithm(Section 6.2) is meant to be random and dynamic but also globally verifiable by any nodes. In each epoch, the total number of Banks selected are expected to be unchanged until there are significant changes in total number(NN) of nodes in system. Consider Figure 1, which shows an example OC system with total 5 nodes and 2 of them are selected as Banks. In this example, the time starts at epoch e0 moving towards e4 and different nodes are picked as Banks in different epoch. For example, in epoch e0, B0 and B2 are chosen, and in e2, B2 and B3 are Banks. Notice that there is no restriction on re-selection in consecutive epochs.
2.3 Global Ledger The currency system in OC relies on the transaction records stored in the global Ledger. Like the other BlockChain-based peer-to-peer systems [42, 43, 44], the purpose of the global Ledger(BlockChain) is to provide the consistency of the currency to prevent and detect the double-spending problem. However, in OC, the way of recording currency transactions are different due to the anonymity re- quirements that the trace of currency should not reveal any identity information. The only unit of currency in OC is Coin. Each Coin has its static ownership under one of registered identity in OC and can be only spent(exchanged) by its owner. A Coin also has an integer coin number to distinguish from other Coins that has the same ownership. Each Coin spent(exchanged) will be recorded in the Ledger with the owner’s ID and the coin number to mark the Coin as used to prevent the same Coin spent twice. In general, every node, regardless Normal or Bank, is expected to store a
4 Figure 1: Roles Switches in OC with 5 Nodes and 2 as Bank
Figure 2: OMSG General Format local version of global ledger in order to perform some Ledger-related operations such as Bank Selection, signature verification, and Coin verification. There are three possible types of transaction records that could appear in the global Ledger, Registration Record(RR), Coin Exchange Record(CE), and Coin Reward Record(CR).Uponthegenerationofeachtransactionrecord, it requires certain number of Banks to sign the record. These signing Banks are named CoSigners. Registration Record will be generated when a new peer is joining the system, including peer’s public key and its unique ID in OC. Coin Exchange Record is generated each time a peer exchanges an existing valid Coin to a new Coin which can be used to pay for the other peers. For every Coin Exchange, each recorded CoSigner is rewarded with one unit of Coin and can be redeemed through a Coin Reward Record.Forexample,3ofBank Nodes signs a Coin Exchange Record for a Coin, then later each of them can redeem a new Coin from this transaction. Coin Reward Record can be seen as an update operation to the Ledger.
5 2.4 Message Encoding Scheme In OC, most of operations require identity check on purposes of either verifying that the user has right to perform the operation, or simply identifying which user is requesting the services. Therefore, all operational messages are secure by default for which every message are digitally signed by the sender and encrypted by the receiver. Every operational message is meant to be only readable by its designated receiver and the identity of the sender of the message is verifiable if the sender is registered in the system beforehand. During any messages ex- change, the message will be encrypted and encoding in a designated way and such formated messages will be referred as OMSG(Figure 2) in the following sections. Every OMSG has five sections including OPCODE, SENDERID, TS, HASHSIG,andPAYLOAD. OPCODE indicates the purpose of the mes- sage and its expected operation such as REGISTER for new node registration and FWD for message forwarding. SENDERID indicates the ID of the source of the message, however, which may not be the originator of this message since the message could be relayed. HASHSIG is the sender’s digital signature on the sha-256 sum of the PAYLOAD to detect the possible tamper or corruption of the message. PAYLOAD includes functional part of data in different oper- ations. After preparing all these information of OMSG, the sender encrypts the entire OMSG with AES first, then encrypts the 256-bit AES key with receiver’s public key, and attached the encrypted AES key to the front of the message before sending this OMSG. Upon receiving an OMSG, the receiver first decrypts the encrypted AES key with its private key. If the decrypted OMSG is ill-formated, then discards the OMSG. Otherwise it then decrypts the OMSG with decrypted AES key to retrieve the five sections of this OMSG. The integrity of the data can be checked by comparing the HASHSIG against the PAYLOAD with sender’s public key, and this also verifies the identity of the sender. Afterwards, the receiver can start perform requested operation indicated by the OPCODE from the message.
2.5 Routing Table The nodes in OC will all be expected to listen on UDP at OC’s port(1338) for any incoming communication. Due to there will be public key encryption scheme to verify the identity of communicating nodes, all UDP traffic will be accepted and then decoded and decrypted if possible. Whenever identity of the sender of an incoming message can be successfully verified as one of the nodes in OC, the IP address associated with this sender will be inserted or updated in the local Routing Table. Primarily, the entries in Routing Table are
6 for communication, but the IP of any node can frequently be changing in the dynamic network environment. The mechanism regarding peer discover and routing information advertising will be discussed in later sections.
2.6 Threat Model To achieve anonymity in message delivery, it means that the adversary cannot not guess which pair of honest nodes are communicating with significantly higher probability than any other irrelevant node pairs. In order for adversaries to provide solid proofs regarding their guesses, either the meta-data of the complete chain of communication between suspecting ends, or the content that directly indicating the communication facts with provable digital signatures, are required to be used to as the proof of compromising the anonymity. The adversaries have the capability to inspect, tamper, tag, and drop the datagram in any part of the communication. Moreover, the adversaries may also present as some of OC nodes pretending as honest users providing re-directing service and/or serve as Bank Node to access and modify the content of the global ledger. For any instance of communication, when all the nodes on the communica- tion path have been compromised or monitored on the same time, a firm linkage can be made between the sender and receiver. Therefore, we assume that at least one node on the communication path is not colluding with the other nodes on the path. Due to single path of communication, any tampering or dropping on the datagram probably will stop the message reaching the destination or end- ing up being delivered to the wrong destination. However, this will not expose the identity of the receiver, therefore also protecting sender’s anonymity. As for other nodes that are not controlled by adversary, it is also assumed that the nodes will act rationally, which means they will not deviate from the protocol if there is no potential earning additional Coins. In other words, all nodes are assumed to be untrusted and greedy, but will not intervene other nodes without any benefits. As for the other operations such as currency transactions and user registra- tion, we assume that the adversary cannot compromise more than half of total number of Banks in the same epoch, and no user can register multiple times in OC including the adversary. The registration abuse could cause OC vulnerable to Sybil style attacks [39] since OC’s consensus relies on the number of nodes involved. Additionally, it is assumed that when a new user wants to join OC, it can always find at least one honest Bank node to join.
2.7 Challenges The one of the greatest challenges to design such a system like OC is to resolve the conflict between a anonymous messaging system and a currency system. As an anonymous messaging system, the connection between communicating parties should not be revealed by any other nodes, yet in a currency system, normally, the information regarding the exchange of ownership of currency such as the previous ownership, new ownership and the amount of currency should
7 be visible to the public. Therefore, when sender is trying to pay the forwarding nodes, such currency transactions should be carefully designed so that they would not reflect the path of communication that the sender chooses. In other words, this challenge can be split into multiple small guarantees: (1) the validity of Coins can be verified by any node, (2) the Banks can not know the ids of payees and (3) the forwarding nodes can not know the id of payer while still be able to get paid. There are also other challenges related to the currency system, such as (4) the Coins cannot be forged, (5) the record cannot be forged, and (6) the Ledger contains same records in every node’s copy. The following sections are structured to describe how OC handles these challenges in order.
8 3 Currency System: No Pay No Gain
In any kind of p2p system, the "free-rider" issues is always severe, which signif- icantly degrades the performance and liveness of the system and brings psycho- logical damage to the honest peers due to the unfairness. To address such issue, OC adopts the currency system, which will enforce peers to "produce" the helps before "consume" the messaging service. To "produce", in one way it simply means a node needs to remain public and open to incoming OC traffic and help re-directing the message received from other peers with the intention to send anonymous message. On the other hand, when a node is selected as a Bank Node for current epoch, it can "produce" by helping with Normal Nodes which are planning to perform Coin Exchange or New Peer Registration to finish the CoSign Protocol (Section 3.1). Each signature gathered within any records will become a valid unit currency as rewards for the CoSigners. To "consume" the service, it only means the node is planning to send an anonymous message through multiple peers towards the final destination. For each intermediate nodes on the communication path, the sender should include a Coin as rewards for the "producing" peers along with the message. All of the records of both "produce" and "consume" of course will be recorded into the global ledger in order to provide certain level of consistency of overall currency volume and to ensure the fairness which is crucial to encourage peers to behave honestly. However, unlike the other crypto-currency system, OC does allow some degree of double-spending to occur in trade of performance and efficiency, and the details will be discussed in the later section. Also, unlike other crypto-currency system, OC is primarily a messaging system and the currency is auxiliary, which means the strong consistency in currency control is not necessary as long as the cheating behaviors are bounded within certain tolerable range to provide sense of fairness. The following sections will describe the definition of the Coin, and the protocols to exchange an old Coin into a new one with related techniques and operations.
3.1 CoSign Protocol For each record to be added into the ledger, it requires sufficient number of the signatures from distinct Banks selected in the same epoch. This protocol is known as the action of CoSign. The minimum number of signatures required is equal to the Number of CoSigners(NC), which is a parameter of OC configured at system’s boot time. When performing CoSign Protocol, each Bank will sign the hash of the content in record which varies based on the type of records, and then appends its ID along with the signature to the back of the record. For example, considering Figure 3, assume NC=3,andtheBanksarepub- lishing a record with CONTENT. B2 is the first Bank receives the CoSign request, then it generate its signature on the hash of CONTENT and append it to the back of the record as sigB2 with the counter incremented to 1. Then B1 passes this record to B0,andB0 does the same procedure to add sigB0 and
9 Figure 3: CoSign Protocol with NC = 3
increment the counter to 2. Finally, when B1 receives the record, after it adds sigB1 to the record, the counter is incremented till it equals to NC. B1 then sorts the signatures and Bank ids and generate the sha-256 sum of the CONTENT concatenated with signatures and ids as the identifier of this record, which in this example the hash is "6D022EB93CFB20C4775923...". At this point, B1 stores this new record locally and waits for the Ledger Synchronization in the future to make it public.
3.2 What Exactly is a Coin? All the currency in OC has single type of unit as Coin,andeachtimeboth "produce" and "consume" will also be exactly one Coin. Each Coin is only spendable by its owner, yet each Coin’s owner can exchange its Coins with the same amount of Coins with different IDs in order to pay the helping peers. Coins can only be published with the approval from multiple Banks. Such operation is known as Coin Exchange. Before the Banks can generate a Coin, a Raw Coin is created by a requesting Normal Node with desired ownership and a random unused coin number, consider the left part in Fig 4. Then the Raw Coin is split evenly into multiple pieces with total number of pieces equal to NC. A Coin essentially is a piece of data as a result of concatenation of all pieces of the Raw Coin with each piece signed by a distinct Bank. For example, in Figure 4, a
Coin CN0 is created by Banks whose IDs are B0, B1 and B2. The content of
CN0 is shown in the right part of the figure, where SKi is the private key of Bi, and "03402991" is random integer generated as the Coin number for CN0 .Also, the ids of CoSigners and the epoch number are included in the Coin for ease of verification, and this information is not encrypted.
10 Figure 4: Content of a Coin
The verification of a Coin Cid owned by Nid published by Banks Bi comes with two steps. First, retrieve the ids of CoSigners and the epoch number ei. Then check if all the CoSigners are registered in the system and if all of them are selected as Banks within epoch ei. If either the condition fails, then Cid can not be a valid Coin. Second, decrypt each piece of encrypted RCi with SKBi to get plain RCi. Then concatenate all RCisandcheckifitcontainsthe"id" and this "id" matches the presenter of Cid. If the ids are matched, then check if the Coin Number exists in the Ledger with the same ownership. If the Coin number exists, it means this Cid has been redeemed before, so Cid is no longer valid. When both steps succeed, Cid is considered to be a valid Coin owned by Nid.
3.3 Blind Signature Review Blind Signature scheme designed by David Chaum [40], is used to hide content of the message from the signer, yet still be able to get the signature by the signer on the message. To "blindly" sign a message m by S, m is firstly "blinded" by ablindfactorBFrecordedbyblinderB.Withthe"blinded"messageBlind(m, BF), S is not able to decipher Blind(m, BF) and view the content of m. Then S normally signs Blind(m, BF) by S’s private key to get privEnc(Blind(m, BF), SKS). Then BF can be removed by B and produce privEnc(m, SKS) which is message m signed by S. With the attribute of using Blind Signature scheme, one can provide discrete information to the authority to get signed without worry the exposure of the content of the information to the authority. Particularly in OC, although there are no central authorities, the Bank Nodes are responsible to act like temporary authorities signing the information provided by the Normal Nodes. One crucial step in Coin Exchange Protocol is that a Bank needs to sign on the data of the new Coin provided by a requester Node, and this information should not be
11 Figure 5: Coin Exchange Protocol with NC = 3 visible to any Banks, since the content of the Coin reflects its ownership. The usage of a Coin in OC is only to pay the intermediate nodes during message delivery, and hence if the identities of the owners of these exchanged Coins are known by a node Bi, a future communication path which has to be the combi- nation of the owners of these Coins can be easily determined by Bi. Therefore, when a node exchanges a Coin with Bank, the information of the new owner of the Coin is firstly being "blinded" using Blind Signature, so that the Bank cannot log the id of the new owner of the Coin, but also be able to sign on the new Coin.
3.4 Coin Exchange The Coin Exchange operation is the core operation of the currency exchange in OC, which will transform an old Coin into a new Coin with possibly different ownership from the old Coin’s ownership without exposing detailed information on ownership exchange to the other nodes in the system. In general, by per- forming Coin Exchange, a node N0 is able to exchange a valid Coin Cold_n0 into a new Coin Cnew_n0 with the approvals from B0, B1 ... BN , where the id "old" may or may not be the same as the id "new" and N equals (NC - 1), and a new CE record containing Cold_n0 is generated. The overall procedures when performing an instance of Coin Exchange can be split into two protocols, Coin Exchange Protocol and Coin CoSign Protocol,andtheycouldhappen concurrently. For example, considering Fig 5, N0 wants to exchange Cold==N0 into CN1 with NC = 3. N0 initiates with Coin Exchange Protocol, and the steps are:
1. N0 picks a new Coin number CNnew(80903991)thatisnotappearedon
12 the Ledger, and generates a Raw Coin RC with expected ownership as N1.
2. N0 splits RC into 3 pieces and blinds each RCi with blind factor BFi to get Blind(RC0, BF0), Blind(RC1, BF1), and Blind(RC2, BF2).
3. N0 sends a Coin Exchange request to Bi with PAYLOAD as [Blind(RCi, BFi):CN0].
4. Bi receives this request, and then verifies Cold. If invalid, abort. Otherwise Bi signs Blind(RCi, BFi)toproduceprivEnc(Blind(RCi, BFi), SKi).
5. Bi replies to N0 with privEnc(Blind(RCi, BFi), SKi), and then Bi can optionally starts Coin CoSign Protocol.
6. N0 unblinds privEnc(Blind(RCi, BFi), SKi) with BFi and retrieve privEnc(RCi, SKi).
7. N0 continues from (3)-(6) till all RCi has been signed by distinct Bi,and
then N0 can produce CN1 .
During the Coin Exchange, at any point after step (4), when a Bi receives a valid Coin in the Coin Exchange request, Bi can start to perform Coin CoSign Protocol to attempt to generate a new CE. The Coin CoSign Protocol described below is also applied to CoSign Protocol in other occasion(Fig 3 with the dif- ferent content only.
1. B0 signs the hash of Coin Cold to produce privEnc(Cold, SK0).
2. B0 sends [counter:Cold:B0:privEnc(Cold, SK0)] to another Bank B1, where counter indicates how many signatures have acquired.
3. B1 repeats (1) and (2) till counter reaches NC, and a new CE record is produced.
Since any node can start CoSign Protocol whenever receiving valid Coins, the Banks are actually competing with each other to get their signatures on the new records. Even though, more than enough number of Banks may involve and there could be multiple versions of the same record, this competitive envi- ronment encourages the Banks to generate the new records as soon as possible to try to get the rewards from the new records. Moreover, this intended compe- tition helps prevent the cheating groups of Bank Nodes from getting unlimited rewards from collusion, because now the other honest Banks are also trying to produce the records and when the number of honest Banks are greater, the possibility of forging records is lowered.
13 3.5 Fail To Exchange Coin
The Coin Exchange operation of changing Cold to Cnew can be considered as two separate parts, one from N0’s aspect and the other from the Banks. For N0,thesuccessofaCoinExchangeistogetavalidCnew from any of Banks, and yet whether Cold is marked as used should not be concerned. When N0 fails to get Cnew, the following incidents could be happening. First, there is not enough number of Banks currently available in the current epoch. Second, the signatures gathered from one or more Banks are not correct. Third, one or more signatures gathered are not from current set of Banks. To address the second and third occasion, N0 can resend the incorrectly signed RCi to different Banks to get correct signatures, which however may also fail due to insufficient number of other Banks. The first occasion seems to be solvable by simply waiting for another epoch to re-try the same exchange, but there could be the case that Cold has already been marked as used when the first time proposed. This problem is also the one of limitations in OC, which will be described in Section 11. As from Banks’ point of view, the failure would be unable to generate a new RR containing Cold to get rewards from. This failure is also applied to the other CoSign scenarios when new valid records cannot be generated. The cases could be insufficient number of available Banks, one or more ill-behaving Banks, or the information loss during the Ledger synchronization. For the first occasion, there is no feasible solution, the operation will have to abort. Waiting for another epoch to re-try may not solve the problem since different set of Banks are selected. To address the second problem, one can re-try getting the signatures from other available Banks till correct and enough signatures are collected. The solution to the third problem is categorized as the failure in Ledger synchronization and will be discussed in later section.
14 4 Join and Discover
To be able to use the services in OC, the first step would be finding the peers to perform corresponding operations, and being visible to the public is important as well. To become a member of OC, a registration is always required. The only indication for a node N0 becoming a legitimate member is the presence of avalidRRcontainsN0 and PKN0 in the Ledger. PKN0 is the only identifier to distinguish N0 from other nodes in OC, and the string id N0 is only the purpose of human-readability. Also, no user can have more than one id in OC as stated in the Threat Model. The IP address cannot be used to identify a user in OC due to two reasons. First, in the dynamic network environment, a static IP address is not practical and OC will not make such assumption by using end-to-end verification using public key. Second, like the suggestion in TOR, it is always a good idea to use additional VPN for better protection. With VPN, the IP address is certainly not the original one. Therefore, OC uses gossip style protocols to spreads the routing information of different nodes to the entire network. Before a user can use OC’s service, a registration is always required since the identity verification of a user is crucial in currency related operations. When a user is trying to find some peers in OC, the ids of the targets are required in the query to peers. In this section, the procedures of joining OC and finding peers in OC are described. OC is designed to only provide service for registered members, and the identities of all members are publicly available to all of the peers. In order to join OC, a new peer will have to generate a new public/private key pair, and pick an unused ID in OC. Then the new peer can forward the request to any one of the Banks in the current epoch, and then wait for the Banks to publish a corresponding RR with new peer’s public key and ID chosen. The number of Banks required to help new peer finishing the Register Protocol is at least NC. For the following sections, we will assume that the new peer will join on one of the honest Bank Nodes and the first round of new peer’s information will not be intentionally tampered by the adversary, and also the new peer can pick a new unique ID locally without contacting any nodes in OC.
4.1 Register Protocol The Register Protocol is mandatory for any user who wants to use OC’s service, the success of a registration is marked by having a corresponding RR in the Ledger. When joining the system, we assume in this paper that the new peer will always be able to find an honest Bank to finish the Join Protocol. However, this will not be true in the real untrusted network environment, and the solution regarding how to find the trusted node at the first place will not be addressed in this paper. Even though in OC every OMSG is encrypted with public key, some messages in the Register Protocol can not be encrypted since there is not yet registered public key for the new user Nnew.ForNnew to join the system with NC = 3, Nnew requires 3 Banks to help publishing RR through CoSign Protocol. To begin the Register Protocol, considering Fig 6, the steps are as
15 Figure 6: Register Protocol with NC = 3 following:
1. Nnew first generates public/private key pair PKnew. Then along with the idnew, Nnew sends a REGISTER request to the one of the Banks, in this example, B0.
2. Upon B0 receives PKnew and idnew from Nnew with opcode REGISTER, B0 retrieves PKN and check if there is same public key entry registered in the system by verify the existence of it in the Ledger. If idnew is not registered, then B0 signs on the hash of PKnew and idnew.
3. B0 forwards Nnew’s information appended with B0’s signature to one of the other Banks, B2.
4. When B2 receives such message, it first verifies the signature of B0,and if the signature is valid, B2 also signs on the hash of Nnew’s information and append the signatures to the back of message, then pass along to one of the other Banks.
5. As soon as enough signatures have been gathered, the last Bank, in this example, B1,generatesaRR and stores it locally. Then B1 can also notify the completion of the Register Protocol to Nnew.
Nnew,atthepointreceivingthenotificationfromB1,ishowevernotcon- sidered as fully registered since the RR with id Nnew may not be published yet and no other nodes can see the fact that Nnew has joined the system. Nnew in this case, will have to wait until current epoch passes and all the records from B1 are made publicly visible(appended to the Ledger). Then Nnew’s public
16 key and ID are verifiable by any other nodes in OC for future communication. Therefore, the notification sent by B1 is optional and only for the purpose to show Nnew that the REGISTER request has been processed. After Nnew’s RR is generated, B1 will send some of its routing information to Nnew to help Nnew finding more peers in the system.
4.2 Registration Failures The failure situation could be happening when there is not enough Banks helping to sign the RR with Nnew’s information or Nnew’s public key and ID values have been already registered previously. To handle the first failure case, Nnew will have to either retry the Register Protocol from beginning in a different epoch. To deal with the latter, Nnew will have to generate a new public/private key pair and/or picks a different ID, then restart the Register Protocol. The other failure cases could be when one or more signing Banks tampered the information about Nnew. Therefore, the information although can be published successfully, may not be originated from Nnew. In this case, if only the idnew is modified, the new peer can choose to use this ID, since the public/private key pair information is still unregistered. However, if the public key has been tampered, the private key that Nnew has is no longer useful in any sense. As a result, Nnew will have to generate a new key pair and restart the Register Protocol in latter case.
4.3 Finding Peers The overlays network in OC is considered as unstructured due to the churn of peers is expected to be high, in which structured routing techniques are rela- tively not efficient and scalable such as DHTs [45, 46, 47]. Also, in such struc- tured overlays network, if no proper modification to keep routing information private, the anonymity of communication may be revealed by checking which routing information are queried in the history. In OC, the method to aggregate and maintain routing information of other peers is gossip based, in which the information may not be very accurate at runtime, but can be spread efficiently. Also, a node can send query for specific node by its id or public key. In general, there are two ways getting more routing information of other peers in the system. First, send a LOOKUP query to one or more nodes in the Routing Table asking for recent updates of the entries in their Routing Table. This kind of lookup however should be used with caution if the node is suspected by the adversary. Second, every node is expected to broadcast a subset of all routing information including its own information it has to multiple nodes in the system. The subset should be chosen randomly to ensure every one has equal probability to be reached for operations. In both methods, the routing information should always include the recent updates to Time-to-Live values for more accurate planning for communication. However, the incentive for a node to provide routing information to other peers is not directly related to currency earnings, but to make its presence and approximate duration of up-time known to the other parts of system.
17 4.4 Active Advertisement When a registered peer whose information has been recorded as RR in the Ledger,itnolongneedstogothroughRegisterProtocol.However,especially for a peer gone off-line for a long period, its information regarding the routing is probably outdated. Each time when a registered node is coming back on- line to OC, this node can optionally choose to "advertise" its presence with the purpose of providing the possible updated IP address. The procedure is simply providing the current IP address and the expected Time-to-Live to the nodes in its Routing Table. This procedure is typically recommended for the nodes which plan to present as a forwarding node to earn Coins, since actively "advertising" would provide accurate IP information more quickly comparing to waiting to be queried directly or indirectly. Moreover, this procedure can also be used for probing. As described in the previous section, after Nnew receives the notification from B1 indicating the success of generating the new RR, Nnew is still not fully registered. Nnew however cannot checking its status by viewing the Ledger since query for Blocks is also an operation using OMSG which requires public key encryption. With this "advertisement", Nnew can periodically probe with any known nodes in the system to check whether the id Nnew has been added to the Ledger since if it has not, Nnew would receive negative responses since the signature in the message Nnew sent cannot verified. This action is also used when a heartbeat is required to ensure the target node is current on-line. However, this heartbeat should be used with caution, since this action may expose the communication plan when probing the forwarding nodes.
4.5 Potential Threat on Peer Discovery It is a general concern regarding the potential attacks on the peer discovery in peer-to-peer network, in which the adversary is able to compromise some of the nodes to pollute the Routing Table of its targets. Similar problem happens to TOR’s directory server attack [1], and also in Bitcoin’s underlying peer-to-peer network [48]. In OC, since the routing information can only come from other peers in the system, yet some of them can be malicious. The malicious nodes can pro-actively advertise its target frequently with only the routing information of the other malicious nodes, and as a result, the target node is more likely choosing malicious nodes as forwarding nodes and the anonymity of the receiver is compromised. Although, it is assumed that a node will start with routing information of honest nodes in the system, by doing progressively advertising, the adversary is at least be able to make its target nodes choose some of malicious nodes, which increases the probability for the adversary to know the identity of the receiver. In this paper, no solution is proposed to fully prevent this kind of attacks, but will definitely consider is in the future version of OC.
18 Figure 7: Message Delivery from S to R through 2 intermediate nodes
5 Anonymous Message Delivery
The primary functionality of OC is to provide a decentralized platform for regis- tered peers in the system to be able to deliver message to other peers in system with anonymity. Such decentralized anonymous messaging systems have been proposed in many different paradigms, and famous ones like TOR [1] are being actively deployed globally. In OC, the scheme to achieve anonymity is inspired by the Onion Routing [1] based system, in which the message is being encrypted multiple times in layers with different keys. Then this encrypted message will go through multiple intermediate node and each node can decrypt it with its own private key to peel one layer offthe message. So that, only when the message reaches the destination node, the content of the original message can be viewed. In contrast to TOR [1], instead of using symmetric keys to wrap and unwrap the original message, OC only uses public key for encryption. The reason that OC chooses not to use sole symmetric encryption is that OC tries to leverage the use of public key for both identification and encryption purpose, for which if using symmetric key scheme cannot achieve both purposes at meantime directly. In TOR, multiple of symmetric keys for each pair of hops are negotiated when the virtual circuit is built, and those keys can only be used within the same circuit for encryption and identification. When the old circuit is destroyed, these symmetric keys are no longer useful for identification. With the integration of the currency system, besides the extra content added in OMSG, there are also extra steps added when delivering messages. These ex- tra steps are mainly for the purpose to utilize the currency to provide incentives for peers to be more likely participate in OC while still remain anonymous. To be specific, the intermediate nodes will get Coins from the source at the proper
19 moment when it provides the help re-directing the message. Besides, some of the optional steps are designed to serve as the cover traffics to aid hiding the intention of the communication. The full procedure of send an anonymous mes- sage can be separated into two parts, the Preparation Stage and the delivery of the message by Message Forward Protocol.
5.1 Preparation Stage In Preparation Stage, the sender is responsible for getting enough information to make the message delivered with high probability such as routing information of the selected forwarding nodes, and the Coins for every forwarding node. For the sender node S to deliver a message m to the receiver node R, S first needs to prepare several necessities before actually send offthe m.(1)S needs to plan the communication path consists of multiple intermediate nodes with ids N0, N1,...Nk, with public keys PK0, PK1,...PKk which are registered in OC. (2) If any routing information of intermediate nodes or R is missing or suspected to expired in S’s Routing Table, S needs to gather such routing information from other nodes . (3) If S does not have at least one Coin for each Ni, S needs to perform one or more Coin Exchange operations to acquire enough Coins C0, C1, ... Ck for rewarding, (4) Optionally, S could wait for the time when there are intense incoming traffic while sending m for better anonymity. (5) S prepares the layered payload M in form of
pkEnc(N1 : CS : ... : pkEnc(R : Ck 1 : pkEnc(m : Ck,PKR),PKk)...., P K0) as the PAYLOAD part in OMSG with OPCODE to be FWD.Forinstance, if S chooses N0 and N1 as intermediate nodes, the payload M should be:
pkEnc(N1 : CS : pkEnc(R : C0 : pkEnc(m : C1,PKR),PK1),PK0)
The order of steps are crucial, especially steps (2) needs to be done before (3)-(5), otherwise, once the Coins are exchanged and if some of intermediate nodes are not currently on-line, the deliver would fail with high probability. The broken point on the communication path is undetectable, therefore the Coins that have been spent before reaching the broken point are paid to the other peers, however, the Coins that are supposed to pay for the peers after the broken point are still valid and can be used in future for the same subset of peers.
5.2 Messaging Model Adjustment Continue with the same context from previous sections, where the communica- tion lies among S, R,andN0, N1 ... Nk.Toreasonaboutthenecessityofthe extra steps for message delivery added in OC, start considering the base ver- sion of Onion Routing message delivery protocol(Figure 7). The steps (1)-(4) in Preparation Stage remain the same, and perhaps with different mechanism
20 Figure 8: Message Delivery from S to R through 2 intermediate nodes with Coins "paid-in-advance" according to the system designs. In the last step, the content of M can be sim- pler as there is no need for Coins. The form of message M with a path consists of N0 and N1 should in the format like:
pkEnc(N1 : pkEnc(R : pkEnc(m, P KR),PKn1),PKn0)
Then S forwards M to N0.AsN0 receives M,itcandecryptM0 with its private(secret) key SK0 and get next hop id N1 and the inner message M1. After that, N0 forwards M1 to N1. N1 can also decrypt it to retrieve id R and M2.Finally,R receives M2, and decrypts it with SKR to read the message m which was originated by S. This base version of Onion Routing provides the anonymity for S by hiding its action delivering m to R via multiple intermediate nodes in which none of these nodes are able to read the content of m due to the encryption. Also, none of these intermediate nodes are able to determine the source of m since the fact that m could be going through multiple hops on purpose and therefore the neighbor nodes are not certainly the origin nor destination of m. The base version of Onion Routing has no assumption about the odds that the intermediate nodes will or will not deliver m continuously till reaching R since no incentives are provides. Now considering adding Coins to M0 for paying the intermediate nodes, based on the Onion Routing communication model, Coins are added for rewarding the intermediate nodes for helping deliver m from S to R.AssumeS has already gained two Coins Cn0, Cn1 for N0 and N1. The simplest way for S is to "pay-in-advance".Forexample,S prepares the payload M as
pkEnc(N1 : Cn0 : pkEnc(R : Cn1 : pkEnc(m, P KR),PKn1),PKn0)
21 Figure 9: Message Delivery from S to R through 2 intermediate nodes with Coins "paid-afterward"
In this way, considering Figure 8, when N0 receives M0,itcandecryptM0 and retrieve its rewarding Coin Cn0 and so does N1.Baseonthevalidityofthe Coins, the intermediate nodes can then determine whether or not to continue forwarding the M1 to next hop. However, this model has to be based on the assumption that every node is willing to behave according to protocol if the node is rewarded properly, which can be too excessive to ask for in the real- world network environment. Any intermediate nodes in this communication model actually have no incentives to keep providing aids since the rewards have been "paid-in-advance". In order to prevent intermediate nodes from taking the rewards without providing the service, a better design would be that the rewards can be "paid- afterward". Now consider a better version of this model(Figure 9), in which the Coins are no longer directly accessible by its owner at the first place. Consider the following procedure, S prepares M0 in the form of:
pkEnc(N1 : CS : pkEnc(R : Cn0 : pkEnc(m : Cn1,PKR),PKn1),PKn0)
Now after N0 decrypts M0, N0 will not get Cn0 for reward. Instead, N0 will get Cn0 for the node from its next hop which is N1 in this case, and N0 should reply CS to S for rewarding S and then N0 delivers M1 to N1. In this version, the rewards will always coming from the peer on next hop, and by designing it this way, it guarantees that only after an intermediate node has helped delivering a message, this node may get the rewarding Coin. With this fact in the protocol, the intermediate nodes should be more willing to deliver the message further compared to the first model(Figure 8). However, this model introduces one extra message for each hop on the com-
22 Figure 10: Message Delivery from S to R through 2 intermediate nodes with Coins "paid-afterward" and Feedbacks munication path, which in general doubles the total number of messages re- quired to deliver m,anditisnotenoughtoprovidethesenseofincentiveto the intermediate nodes especially when S plans to cheat. In this model, every intermediate node expects to get rewards from its next hop, yet these interme- diate nodes can not really do anything to guarantee receiving a valid Coin after providing the help. The sender S can simply wraps some of invalid Coins or just trivial data along with the m,andthem will probably still be able to reach the destination with the same probability compared to that S uses valid Coins to pay the intermediate nodes. To resolve the problem with the cheating sender, one extra step can is nec- essary to add to constrain S from cheating with invalid Coins. The format of message M0 remains the same as in previous model, and an intermediate node Ni can only get reward from its next hop Ni+1. The extra step would be, af- ter Ni decrypts M0,insteadofforwardingtheinnermessageM1 to Ni+1 and replying Ni 1 with Ci 1 at meantime, Ni replies Ci 1 to Ni 1 with the Coin first, and then wait for a feedback from Ni 1. The feedback from the Ni 1 varies by the result of Ni 1 verifying the validity of the Ci 1.AfterNi receives the positive feedback from Ni 1 indicating Ci 1 received is valid, Ni based on this positive feedback, can decide whether to forward M1 to Ni+1. Consider Figure 10 for how this new model works. With the feedback step added, the intermediates nodes now are able to tell whether S has included invalid rewards for their previous hops. An intermediate node although cannot directly determine the validity of its upcoming Coin for its next hop, the fact that if S has provided the invalid Coin at its previous hop
23 indicates S’s intention to cheat. Therefore, with this step added, the sender should be more willing to provide only the valid rewards to increase the proba- bility of a successful message deliver, since once any cheating by S is detected, the intermediate nodes probably would not want to continue helping to forward the message. This model however still allows S to partially cheat and yet get the message delivered with the same probability. Now consider S prepares M0 with all Coins to be valid except the one for the last intermediate node Nk.Bydoingthisway, even though Nk is able to detect cheating behavior of S,themessageitself has already be received by the receiver R, which allows S to pay one less Coin to deliver the message with same success rate compared to that all Coins are valid. Nevertheless, when S cheats in this way, Nk has a higher chance to detect that its next hop R is the final destination of m, which could aid compromising the anonymity of this communication especially if Nk is part of the adversary. Therefore, for S’s best interest, S would still want to use only the valid Coins to deliver m.
5.3 Message Forwarding Protocol This version of protocol is adopted in OC as the Message Forwarding Pro- tocol(Figure 10). The steps for S to deliver a message m to R can be concluded as following:
1. S finishes the steps described in Preparation Stage, with M0 ready.
2. S forwards M0 to N0.
3. N0 receives M0 and decrypts it with SK0 to retrieve id N1, CS,andinner message M1.
4. N0 forwards CS to S.
5. S receives CS,andverifiesCS,thenforwardsthefeedbackfS to N0.
6. N0 receives the fS. If fS is negative, abort the operation. Otherwise, N0 forwards M1 to N1.
7. N1 receives M1 and repeat steps 3 to 6 till Nk receives the fk 1 from Nk 1.
8. Nk forwards Mk to R based on fk 1.
9. R decrypts Mk with SKR to retrieve message m and Ck.
10. R forwards Ck to Nk,andreadsmessagem.
Notice that there is a Coin CS sending from N0 to S. The purpose of having this CS is to prevent N0 from suspecting that S is the originator of M0, which will provide more information regarding this communication. The same reason
24 goes for the presence of Ck.SinceCk is the last intermediate node, and R will be able to retrieve m anyway without sends Ck back to Nk.However,ifR does not give Ck to Nk, Nk can suspect that R can possibly be the destination of this communication. Compared to base version of Onion Routing communication model, OC’s model introduces 2 more messages for each hop on the path, one for the Coin, and one for the feedback, which eventually triples the total number of messages required to deliver m compared to the base version of Onion Routing. However, with these extra steps added to OC’s Message Forwarding Protocol,besides the incentives are provided for the helping peers, the anonymity of the commu- nication is also enhanced. The extra messages exchanged in every hop can also be considered as the cover traffics to introduce extra difficulty for adversaries to inspect the traffic and determine useful patterns to correlate the identities of the communicating nodes.
5.4 Failure on Delivery In OC, there is no protocols to detect the failure status or locate the exact position of broken point on the delivery path when there a message failed to reach its destination. It is not because that the communication model in OC is datagram(UDP) based, which by default there is no indicator on delivery status such as acknowledgement(ACK) expected by the message sender. The primary reason is that the message will be re-directed multiple times to hide the identity of the original sender S,andanykindofindicatordirectlyreportingbacktoS will compromise S’s cover of action. Also, due to the design of message encoding and encryption scheme, as well there is no easy design to decide where the failure report should go back to. Although, it is always possible to including extra information in the mes- sage for the purpose of failure detection or correction, this way will increase the chance for adversary to identify the communicating parties. For example, consider adding the steps in the protocol in which each intermediate node is able to maintain the status of the message delivered mapped to some ids. Once the failure case is suspected, such as no Coin has come from the next hop for alongtime,thenodecansendthespecialmessageFid indicating the failure to its previous hops with the identifier(id) of this communication, and then the previous hop can do the same until Fid finally back to the S.Basedonthe information included in Fid, S is able to detect the broken point of the path, and also knows which Coins are still valid to use. However, this protocol brings us back to the problem with incentives. In order for the peers to helping deliver Fid, providing the rewards are also necessary, which could potentially lead to double the number of Coins required from S.
25 6 The Ledger
The Ledger in OC represents the globally distributed database of all the trans- action records with three different types: Registration Record(RR), Coin Exchange Record(CE), and Coin Reward Record(CR). The Ledger adopts the BlockChain-like approaches, in which a block consists of multiple transaction records, and blocks are append-only to the Ledger. Each node is expected to have local copy of the Ledger,andthe"longestbranch"principleis applied when conflicts happen. The major difference between OC’s blockchain and the ones from other crypto-currencies [42, 34, 43, 44] is that the "mining" in OC can only be done by the Banks in current epoch. At the end of the epoch, the Banks will cooperate to generate a single new block containing all the transactions happened in current epoch. This approach is inspired by the idea of "leader" in BlockChain-NG [34], where only the leader nodes are able to mine the new blocks.
6.1 Records Although there are different types of transactions, the general format of them are the same. Each record consists of four segments: CONTENT, TIMES- TAMP(TS), SINGERS, and SIGNATURES(SIGS). TS is general UNIX time-stamp of 8 bytes in size. SINGERS are the list of strings representing the ids of CoSigners of this record, and the SIGS are the corresponding digital sig- natures on the hash of the CONTENT by these CoSigners. CONTENT is the only varying part in different type of records, and the details will be described in the following sections. When a record is added to a block, this record can be identified by the sha-256 sum of its CONTENT since all CONTENT could never be duplicated.
6.1.1 Registration Record The Registration Record(RR) is generated each time the Banks have ap- proved of registration of a new peer into the system. The CONTENT of RR is id of the new peer Nnew and the public key PKnew generated by Nnew. The membership in OC is only being verified by checking the existence of corre- sponding RR in the Ledger. Also, the positions of RRs in the Ledger are used when selecting the Banks.
6.1.2 Coin Exchange Record The Coin Exchange Record(CE) represents the action of marking the old Coin as invalid from the point this CE is added to Ledger, since the old Coin has been considered to be exchanged for a new Coin. However, the information of the new Coin is not recorded to protect the identity of the owner of the new Coin. The CONTENT in a CE is the data of a valid Coin as defined in earlier section. The generation of CE may not necessarily indicate the fact that a new
26 Coin has been generated due to the failure cases described in earlier section. Therefore, the purpose of having CE on the Ledger is only to record the usage of those old Coins to detect "double-spending" behavior.
6.1.3 Coin Reward Record A node can "redeem" its previous service to the community when serving as a Bank into new Coins. Every time a transaction is published, the ids of CoSigners are recorded in the record as well. Any of these CoSigners can later require a new Coin from one of these old records by requesting Banks for publishing a Coin Reward Record(CR). The CONTENT of CR includes the block depth(index of block on chain) in the Ledger, transaction hash, and node id. This information should only mark one of the CoSigners in one previous transaction record in one of the previous Blocks. The generation of CRs is crucial for the liveness of currency system since it is the only mechanism in OC to publishing new Coins.
6.2 Bank Selection In OC, the term epoch refers to a short time-interval whose length is determined at the boot time of the system. In each epoch, a subset of nodes will be selected to play the role as Banks(Figure 1). The Banks are not considered elected but instead selected automatically by the consistent hash function F . The definition of F is fixed at the boot time of OC, which will output certain number of ids. The parameters of F are epoch number ei,numberoftransactionrecordsgenerated in last epoch ei 1,andregisteredidsandtheirpositionsrelativetothebeginning of the Ledger.SincetheLedgerisconsistentglobally,theregisteredidsand their order of registration are also consistent to any nodes that has the main version of the Ledger. At the end of each epoch, with proper synchronization of the Ledger, every node is able to determine which nodes are going to be Banks in next epoch, therefore, no protocol for consensus or notification is required. Base on the fact that, majority of nodes will maintain the same version of the Ledger,thenthe majority of the nodes would have the same view of the choice of Banks for next epoch. However, the Ledger is so distributed that the synchronization may not always successfully happen, and as a result, less than majority of the nodes could have the same version. With static definition of F ,someformsofattackscouldbeperformedbythe adversaries to try to acquire the majority of the Banks in some epochs in order to collude and cheat on currency system. Although the definition of F is static, the parameters are changing dynamically overtime and therefore unpredictable unless the adversary is able to control the number of transactions happened in certain epochs.
27 6.3 Ledger Synchronization Protocol Like other BlockChain-based system, keeping the Ledger up to date is crucial to the operations involving accesses to the Ledger such as Bank Selection and Coin Verification. The synchronization among all the nodes is also the costliest part compared to other messages exchanged in OC. In OC, in order to improve the efficiency, the Block generation is limited only to the Banks in current epoch and the Normal Nodes are not required to have the new block until next epoch to fully operate since the information on the newest block is never accounted in any operation such as Bank Selection, and Coin Verification. The principle of performing synchronization of the Ledger is similar to the other BlockChain-based system, which is to try to locally store the chain of blocks with the longest branch. The branching could happen due to either the network failures, limited view in system, or simply a node is not operating during recent time intervals. In OC, even though the Block generation is epoch-based, in which only one block will be generated for each epoch, the branching could still occur due to similar reasons. For a node N0 with local Ledger L0 of depth d0 to synchronize L0 with another node N1 with Ledger L1 of depth d1. The general protocol goes as following. N0 sends SYNC request to N1 with payload including d0 and k hashes of the blocks in L0, hd k, hd k+1, hd k+2 ..., hd .WhenN1 receives 0 0 0 0 the SYNC request, five cases could happen:
1. d0 is same as d1 and all hashes on the same positions are same.
2. d0 is same as d1 but some hashes on the same positions are different.
3. d0 is greater than d1.
4. d0 is smaller than d1 and all hashes on L0 are same as the ones on L1 in same positions.
5. d0 is smaller than d1 but some blocks on L0 are different from the ones on L1 at same positions.
When N1 receives the request, it first compares d0 and d1. If d0 is the same as d1,thenN1 checks if all hd i are the same as hd i,ifyes(case 1), 0 1 N1 ignores the request. Otherwise(case 2), N1 also ignores the request since there is no way to tell which Ledger the main version is. If d0 is greater(case 3), N1 ignores the request. Otherwise N1 checks if all hd i are the same as 1 hd i. If true(case 4), N1 replies with blocks bd d , bd d +1, bd d +2,... bd . 0 1 0 1 0 1 0 1 Otherwise(case 5), N1 finds the first position p such that hd p is not equal to 1 hd p and replies with blocks bd p, bd p+1, bd p+2,...bd . 0 1 1 1 1 For example(Figure 11) as of case 5,considerN0 has a shorter Ledger with 3 Blocks with hashes h00, h01,andh02,andN1 has a longer one 5 Blocks with hashes h10, h11, h12, h13,andh14,assumingk =2. Then the synchronization protocol goes as follow:
1. N0 sends the d0 =3and hashes h01,andh02 as SYNC request.
28 Figure 11: Ledger Synchronization with d0 =3and d1 =5
29 2. N1 receives the SYNC request, and finds out d0 is smaller than d1.
3. N1 then checks h01(B89B32), and h02(7C290E)againsth11(B89B32), and h12(B9811E), and finds out that h12 is different from h02.
4. N1 replies with blocks b12, b13 and b14.
5. N0 receives the new blocks, and based on the depth of these blocks, N0 trims its chain by discarding b02 and append b12, b13 and b14 to L0 then update d0 to 5.
During the procedure that N0 sends the SYNC request to N1, N0 yet has no way to verify that the blocks from N1 are from the longest branch, and N1 also not guarantee to have the longest version of it. Therefore, N0 should request the blocks from multiple sources and possibly only append the most commonly occurred blocks. This problem yet will not affect the correctness of the other part of the protocols since the most recently generated blocks will not be expected to involve in the protocol and information from these new blocks should never be used for verification.
6.4 Block Generation At the end of every epoch, a new block containing of all the transactions pro- cessed in the current epoch is expected to be generated by the Banks of the current epoch. All the Banks are expected to cooperate to attempt to generate a new Block approved by majority. The generation of the new block can be split into three stages: (1)Proposing,(2)Pushing,andoptionally(3)Pulling. After finishing all three stages, every participated Bank is expected to hold the same version of the Ledger with new Block added.
6.4.1 Proposing Stage In Proposing Stage,eachBankgathersthedataofalltherecordsstored locally and sends them to all the other Banks with best effort. After receiving the transaction records from the other Banks, a Bank validates each of the records received by checking several things. First, whether all the CoSigners were selected as Banks in the epoch recorded. Second, whether the signatures on the hash of the CONTENT is correct. Finally, whether the CONTENT is plausibly correct, for example, if the Coin is valid and has not been used in a CE. Then every Bank adds all non-duplicate records received to its local transaction buffer. Two records are duplicated if the hashes of the CONTENT are the same, but the signatures and signers can be different. By the end of Proposing Stage, each Bank participated should have a same set of records. Although there could be failure cases in which some of the Banks may not have the full set of records, these Bank will not be considered having useful Block during Pushing Stage and they are able to detect this situation.
30 6.4.2 Pushing Stage Each Bank generates a new Block containing all the records from its local trans- action buffer, and sends the meta-data of this new Block to all of the other Banks. Upon receiving the information of the new Block from other Banks, each Bank keeps recording the frequency of distinct Blocks. At the end of this stage, each Bank should be able to determine which Block is being proposed by the majority of Banks which would be the Block that has the highest fre- quency. However, there could be the case that the majority cannot be formed, where multiple Blocks may all be considered as the major ones. In such case, the Block that has the highest hash sum value is considered as the one to keep. This method can be however replaced with other standard to resolve the conflict.
6.4.3 Pulling Stage At the end of the Pulling Stage, each Bank should have a Block generate locally, and the Bank also knows whether this Block is the major Block. If the local Block is not the same as the major one, the node will broadcast the request for Ledger SYNC, and the new Block will be pulled from whichever Bank that has this Block generated. This is the end of Pulling Stage, and also the end of the Block Generation Protocol. The other nodes in the system can expect to get a version of the newest block from any of these participated Banks, yet there is no guarantee that the block will be the major one. Therefore, it is recommended to attempt to retrieve the blocks from multiple Banks and the major block can be easily determined. Since the the Bank Selection Protocol is known globally, it is always feasible to request the blocks from the nodes that were playing as Banks from the last epoch.
31 7 Threat Case Analysis
OC’s primary feature is to provide anonymity to all the users regardless the roles the users are currently playing, yet the other security aspects such as message integrity, identity authenticity and privacy are also being covered. In order to state to compromise the anonymity of the communicating parties, the proof does not have to be perfectly gathered, for example, the adversary can prove that there is a message originated by sender S and it is eventually delivered to R and no further hops after R.Aslongasthereisevidenceindicatingthere is a message coming from S to R,theconnectionbetweenS and R then can be concluded and hence the anonymity is considered broken. In this section, multiple instances of different possible attacks on OC’s protection on anonymity of the users are analyzed.
7.1 Passive Threat on Messaging In the passive attacks, the adversary only means to inspect traffic and try to retrieve useful information to make connection regarding the message flows. The potential passive attacks in OC are very similar to the other Onion Routing based message passing [37, 35, 36, 38]. Although in OC, there may be two more message exchanges between a pair of hops, the overall behavior can still be reduced to fit the Onion Routing based model since the number of message exchanged between hops are considered consistent. However, there are extra dangerous cases in OC due to the addition of the currency system. In the following section, multiple cases of an instance of communication from S to R via k intermediate nodes N0, N1, N2 ... Nk 1 where 0 32 where S does not prove its identity authenticity, R cannot verify the originator of m and therefore the communication is considered failed. Now consider the scenario that the adversary has compromised one of Ni where 0 i 7.3 Multiple Malicious Intermediate Nodes In this section, the cases when there are multiple compromised intermediate nodes are discussed. The strength of protection on the anonymity relies on number of intermediate nodes, hence it is obvious that the more nodes that the adversary controls, the higher probability that the communication ends can be identified. However, the positions of compromised nodes on the path is also a dominating factor based on two interesting facts. First, a pair of non-adjacent nodes may correlate the traffic between them based on some factors such as packet size, timing, and frequency, and the chance of making correct conclusion increases as the length of the gap decreases. Second, only when both N0 and Nk 1 are controlled, the adversary has the opportunity to link S and R because 33 they are the only nodes directly contacting the sender or receiver. The best play for the adversary therefore is to control N0 and Nk 1 first and try to pick Nj’s (0 34 be guessed with the help of correlation in timing especially when there is little traffic coming from S. For example, with N0 and N2 controlled, the adversary has better chance conclude that there is message from N0 to N2 via N1 using traffic correlation. As for case (6), it lies between (4) and (5), in which the adversary would have higher chance finding the link between S and R if the positioning is more like the one in (5), and less chance it is like one in (4). In conclusion, to fully utilize the help from correlation, the adversary should try to create as many gaps on the path as possible yet also try to minimize the length of each gap. 35 8 Cheating on Currency In OC, the requirement on consistency regarding the currency is not necessarily as strong as those crypto-currency systems since the currencies in OC are not directly related to real world currencies. As a result, it is possible to cheat on currency system in OC with low probability if the adversary is able to con- trol large number of nodes. In this section, some cases regarding the potential cheating behaviors on the currency system are discussed. Like many other dig- ital currency systems, there are always attempts by the members to exploit the bugs in the system to make undeserved profits. The collusion is mostly an ef- fective way to acquire super power over the peers to go against the consistency of the system especially in decentralized environment, where the consistency is relied on some forms of consensus. In OC, such collusion is also possible since there are always multiple Banks behaving as the temporary authorities to co- ordinate the transactions on the Ledger. However, in such cases, the protection of the anonymity of the peers are not affected. Beside the collusion, the sender who pays to every helping peer may also cheat on the system to save some Coins. 8.1 Forging Coins and Records Since each record requires NC Banks to sign on it to make it valid and those Banks who signs will get rewards for signing this record, Banks can then play to sign as many records as they could to increase their profits. Yet, there is another method for Banks to get even more profits with less efforts, which is considering forging records or Coins. One Bank however cannot possibly forge anything since each record requires NC signatures, and NC should always be greater than one in practice. However, with at least NC colluding Banks, records can be forged. In the following paragraphs, the discussions about how Banks may collude to forge records and Coins, and how likely this collusion can happen are made. RR itself cannot be simply forged due to the assumption that no node can have multiple ids registered in OC, and CR cannot be forged as well due to that each CR claims a reward from previous records and the reward can only be used by its actual owner which is the Bank that signed this record. Therefore, only CE may be forged if enough Banks are colluding. However, each CE requires a valid Coin to be marked as spent, therefore, the essential question becomes is it possible to forge a valid Coin? A valid Coin also requires NC Banks in the same epoch to sign on it, therefore, if the adversary can control at least NC Banks in the same epoch, it is able to forge as many Coins as possible during this epoch. These Coins can be spent in the later epochs, and the forging can not be detected due to the feature that a Coin’s old owner is not linked to the new one. Now lets consider the probability that an adversary can control NC nodes that happen to be Banks in the same epoch. Since the Bank is assumed to be selected randomly and cannot be predicted, the probability that any node 36 #Nodes(n) #Banks(b) #CoSigners(c) p 10 5 3 0.08333333 10 5 5 0.00396825 10 7 3 0.29166667 20 5 3 0.00877193 20 5 4 0.00103199 100 5 3 0.00006184 100 5 4 0.00000128 100 10 3 0.00074212 100 20 3 0.00705009 16 10000 10 5 3.027 x 10 14 10000 20 5 1.862 x 10 26 1000000 10 5 3.024 x 10 Table 1: The probabilities that an adversary can forge Coins is selected as Bank is equal. Also, assumes that an adversary can compromise any node with equal probability. Let n be the total number of nodes in the system, b as the number of Banks selected in each epoch, and c as the number of CoSigner that the adversary can compromise, where b is always greater or equal to c,andb and c are smaller or equal to n. The question can then be reduce to a probability quiz question that what is the probability p that all c nodes selected from n nodes happen to be Banks given that there are b out of n as Banks? The solution is: bC b!(n c)! p = c = nC n!(b c)! c The value of p may not be very clear to tell given such formula in terms of multiple variables. Let consider some values of p in different examples with various n, b,andc selected, shown in Table 1. Although it is possible for the adversary to have multiple of nodes compro- mised and be able to forge many Coins, the probability that it could happen can be very small when either there are large number of total nodes or the number of CoSigners is large. Increasing the number of Banks selected in each epoch would increase this probability but the ratio of number of Banks to number of total nodes should be small in practice. On the other hand, this cheating be- havior once happens, would not harm the anonymity guarantees regarding any communications since no useful information is leaked from these forged Coins. As for the other honest peers, they also would not lose any deserved Coins since the forged Coins would not cost any Coins from these honest node. Therefore, a mechanism to full prevent this cheating behavior from happening is not designed in this paper but may be considered in the future works. 37 8.2 Cheating Sender and Intermediate Node As discussed in the Section 5.2 when developing the communication model from base version Onion Routing, sender is totally capable of cheating to save some Coins. However, the saving may cause the failure of message delivery or the exposure of anonymity. For sender S to deliver m to R through N0, N1 and N2, S should pay three Coins in total. With the Feedback step in the protocol, if S ever includes invalid Coins for any of N0 and N1, m will be failed to deliver with high probability. When the Coin for N2 is invalid, the success of delivery of m will not be affected, however N2 can suspect R as being the final destination of m, which lowers the difficulty for adversary find the links between S and R since one end of the communication is found. Another concern for sender to cheat is that whether S is able to use the Coin before any of Ni receives them. Due to the design that every Coin can only be exchanged by its owner, S once has prepared the Coins for Ni, S cannot re-exchanged them. Therefore, under any circumstance, the best play for S is to pay enough valid Coins for intermediate nodes. As for the intermediate nodes, the cheating behavior is also feasible but will not damage the system. One possible case is that when Ni receives Mi,itcan get Ci 1 by decrypting Mi,butNi can choose not to send Ci 1 back to Ni 1 and instead sending an invalid Coin to Ni 1 and ignore the feedback from Ni 1. Then Ni can continue deliver Mi+1 to Ni+1 and wait for Ci.Bydoingthisway, Ni 1 does not get a deserved reward but the message delivery is not affected. As for Ni,sinceCi 1 can only be used by Ni 1, Ni does not get an additional Coin, and therefore this cheating behavior is not beneficial to Ni. The same rationale goes for the case that Ni gives falsified feedback to Ni+1,inwhich Ni is not getting additional reward but may cause the overall message delivery failed. 38 9 Analysis of Encryption Steps In OC, the public key encryption and symmetric key encryption are used almost every time a message is sent to from one node to another. In the operations related to the currency system, there are even more encryption steps to suit different security requirement. However, the encryption itself is computationally expensive due to massive arithmetic operations. In this section, each encryption step will be discussed regarding its necessity and possible alternatives. 9.1 Encryptions in OMSG Every OMSG is designed so that only its designated receiver can decrypt it and has the accessibility to PAYLOAD. A common approach is that use the receiver’s public key to encrypt the message and then send to the receiver and no other peer is able to read it. The other approach is that performing Diffie- Hellman key exchange [41] between the sender and the receiver to negotiate a secret session key for encryption. The former approach is adopted in OC due to that identities of senders of any messages need to be verifiable as members in OC, and symmetric key encryption scheme cannot give such information regarding the identities of the key holders. However, the size of OMSG can be very large in some cases and the public key encryption is not efficient in such case, therefore the hybrid approach is applied to improve this encryption step. The OMSG will be encrypted using a one-time AES key first, and then the AES key is encrypted by the public key. For a registered node Ni to deliver an OMSG, the HASHSIG section is generated by signing the sha-256 sum of the payload with the private key SKi. The purpose of this signature is twofold. First, the receiver is able to verify that the sender is registered, and sender is who it claims to be. Since OC is designed to only provide services for members, the ability to verify the identity of the OMSG sender is a must. When N0 receives an OMSG from N1,despite the SENDERID is claimed to be as N0 in this message, N1 cannot confirm that it is actually sent by N0 rather than a spoofing node. Therefore, the proof of identity of N0 is required to be included in this OMSG, and like many other system, digital signatures are used here to provide such proof. Secondly, this signature also provides the evidence that the data in PAYLOAD is not corrupted or tampered. N1 should be able to compare the hash of the PAYLOAD against the value gained by decrypting HASHSIG with SKN0 to check if the PAYLOAD is not altered. 9.2 Encryptions in Protocols The encryption steps also happen in the process of some of the operations in various protocols. In the Message Forwarding Protocol, the message is to be wrapped multiple time as an onioned message, and then later this onioned message will be peeled multiple time as well. Also, during the Coin Exchange and CoSign Protocol, some public key encryption steps are there to protect 39 either the anonymity of the sender or to proof the authenticity and validity of the information being published. In the following sections, each of these encryption steps will be discussed. 9.2.1 Signatures In The Records For a record to be valid, it needs to contain multiple signatures from the Banks in the same epoch. In OC, the Banks act like the authorities to approve the transactions that Normal Nodes proposed. The Bank signs the CONTENT of a record to show their approval to this record, and the signatures are included in the record for other nodes to verify their validity. The signature is one step of public key encryption, and for every record there are then NC times encryption steps required. These signatures are necessary to validate a record, as well to protect the CONTENT of this record from being tampered. 9.2.2 Onioned Messages The layered public key encryption used in formatting the message being deliv- ered is mainly to guarantee that the intermediate nodes are not able to view the content of the original message so that the intermediate nodes cannot acquire useful information from the content to reveal the link between the sender and receiver. In OC, however, when such message is delivered in OMSG format, the en- cryption seems to be redundant due to that OMSG also encrypts the message, which means the message is encrypted twice to protect from being viewed. When an intermediate node receives the layered message, it needs to first decrypt the OMSG to see the PAYLOAD and then again it needs to decrypt the PAYLOAD to get the inner content which is also encrypted. Then the receiver needs to make another OMSG with the inner content and pass it to the next intermediate node. However, the steps regarding wrapping and peeling the onioned message cannot be removed even though the onioned message is within the OMSG. 9.2.3 Blind Signature As describe in Section 3.3 when a node N0 is doing Coin Exchange and with plain Raw Coin RCi, Bi can log RCi received from N0 to make guess about N0’s planned communication path. Therefore, N0 should always "blind" RCi before it goes to Bi.TheBlindSignatureisalsousingthepublickeyencryption to apply the blind factor the message and when removing the blind factor is also another step of public key encryption. The "blinding" is important for hiding the information regarding the new Coin which also indicates the N0’s possible future contacts. This step however cannot be replaced with other encryption scheme such as normal public key encryption or symmetric encryption since these scheme does not forbid the Bi to know the content of the message and also be able to have the signature from Bi. 40 #Messages : #Encryption Steps NACE OnionCoin 1. Split RC into NC pieces and blind 0:0 0:NC each piece 2. Send RC pieces to Banks NC : 0 NC : 0 3. Cost at Each Bank NC* NC* 3.1 Verify old Coin 0:NC 0:NC 3.2 Sign on RC or blinded RC piece 0:1 0:1 3.3 Reply to the requester 1:0 1:0 4. Unblind signed blinded RC pieces 0:0 0:NC Total Message Encoding 0:12NC 0:12NC Total without Encoding 2NC:NC2+NC 2NC:NC2+3NC Total 2NC:NC2+13NC 2NC:NC2+15NC Table 2: Number of Messages and Encryption Steps Summary for Coin Ex- change in OC compare with NACE 9.3 Analysis Summary In this section, the extra encryption steps and extra messages in some part of OC’s protocol are computed and summarized to demonstrate the extra cost using OC as a peer-to-peer anonymous messaging system with anonymous cur- rency exchange. Two protocols are mainly analyzed, Message Forwarding Protocol and Coin Exchange, which are the primary functionalities in OC. Each part of these protocol is compared with either an existing system or the simulated system for benchmarking purpose, so that the extra cost of using OC can be computed directly in terms of number of messages exchanged and en- cryption steps, which are the major contribution to degrade performance of the system. The following variables are used in the following sections for compu- tation, NC as number of CoSigners, NB as number of Banks, NN as number of total nodes, L as the number of nodes on the communication path (number of intermediate nodes plus one receiver and one sender). The OMSG encoding cost is fixed for each message, which is 6 encryption steps in total with 3 for encryption and 3 for decryption. 9.3.1 Extra Cost in Coin Exchange The Coin Exchange Protocol in OC is novel, and no other existing system has similar approach for anonymous currency exchange. Therefore, a simulated protocol named Non-Anon Coin Exchange(NACE) is proposed for bench- marking purpose. In NACE, an old Coin is also being exchanged for a new Coin with possibly different owner, and the content of Coin remains the same. The main difference in NACE is that the ownership exchange is no longer oblivi- ous, in which Banks can record these transactions in order to make assumption about a future message delivery by a specific node. The OMSG encapsulation is still required for confirming the former ownership of the old Coin is the same 41 #Messages : #Encryption Steps TOR OnionCoin 0. Initial Setup (circuit L2-3L+3:2*(L-2)2 (L-2) * CE building in TOR, and Coin Exchanges in OC) 1. Prepare Onion 0:(L-2) 0:2L-2 2. Cost at Each Hop (L-2)* (L-1)* 2.1 Peel Layer 0:1 0:1 2.2 Verify Coin 0:0 0:NC 2.3 Reply Coin backward 0:0 1:0 2.4 Send Feedback 0:0 1:0 2.5 Forward to Next Hop 1:0 1:0 Total Message Encoding 0:0 0:18L-18 Total without encoding L-2:2L-4 3L-3:(L-1)(NC+3) Total without Ini Setup L-2:2L-4 3L-3:(L-1)(NC+21) Total (L-1)2:2L2-6L+4 [3L-3:(L-1)(NC+21)]+(L-2)*CE Table 3: Number of Messages and Encryption Steps Summary for a Message Delivery through L intermediate nodes compared with TOR as the Coin Exchange requester. In NACE, when a node N0 wants to exchange Cold for Cnew, N0 first generate a Raw Coin RCnew and send it to at least NC Banks along with Cold.WhenBi receives RCnew, Bi verifies Cold and signs on the hash of RCnew,thenrepliesthesignaturetoN0. The difference in cost in each different step is shown in Table 2 in measures of number of operational messages and number of encryption steps. 9.3.2 Extra Cost in Messaging Since the Message Forwarding Protocol is very similar to the communication model in Onion Routing, TOR is used as the benchmarking model to compute the extra cost in OC to delivery anonymous message from one end to another with the extra features such as Coin rewards, and Feedbacks. As shown in Table 3, the extra cost in term of number of messages and number of encryptions including both symmetric and public key at each separate step are listed. In both model, there are initial setups before the sending the messages. In TOR, avirtualcircuitconsistingofL 1 node is built and the L 1 symmetric keys are negotiated using Diffie-Hellman key exchange [41] iteratively. In OC, the sender may need to perform L 1 Coin Exchange to get enough Coins. The extra steps in OC include OMSG encapsulation, Coin rewarding, Coin verification, and Feedback. The cost in OC also needs to consider the value of NC which is set as a parameter when the system boots. The cost of a single Coin Exchange can be found in Table 2 which is considered the minimal cost in the best case of a Coin Exchange. 42 10 Prototype Evaluation To evaluate OC’s performance, some scenarios are run with different system parameters. The primary goal of the following experiments is to show the per- formance variation of the message delivery in different scenarios with variable system parameters. The metrics of performance is not the end-to-end latency, but instead number of operational messages sent, and number of encryption steps are used to measure the performance. The system parameters of OC in- clude (1)Number of CoSigners(NC), (2)Number of Banks(NB) in each epoch and (3)Epoch Length(EL). In all of the following experiments, the total number of nodes(NN) in system is fixed at 20 and every node has full knowledge of ad- dressing the other nodes, which means the peer discovery cost is not considered as part of the performance cost in this paper. Also, every node is actively follow- ing the designed procedure, and no lazy nodes are present. The issues regarding the consistence of the Ledger is not covered during the following experiments, but the cost related are measured along with the other cost. 10.1 Implementation The prototype of OnionCoin system is implemented using Go in 2800 line of code. The implementation only uses Go’s standard libraries for all the function- alities. The source code is available on Github at www.github.com/rainer37/OnionCoin The public encryption, digital signature and Blind Signature are all using RSA scheme. The RSA key length is variable but should be at least 1024-bit. The symmetric encryption uses AES with 256-bit key. The hashing all uses SHA- 256, and UDP sockets for all communication. All of the following experiments are all running on one Ubuntu 17 desktop with quad-core Intel i7 3.7GHz CPUs and 12 GB of RAM. 10.2 Experiments The scenarios of the experiments go as below. Each node will start with the same initial Ledger including RRs of all 20 nodes, and the Routing Table containing full addressing information. Starting from an initial epoch, each node except the Banks will send a message to a random destination through a path of several nodes with random length(L) between 2 to 5 at random frequency less than half of the EL. Each node initially will hold several valid Coins owned by itself, and may need to perform Coin Exchange before sending a message. The experiments are mainly divided into three set based on the control variables, (1)with fixed EL and NB, varying NC, (2)with fixed NC and NB, varying EL and (3) with NC and EL fixed, changing NB. In the first set, different instances with NC varies from 1-5 are tested with EL as 20s and NB equal to 5, shown in Figure 12 and Figure 13. In the second set, 10s, 15s, 20s, 25s, 30s, 40s and 60s are used for EL where NC = 3 and NB = 5. In the third set, NC 43 104 · 6.5 #messages 6 5.5 5 4.5 4 Number of Messages 3.5 3 2.5 2 1 1.5 2 2.5 3 3.5 4 4.5 5 Number of CoSigners(NC) Figure 12: Number of Messages To Deliver 1000 message as Number of CoSign- ers changes 44 105 · #encryption 2 1.8 1.6 1.4 1.2 1 0.8 Number of Encryption Steps 0.6 0.4 0.2 1 1.5 2 2.5 3 3.5 4 4.5 5 Number of CoSigners(NC) Figure 13: Number of Encryptions To Deliver 1000 message as Number of CoSigners changes 45 105 1.01 · #messages 1.01 1.01 1 1 Number of Messages 1 1 1 10 20 30 40 50 60 Length of Epoch(EL) Figure 14: Number of Messages To Deliver 1000 message as length of Epoch changes 46 104 4.4 · #encryption 4.3 4.2 4.1 4 3.9 Number of Encryption Steps 3.8 3.7 3.6 10 20 30 40 50 60 Length of Epoch(EL) Figure 15: Number of Encryptions To Deliver 1000 message as length of Epoch changes 47 105 1.05 · #messages 1.04 1.03 1.02 1.01 1 0.99 Number of Messages 0.98 0.97 0.96 0.95 3 4 5 6 7 8 9 10 Number of Banks(NB) Figure 16: Number of Messages To Deliver 1000 message as Number of Banks changes is set to 3 and EL as 20s, with NB varies from 3 to 10. For each instance of experiments, the system is kept running until a total 1000 messages have been successfully exchanged, and then the statistics are collected from 20 nodes. The stats including number of messages exchanged related to the message delivery but not one with the Ledger synchronization or record CoSigning. Also, the stats do not include the encryptions in formating OMSG, since every message will have such cost and eventually they will be canceled out. 10.3 Evaluation As shown in Figure 12 and Figure 13, the number of messages is growing linearly as NC increases from 1 to 5, which is as expected since the total number of messages is related to NC due to the cost of Coin Exchange is proportional to NC. As for the number of encryption steps, this number grows super-linearly as NC increases. This growth is also within the expectation range since this cost is also related to NC due to Coin Exchange and Coin Verification. In Figure 16, 48 104 4.4 · #encryption 4.3 4.2 4.1 4 3.9 Number of Encryption Steps 3.8 3.7 3.6 3 4 5 6 7 8 9 10 Number of Banks(NB) Figure 17: Number of Encryptions To Deliver 1000 message as Number of Banks changes 49 Figure 17, Figure 14 and Figure 15, as NB and EL vary, there are no significant changes in both number of messages and number of encryptions. This behavior is also the same as expected since, the cost of delivery is not directly related to either NB or EL. The value of NC is the dominating parameter in OC in almost every part, although in some operations, the Banks are not involved in the messaging, but the operations such as Coin Verification or record validation also requires NC times encryptions. The experiment does not cover the performance related to the record CoSigning or Ledger synchronization, but it is obvious that NC is also the key factor that affects the performance significantly. Therefore, in the future work, reducing the cost of the operations related to NC is the primary alternatives to consider to improving the performance and the scalability. 50 11 Limitation and Future Work OC’s communication model lacks some functionality that provide features for reliable, fast, and lightweight messaging delivery. Although the anonymous messaging system always brings in more overhead to protect user’s privacy or security, message delivery in OC introduce even more steps in order to integrate the currency system to provide just incentives for its users. While maintaining the ability for the currency system to provide useful information such as currency status and authorized identities, there are overhead in different part of OC’s protocol which either would introduce additional latency, or use extraneous space such as keep the Ledger. In this section, these limitations are discussed and some more features are proposed for future improvement consideration. Besides the limitations regarding communication, there are also limitations related to the currency system, such as low utilization of Coins. 11.1 Unidirectional Message OC is considered as a messaging system that can only deliver a message to the destination, and if the receiver node needs to reply to the sender, it will be considered as another message delivery originated by the receiver node. In TOR, the communication tunnel is designed to be bi-directional based on TCP for multi-purpose message delivery. For example, an HTTP request may be sent by the sender through the circuit and its replies may come back using the same circuit, which comparing to OC, makes TOR is convenient for different forms of communication. This limitation in OC however is not related to the network protocols chosen for delivering data, but due to the principle in OC that every peer needs to "pay" for the service. Therefore, an instance typical request-response communication has to be considered as two separate messages deliveries in OC to properly handle the Coin rewards. 11.2 Delivery Failure Detection OC should not be considered as a reliable messaging system since there is no failure detection or correction protocols to try to ensure the success delivery of a message. In OC, the sender of a message has no ability to detect the failure during the delivery or the ability to confirm that the receiver has received this message. As proposed in the previous section, the intermediate nodes are able to keep recording the status of delivered messages, and once the failure is found by any of intermediate nodes, this failure status including the position of the broken point can be reported back to the previous hops recursively till the sender node. This mechanism however is not adopted by OC also for that this failure detection can also be considered as a service which should require the payment. Therefore, the future design regarding the failure detection will have to consider embedding rewarding Coins in such status reporting messages in order to provide incentives. 51 11.3 Performance as of a Messaging System In terms of being a messaging system, the major functionality is to deliver and receive the message, and preferably secure and fast. In terms of security, OC has covered almost every aspect, such as data integrity, authenticity, and anonymity. However, the performance of OC is not as acceptable as the other low-latency anonymous messaging systems such as TOR. The performance is- sue also happens in TOR’s case for the same reasons, multiple hops, multiple encryption, and more network failing points. While due to the addition of cur- rency system in OC, the steps that cause longer latency are mostly expensive public key encryption/decryption to provide security protection. As describe in Section 9.3, the additional cost for each hop on the communication path is still constant but is greater than the ones in TOR. However, the cost for sender can be significantly increased as NC goes up since each rewarding Coin has the overhead of doing a Coin Exchange by the sender. 11.4 Re-usability of a Coin As defined in Coin Exchange protocol, a Coin CN0 can only be exchanged by its owner N0 to another Coin with different ownership such as N1.However,after the Coin’s owner becomes N1, N0 cannot exchange it again although this N0 deserves this Coin. This may cause the new Coin to be invalid if the new owner is no longer using the system, in which N0 loses a Coin and cannot get it back. Also, similar problem also happens during the Coin Exchange. By the design of protocol, N0 should present a valid Coin CN0 along with Raw Coin pieces to Banks, and whenever a Bank can verify that CN0 is valid, it may start CoSign protocol to generate according CE record. This becomes a problem when there are not enough Banks available in current epoch to help N0 to get a new Coin, the CN0 may also used by the Banks for generating CE to get rewards. As a result, N0 loses CN0 since it has been marked as used and does not get a new Coin as return. However, this problem does not have an easy fix since this feature is also the one that ensures there is no linkage between a Coin’s previous owner and its new owner, and also ensures when the sender cannot cheat on forwarding nodes. For example, assume a Coin can be exchanged by any node holding it. In such case, after a sender S prepares the message M with valid Coins and send M to the first intermediate node, S then can start to exchange those Coins wrapped in M. As a result, these intermediate nodes may still believe the Coins are valid and provide help for the message delivery. In another case, assume that when Banks receive CN0 from N0 requesting for an exchange, Banks have to wait for a proof or notification from N0 indicating that N0 successfully gets enough signature from Banks and a new Coin is made. Nevertheless, N0,foritsbest interest, may not want to give such proof, so that N0 can still use CN0 and also gets a new Coin. Such behavior would waste the effort of these Banks. 52 11.5 Features in Future Work The cost of maintaining the Ledger can be significantly high for that the content of obsolete information on the Ledger is unlikely to be useful but still have to occupy space to provide global consistency. This problem also occurs for other Block-Chain based system for verifiable source of transaction, yet in OC this may be easier to solve since the full history of transactions is not always required. Another reason is that the number of Blocks is known based on the current epoch number. The only type of record should remain on the Ledger is the RR, since RRs will always be used for Bank Selection and id authentication. As for CE and CR, as long as the rewards have all been collected by the CoSigners, the full information of these records are not required in the future. Therefore, one approach can be applied to save the disk space when storing the Ledger. build two separate Chains, one for RR only and the other for CE and CR. The RR Chain remains using same way to maintain. CE and CR now can be expired so that the old Blocks in the earliest epochs can be either compressed or trimmed to save space. In current version of OC, there is only one currency unit as Coin, and any payments or earnings take exactly one Coin. The amount of work done therefore is not proportional to its payment amount, which would cause unfairness in some situation. For example, the size of message varies significantly from one to another, and sending these messages will consume different amount of resource. The "pay" and "gain" therefore are not proportional which cannot fully utilize the incentives provided by the currency system. An obvious solution would be to introduce more currency units for finer payment amount arrangement. The payment and earning then can be varying according to the type of service and the amount of resource required to finish the operations, such as size of bytes delivered, encrypted, or stored. Two possible challenges when dealing with multiple possible currency are (1) publishing the payment plan anonymously and (2) preventing the adversary correlating the amounts of payments to the corresponding operations. 53 12 Related Works There are numerous proposed designs of system regarding anonymous communi- cation, and based on the primary technology used for security concerns, they can be divided into following categories: Private Information Retrieval(PIR) based, Mixnet-based, Dinning Cryptographer(DC-nets), and protection on Network- level, in which some of these systems use a combination of multiple techniques. However, it is hard to compare OC with any of those systems since OC is pri- marily adjusted for the purpose to support currency system for incentives, and techniques for ensuring anonymous communication has no difference from Onion Routing. Therefore, in the following sections, the features of these systems are discussed to see whether they can be used to improve OC or whether the idea of incentive can be applied in these systems, instead of comparing OC to those system in aspects of performance and security. PIR-based systems [29, 30, 28, 27, 14] are primarily used to pull information from untrusted database without exposing user’s identity and content retrieved with high probability. In OC, the routing information of the other nodes are not always publicly available or accurate in real time, hence sometime the peer discover is required. However, this procedure may also introduce potential leaks to adversary learning about one node’s intention by analyzing its recent queries for peers similar to the directory attacks in TOR. Therefore, PIR is a candidate technique to replace OC’s routing information retrieval protocol since the goal of PIR is to protect the content of the query from untrusted queried peers. DC-nets systems [19, 20, 21, 22, 31, 27] allow a group of users to exchange anonymous message within the group using broadcast. Although DC-net would provide stronger anonymity for its members yet in peer-to-peer environment, the cost to maintain all the group member for participation is expensive and this assumption does not seem reasonable for improvising communication. How- ever, considering using incentive system to encourage peer to be more willing to participate could be the solution resolving such issue. Assuming a member would require spending coins for communication and for the other idle nodes, the presence of them would reward them with some coins. Some group members in DC-net can simply participate to provide the covers to the other members who are actually communicating in order to earn the currency for future use, and the number of members in the group therefore may remain large enough to provide strong security. In Mixnet-based systems [5, 6, 8, 9, 10, 11, 14, 15, 13, 3], a group of mix nodes play as the relays to collect messages from users and then shuffle these messages and forward through other mix nodes till delivering to the final destination. The system topology and type of roles of nodes in Onion Routing system and Mixnet are very similar. The messages in both systems are being re-directed multiple time to hide its real path from source to destination, and there are nodes as intermediate mix to handle the re-direction of the messages. However, the Mixnet would provide stronger anonymity against traffic analysis attacks compared to TOR and OC, with the drawbacks that for Mixnet as a messaging system, each mix node will have to collect enough number messages 54 before sending towards next nodes, which could introduce much unnecessary latency due to lack of activities in some periods of time. Therefore, Mixnet is better for the system that would wait for enough messages collected, such as anonymous voting system. 55 13 Conclusion In order to address the "free-riders" issues in peer-to-peer anonymous messag- ing system, in this paper, a peer-to-peer anonymous messaging system named OnionCoin is designed to support anonymous digital currency for incentives without introducing extra potential security leaks regarding Onion Routing dur- ing the communication. The currency system is built upon Block-Chain based global database called the Ledger to store currency transactions and the mem- bership information, and there are Bank Nodes acting at temporary authorities to perform currency-related operations. In the Ledger, a record requires to be signed by multiple CoSigners to prevent forging records. Several protocols are proposed for different security purposes in OC. OC adopts Onion Routing-like style for layered message encryption and communi- cation model using public keys from different selected users. A derived version of this communication model is designed to provide rewards for the forwarding nodes while delivering the message without adding additional threats to the anonymity of communication ends. Also, a Coin Exchange protocol using Blind signature to ensure the new ownership of the Coin is not known to any other users in OC. There is additional cost in performance of message delivery, in which there are about two more messages exchanged for each forwarding nodes and number of encryption steps added is quadratic to number of CoSigners. 56 References [1] Roger Dingledine, Nick Mathewson, and Paul Syverson. 2004. Tor: the second-generation onion router. In Proceedings of the 13th conference on USENIX Security Symposium - Volume 13 (SSYM’04), Vol. 13. USENIX Association, Berkeley, CA, USA, 21-21. [2] Michael J. Freedman and Robert Morris. 2002. Tarzan: a peer-to-peer anonymizing network layer. In Proceedings of the 9th ACM conference on Computer and communications security (CCS ’02), Vijay Atluri (Ed.). ACM, New York, NY, USA, 193-206. [3] Jelle van den Hooff, David Lazar, Matei Zaharia, and Nickolai Zeldovich. 2015. Vuvuzela: scalable private messaging resistant to traffic analysis. In Proceedings of the 25th Symposium on Operating Systems Principles (SOSP ’15). ACM, New York, NY, USA, 137-152. [4] Nirvan Tyagi, Yossi Gilad, Derek Leung, Matei Zaharia, and Nickolai Zel- dovich. 2017. Stadium: A Distributed Metadata-Private Messaging System. In Proceedings of the 26th Symposium on Operating Systems Principles (SOSP ’17). ACM, New York, NY, USA, 423-440. [5] Chaum, D., Javani, F., Kate, A., Krasnova, A., de Ruiter, J., Sherman, A.T. and Das, D., 2016. cMix: Anonymization by high-performance scal- able mixing. 25th USENIX Security Sym-posium. [6] Chaum, D.L., 1981. Untraceable electronic mail, return addresses, and dig- ital pseudonyms. Communications of the ACM, 24(2), pp.84-90. [7] Jerichow, A., Muller, J., Pfitzmann, A., Pfitzmann, B. and Waidner, M., 1998. Real-time mixes: A bandwidth-efficient anonymity protocol. IEEE Journal on Selected Areas in Communications, 16(4), pp.495-509. [8] Danezis, G. and Laurie, B., 2004, October. Minx: A simple and efficient anonymous packet format. In Proceedings of the 2004 ACM workshop on Privacy in the electronic society (pp. 59-65). ACM. [9] Wikström, D., 2004, February. A universally composable mix-net. In The- ory of Cryptography Conference (pp. 317-335). Springer, Berlin, Heidel- berg. [10] Danezis, G., Dingledine, R. and Mathewson, N., 2003, May. Mixminion: Design of a type III anonymous remailer protocol. In Security and Privacy, 2003. Proceedings. 2003 Symposium on (pp. 2-15). IEEE. [11] Rennhard, M. and Plattner, B., 2002, November. Introducing MorphMix: peer-to-peer based anonymous Internet usage with collusion detection. In Proceedings of the 2002 ACM workshop on Privacy in the Electronic Society (pp. 91-102). ACM. 57 [12] Clarke, I., Sandberg, O., Wiley, B. and Hong, T.W., 2001. Freenet: A dis- tributed anonymous information storage and retrieval system. In Designing privacy enhancing technologies (pp. 46-66). Springer, Berlin, Heidelberg. [13] Le Blond, S., Choffnes, D., Zhou, W., Druschel, P., Ballani, H. and Fran- cis, P., 2013, August. Towards efficient traffic-analysis resistant anonymity networks. In ACM SIGCOMM Computer Communication Review (Vol. 43, No. 4, pp. 303-314). ACM. [14] Sassaman, L., Cohen, B. and Mathewson, N., 2005, November. The pyn- chon gate: A secure method of pseudonymous mail retrieval. In Proceedings of the 2005 ACM workshop on Privacy in the electronic society (pp. 1-9). ACM. [15] Danezis, G. and Goldberg, I., 2009, May. Sphinx: A compact and provably secure mix format. In Security and Privacy, 2009 30th IEEE Symposium on (pp. 269-282). IEEE. [16] Angel, S. and Setty, S.T., 2016, November. Unobservable Communication over Fully Untrusted Infrastructure. In OSDI (pp. 551-569). [17] Gelernter, N., Herzberg, A. and Leibowitz, H., 2016. Two cents for strong anonymity: The anonymous post-office protocol. Proceedings on Privacy Enhancing Technologies, 2, pp.1-20. [18] Chen, C., Asoni, D.E., Barrera, D., Danezis, G. and Perrig, A., 2015, Oc- tober. HORNET: High-speed onion routing at the network layer. In Pro- ceedings of the 22nd ACM SIGSAC Conference on Computer and Commu- nications Security (pp. 1441-1454). ACM. [19] Chaum, D., 1988. The dining cryptographers problem: Unconditional sender and recipient untraceability. Journal of cryptology, 1(1), pp.65-75. [20] Golle, P. and Juels, A., 2004, May. Dining cryptographers revisited. In International Conference on the Theory and Applications of Cryptographic Techniques (pp. 456-473). Springer, Berlin, Heidelberg. [21] Corrigan-Gibbs, H. and Ford, B., 2010, October. Dissent: accountable anonymous group messaging. In Proceedings of the 17th ACM conference on Computer and communications security (pp. 340-350). ACM. [22] Wolinsky, D.I., Corrigan-Gibbs, H., Ford, B. and Johnson, A., 2012, Octo- ber. Dissent in Numbers: Making Strong Anonymity Scale. In OSDI (pp. 179-182). [23] Goel, S., Robson, M., Polte, M. and Sirer, E., 2003. Herbivore: A scalable and efficient protocol for anonymous communication. Cornell University. [24] Sirer, E.G., Goel, S., Robson, M. and Engin, D., 2004, September. Eluding carnivores: File sharing with strong anonymity. In Proceedings of the 11th workshop on ACM SIGOPS European workshop (p. 19). ACM. 58 [25] Soska, K., Kwon, A., Christin, N. and Devadas, S., 2016. Beaver: A De- centralized Anonymous Marketplace with Secure Reputation. IACR Cryp- tology ePrint Archive, 2016, p.464. [26] Kwon, A., Corrigan-Gibbs, H., Devadas, S. and Ford, B., 2017, October. Atom: Horizontally scaling strong anonymity. In Proceedings of the 26th Symposium on Operating Systems Principles (pp. 406-422). ACM. [27] Corrigan-Gibbs, H., Boneh, D. and Mazières, D., 2015. Riposte: An Anony- mous Messaging System Handling Millions of Users. IEEE Security and Privacy. [28] Cheng, R., Scott, W., Parno, B., Krishnamurthy, A. and Anderson, T., 2016. Talek: a private publish-subscribe protocol. Technical Report. Uni- versity of Washington. [29] Kwon, A., Lazar, D., Devadas, S. and Ford, B., 2016. Riffle. Proceedings on Privacy Enhancing Technologies, 2016(2), pp.115-134. [30] Borisov, N., Danezis, G. and Goldberg, I., 2015. DP5: A private presence service. Proceedings on Privacy Enhancing Technologies, 2015(2), pp.4-24. [31] Corrigan-Gibbs, H., Wolinsky, D.I. and Ford, B., 2013, August. Proac- tively Accountable Anonymous Messaging in Verdict. In USENIX Security Symposium (pp. 147-162). [32] Castro, M. and Liskov, B., 1999, February. Practical Byzantine fault toler- ance. In OSDI (Vol. 99, pp. 173-186). [33] Kogias, E.K., Jovanovic, P., Gailly, N., Khoffi, I., Gasser, L. and Ford, B., 2016, August. Enhancing bitcoin security and performance with strong consistency via collective signing. In 25th USENIX Security Symposium (USENIX Security 16) (pp. 279-296). [34] Eyal, I., Gencer, A.E., Sirer, E.G. and Van Renesse, R., 2016, March. Bitcoin-NG: A Scalable Blockchain Protocol. In NSDI (pp. 45-59). [35] Evans, N.S., Dingledine, R. and Grothoff, C., 2009, August. A Practical Congestion Attack on Tor Using Long Paths. In USENIX Security Sympo- sium (pp. 33-50). [36] Jansen, R., Tschorsch, F., Johnson, A. and Scheuermann, B., 2014. The sniper attack: Anonymously deanonymizing and disabling the Tor network. OFFICE OF NAVAL RESEARCH ARLINGTON VA. [37] Murdoch, S.J. and Danezis, G., 2005, May. Low-cost traffic analysis of Tor. In Security and Privacy, 2005 IEEE Symposium on (pp. 183-195). IEEE. [38] Sun, Y., Edmundson, A., Vanbever, L., Li, O., Rexford, J., Chiang, M. and Mittal, P., 2015, August. RAPTOR: Routing Attacks on Privacy in Tor. In USENIX Security Symposium (pp. 271-286). 59 [39] Douceur, J.R., 2002, March. The sybil attack. In International workshop on peer-to-peer systems (pp. 251-260). Springer, Berlin, Heidelberg. [40] Chaum, D., 1983. Blind signatures for untraceable payments. In Advances in cryptology (pp. 199-203). Springer, Boston, MA. [41] Diffie, W. and Hellman, M., 1976. New directions in cryptography. IEEE transactions on Information Theory, 22(6), pp.644-654. [42] Nakamoto, S., 2008. Bitcoin: A peer-to-peer electronic cash system. [43] Wood, G., 2014. Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper, 151, pp.1-32. [44] Miers, I., Garman, C., Green, M. and Rubin, A.D., 2013, May. Zerocoin: Anonymous distributed e-cash from bitcoin. In Security and Privacy (SP), 2013 IEEE Symposium on (pp. 397-411). IEEE. [45] Stoica, I., Morris, R., Karger, D., Kaashoek, M.F. and Balakrishnan, H., 2001. Chord: A scalable peer-to-peer lookup service for internet applica- tions. ACM SIGCOMM Computer Communication Review, 31(4), pp.149- 160. [46] Zhao, B.Y., Kubiatowicz, J. and Joseph, A.D., 2001. Tapestry: An infras- tructure for fault-tolerant wide-area location and routing. [47] Maymounkov, P. and Mazieres, D., 2002, March. Kademlia: A peer-to-peer information system based on the xor metric. In International Workshop on Peer-to-Peer Systems (pp. 53-65). Springer, Berlin, Heidelberg. [48] Heilman, E., Kendler, A., Zohar, A. and Goldberg, S., 2015, August. Eclipse Attacks on Bitcoin’s Peer-to-Peer Network. In USENIX Security Symposium (pp. 129-144). 60