sign in sign up
<<
Home , Facebook Messenger, Ricochet (software), Signal (software), Tox (protocol)

Proceedings of the 52nd Hawaii International Conference on System Sciences | 2019

ATHiCC: An Anonymous, Asynchronous, Serverless Protocol

Daniel F. Balchasan Michal Ozaniak Yoav Schwartz Nicolai S. Steffensen Aalborg University Aalborg University Aalborg University Aalborg University [email protected] [email protected] [email protected] [email protected]

Samant Khajuria Lene T. Sørensen Aalborg University Aalborg University [email protected] [email protected]

Abstract by default can, and do, collect ‘metadata’. This metadata includes, but is not limited to, the Instant messaging has become a main form of sender, receiver, and location of the message. communication between people. The ability to Therefore, even though the content of the message is instantly send to each other, even when the secure, enough information can be deduced with the recipient is offline, has become second nature and is metadata to undermine the user’s . taken for granted in modern society. However, this is Chat software that do put encryption and privacy not without a cost. In the case of instant messaging, at the top of their priority, like , get attacked that cost is privacy. Service providers use centralized by governments [7], and users are getting blocked servers to store these messages and can collect from the service. This is relatively easy to achieve information using the messages ‘Metadata’ or even through the ISPs [8], since they can be forced to block read the contents of messages. This paper presents a access to the servers that host the chat service. novel protocol, ATHiCC (Asynchronous Hidden These points have led the authors to conclude that Chat Communication) [1] that allows private and there is a need for a fully distributed, autonomous anonymous communication that doesn't require a instant messaging software that would be secure, , and yet is still able to support asynchronous private and anonymous, so that no user data can be communication. A simulator was implemented to test collected. the protocol and performance under various network There are applications [9][10] that do provide these conditions and topologies. The results of the requirements, however they are not widely used as simulation predict high delivery rates and low delays they are less usable than their popular counterparts and in message delivery under most conditions, even in users often choose what they deem is secure enough small network topologies. over a more secure option that is less usable [11]. One of the main features missing from these programs, is one we take for granted in modern 1. Introduction communication systems, namely, the ability to send messages in an asynchronous manner when the Privacy is a fundamental human right, as recipient is offline. This is because they rely on Peer- recognized by the UN Declaration of Human Rights to-Peer communication between clients which makes [2] and yet, recent events make it clear that it challenging to support asynchronous features. users right to privacy is being violated. Governments The goal of this paper is to suggest a protocol that are collecting more information than ever [3] and supports asynchronous messaging while being private, some of the biggest companies in the world use users’ secure and fully distributed. This work is done by personal data as a financial model e.g. and designing a protocol that uses other users in the . network, in a unique fashion, while relying on the Facebook, the biggest social network in the world, characteristics of Tor onion services to deliver which was involved in a scandal leaking millions of asynchronous messages. The protocol is then tested users’ details [4], has one the most popular instant using a simulation software developed to test the messaging applications on the market [5]. In protocol’s performance under varying conditions. “Messenger”, Facebook’s instant messaging The outline of this paper is as follows; in Section application [6], conversations are not end-to-end 2, an overview of related work is presented. In Section encrypted by default, meaning Facebook can read the 3 the conceptual framework around the protocol is laid majority of messages sent. out. Section 4 and Section 5 give the background and Even chat services that do implement end-to-end

URI: https://hdl.handle.net/10125/59942 ISBN: 978-0-9981331-2-6 Page 5049 (CC BY-NC-ND 4.0) details of the protocol. Section 6. contains the 2.3. methodology for the simulation, and in Section 7 the results of the simulation are presented. Finally, Section Tox [9] is an encrypted instant messaging protocol, 8 and Section 9 discuss the considerations made in the which provides peer-to-peer communication. It works design process and possible future work. by creating a network of users, who via an anonymous identifier connect and send messages to each other. 2. Related Work The protocol employs perfect , just like does. Much work has been put into developing solutions Tox doesn’t natively support asynchronous for secure and private end-to-end encrypted messages, it only implements a ‘pseudo-offline’ communication. Many of these approaches either offer message [19], where a message is stored locally at the high levels of security and , but with a low user, until both are online. Third-party developers number of features with respect to messaging. Others have tried to solve this issue of Asynchronous offer many features, but lower levels of security and messaging in two different ways: Relay through anonymity. another user and relay through a decentralized server, called ‘supernodes’. None of the presented solutions combine both high 2.1. levels of security and the possibility to send asynchronous messages and to the best of the authors Ricochet [10] is an example of a chat application knowledge, no other current solution on the market which offers high-level security and anonymity by offer this. In this paper, such a solution will be utilizing Tor [12] and Tor Onion Services [13]. It presented. utilizes end-to-end encryption and guarantees that only the sender and receiver can read the content. 3. Conceptual Framework By utilizing Tor Onion Services, it also eliminates any possibility that an entity can gather metadata or track who send which message. Furthermore, the In this section we will present some of the concepts application works autonomously without the need of and terms needed in order to understand the design and any kind of servers for routing or connecting peers, functionality of the solution presented in this paper. since this is done by the Tor network. This means no one can track who is using the application, as all Tor 3.1. Tor traffic is indistinguishable [14]. This level of security and anonymity does come with a downside as One of the main requirements set for the protocol Ricochet only works when both parties are online at is anonymity. In the context of this paper, maintaining the same time. anonymity means not disclosing any information which may indicate the identity of the user or their 2.2. Signal location, namely the IP address of the device. It was decided that the IP address would be kept private by designing the protocol over an Onion Signal is a chat protocol, developed by Open Routing network [18]. Whispers Systems in 2013 [15] and implemented into [20] provides anonymous routing a number of different chat applications like, Signal of data over the internet, by encapsulating data packets [16], WhatsApp [17], secret conversations in (including the IP layer headers) in encryption layers and in incognito like an onion (hence the name). These packets are then mode [18]. It offers a high level of security by enabling sent through multiple proxies (Onion Routers), each end-to-end encryption, with a different for each removing a layer of encryption until the clear-text message. Providing perfect forward secrecy, so that if packet is sent by the last proxy to the destination. one key is lost, no other messages can be decrypted. The Onion Routing network selected for the In Signal all messages are sent to a server, making protocol is Tor [12], due to the scale and performance. it possible to send messages to users who are offline. In order to open secure connections over the Tor This doesn’t allow the server to see the content of the network, first a list of onion routers must be retrieved messages, but all metadata can be collected. Signal is from a . Using this list, three therefore considered as a secure, but not a private chat random onion routers are picked which will function protocol. as proxies. Shared keys are then negotiated via

TLS/SSLv3 with each of the onion routers and a path

(tunnel) in the network is created.

Page 5050 When using Tor onion routing, even though the 3.3. Centralized/decentralized/distributed base packets are sent over TCP/IP, they cannot be traced back to their source, even by the receiver of the Centralized Systems are systems which rely on a packet. However, as the packets leave the last leg of single entity for decision making, such as a server. the path unencrypted, the payloads of said packets are This means that one entity (or a group of entities acting not kept secure. as one) provides a critical service for the function of the system. 3.2. Tor Onion Services

Onion services [13] is a feature of the Tor network. Previously known as ‘Hidden Service’, Onion Services allow devices to provide services over the Tor network, without revealing their IP addresses, and thus their location. Onion services are made possible by having the service provider join the Tor network. This is done by the service creating a public-private key pair and an Onion address, as a subset of their public key. This Onion address is then published on the Tor distributed hash table, as well as addresses of other nodes known Figure 2: Difference between centralized, as ‘introduction points’ (IP). The IP make it possible decentralized and distributed networks. to reach the Onion service provider, by forwarding Centralized systems, in server- paradigms, packets through previously defined Tor connections to are very common, as they are easy to maintain, manage and provide easy control of the system. the service provider. Using the IP, a ‘Rendezvous Point’ (another Tor router) is agreed upon, and Tor Decentralized system are systems where a subset connections and established to it by the requester and of the entities provides services and decision making the service provider. to the rest of the network. These service-providing entities work independently of each other. Distributed systems are systems where all entities are equal. There are no nodes who are more ‘important’ than other, and decision making is made on the individual level.

3.4. Synchronous/asynchronous

The basic functionality of any messaging application can be split into 2 kinds of messages. Synchronous and asynchronous messages.

Figure 1: Communication from a client to a Tor Synchronous communication refers to data sent while Onion Services, by using a rendezvous. the recipient of the data is active and available. This means that in order to be able to use the service, both Onion services provide multiple benefits to normal sender and receiver of the messages must be ‘online’ onion routing. First, they provide end-to-end address at the time of sending the messages. and payload encryption. Second, they don’t require Asynchronous messages refer to data which is sent that the sender of a packet know the IP address of the while the recipient is not available. This data will be receiver. Instead they use Onion addresses which received by the recipient when, or shortly after, cannot be traced back to their owner. Third, by coming online. After sending the messages, 3rd parties implementing Onion services on both communicating provide services to ensure message delivery. parties, a full duplex communication can be implemented which only sends packets through the 4. Synchronous messaging Tor network, without sharing anything more than randomly generated Onion addresses. The first, and simpler, aspect of the ATHiCC protocol relates to synchronous messages. These messages are to be sent directly, and as quickly as possible, to the other side of the conversation.

Page 5051 Due to the requirement of ATHiCC to be 5.1. Double addresses serverless, synchronous messages are sent in a peer- to-peer method. As with traditional P.O Boxes, every which In order to allow connections between nodes in the provides messages hosting services has a unique network, while maintaining anonymity, ATHiCC uses identifier. In ATHiCC, this unique identifier is an Tor Onion Services in order to establish the Onion Address, used in order to access the Onion connections. In order for a node to use the protocol, service offered by the P.O Box. they must create an Onion Service, and therefore However, the Onion address of a node is also used generate an Onion Address. The Onion Address is then in order to send ‘Contact requests’ and messages to exchanged off- with other users who wish to each node. In order to provide privacy and avoid social communicate over the protocol. In the asynchronous engineering techniques, such as phishing, the messaging section, this Onion Address is referred to as ATHiCC protocol defines both a private and a public the ‘private address’. onion address for each node. The private address is Whenever a node requests to open a session (start shared and used for Synchronous messaging and a conversation) with another node, the former must use ‘Contact requests’, while the public addresses are only the latter’s Onion Address in order to contact them. used for providing P.O Box services. Once the Tor connection is established, and a By defining a public and private address for each connection request is received, the receiver node, the protocol also maintains privacy of addresses authenticates the requester’s Onion Address. If the in small networks where the topology could be address is approved by the receiver, a communication inferred due to the distribution of P.O Box addresses. channel is established. After the first time an address is approved, 5.2. The P.O box solution subsequent connections will be accepted with an ‘already known’ response in the authentication The P.O Box solution provides Asynchronous process. Once 2 nodes have performed the first messaging by utilizing message hosting services authentication and connection, they are considered provided by other nodes in the network. ‘contacts’ of each other. As every node has their own Onion Service, they can be contacted, and receive connection requests (‘Contact’ requests) from any other node who has their Onion Address. Therefore, the Onion Address should be kept private and shared only with contacts one wishes to establish connections with. Once the ‘contact’ relationship is established, the nodes are able to freely send packets over a TCP connection through a secure tunnel created by the Tor network.

Figure 3: First step of asynchronous messaging. 5. Asynchronous messaging The first step of the Asynchronous messaging The main difficulty of sending Asynchronous starts with each node performing a ‘P.O Box messages in a distributed system comes from the need association’ process, in which a node (the ‘P.O Box’) of 3rd party services for hosting of messages between agrees to provide message hosting services for another sending and delivery, as there are no entities in the node (the ‘Receiver’). This association process network which guarantee their availability (as is produces a P.O Box Token, which contains needed common in centralized and decentralized networks). information such as P.O Box address, association The solution proposed in this paper was named the unique identifier and proof of ownership of the token. ‘P.O Box’ solution due to its similarity to services In order to increase the reliability of the protocol, offered by the Post Office. In this solution other nodes each Receiver node performs P.O Box association in the network provide message hosting services while processes with multiple nodes, and thus has multiple the recipient is offline. P.O Boxes to use. Figure 3 depicts the first step of the This section will describe the solution designed to asynchronous messaging process. provide the Asynchronous messaging features of Once a P.O Box association process is complete, ATHiCC. the Receiver node publishes their Token (excluding the proof of ownership) to all their contacts, informing

Page 5052 them of the P.O Boxes the Receiver node is using. Token publishing is performed synchronously whenever nodes connect for the first time or whenever they have a synchronous connection. Token publishing is also performed Asynchronously when a new P.O Box association is performed. Figure 4 depicts the second step.

Figure 6: Fourth step of asynchronous messaging.

In order to address the potential of missed messages, the protocol includes a process for repeating previously sent messages in a sliding window, as well as a synchronous ‘Synchronization’ process used to exchange previously missed messages, once Sender and Receiver are online at the same time. Figure 4: Second step of asynchronous Finally, in order to address potential misuse of the messaging. protocol, it defines methods for ranking and ‘blacklisting’ nodes based on their success rates and By presenting the Token to the P.O Box the Sender misuse. Identification of misuse is done using shows proof that they are allowed to upload confirmation receipts from the P.O Box to the Sender, Asynchronous messages to P.O Box, addressed to the which are then presented to the Receiver during the owner of the token. In order to increase the reliability synchronous ‘Synchronization’ process. of the protocol, the Sender will upload the same message to multiple P.O Boxes used by the Receiver. 5.3. Distribution

The distributed nature of the solution presents a major challenge. As there are no central entities in the network, the only nodes known to each node are those they know as ‘Contacts’. Relying on contacts alone to perform P.O Box services would mean a low reliability for nodes with few contacts, as well as breach the privacy of the users by publishing a list of their contacts as P.O Boxes. In order to allow any node to perform the role of P.O. Box for any other node, the protocol defines a Figure 5: Third step of asynchronous messaging. propagation method for addresses. This process allows the public addresses of nodes to be published Once messages are uploaded to the P.O Box, the throughout the network, so they may provide services Receiver node is able to collect them at any time the to previously unknown nodes. P.O Box is online. Once the Receiver node comes To support address propagation, the protocol relies online, they query all their online P.O boxes for on the publishing of Tokens, used as part of the messages, presenting the ‘proof of ownership’ agreed asynchronous messaging process. As each Token upon during the association process. Until all P.O includes the public address of the P.O, contacts of a boxes have been queried, the Receiver node would specific node learn the public addresses known by that continue to query them at fixed intervals. node. Once they learn a new public address, they may The protocol relies on probability. Out of the list of initiate P.O Box association with that node as well, P.O. Boxes used by the Receiver, at least one P.O Box depending on their current need for more P.O Boxes. would need to be online both at the time of sending the Otherwise, the contacts would add the address to their message and while the Receiver is online next. By list of ‘known P.O Boxes’. Figure 7 shows the adjusting the number of P.O Boxes used by the nodes, propagation of addresses by Token publishing. a balance between reliability and network load can be achieved.

Page 5053

This method has a weakness in small, closed networks of contacts. Should a small number of nodes all share the same connections to other nodes, the only nodes available to propagate are in that subset. However, once the small network is connected to another network through any node, all connected Figure 7: Propagation of P.O. Box addresses by addresses should spread. Figure 8 shows the states for Token publishing. a small network before and after connecting to a larger network though a single node. This behavior is As each node in the network shares its own P.O simulated in the simulation when address propagation Boxes, the addresses would propagate throughout the is looked into. connected network graph. In order to facilitate the spread of addresses, and to distribute the load on the 6. Simulation different nodes, P.O Box associations are maintained for a fixed period of time. Once an association ‘times To test that the protocol works and scales, independent out’, a new node is selected at random from the list of of the network size, or , a known public addresses, with exclusion of addresses verification or test method is needed. We have which are ‘blacklisted’ or have previously shown low identified two key aspects of the protocol to test which reliability, when compared to the other known nodes. are needed to assess its viability. These are the ‘messages sent and receive success rate’, and the ‘propagation of P.O. Box addresses’. For this purpose, a network simulation was designed and implemented [21]. The simulation was designed to test several hypotheses. These hypotheses helped scope the simulation and focused the analysis of the data, as well as assessing if the simulation worked as expected. For the analysis, we assumed that the simulation worked as expected, meaning no errors or bugs in the code were present to an extent where the data would be corrupted. The hypotheses were split into two different parts: Propagation of P.O. Box addresses and Asynchronous message delivery. Where only one hypothesis was tested regarding P.O. Box address propagation and several regarding Asynchronous message delivery. Below are the hypotheses that were tested:

1. The average number of known P.O. Box addresses will increase over time. 2. The more time users spend online in a given period, the higher percentage of Asynchronous messages will get delivered. 3. The more time users spend online in a given period, the faster Asynchronous messages will be delivered. 4. The more P.O. Boxes a user sends an Asynchronous message to, the higher percentage of the messages will get delivered. Figure 8: States of a small network before (A) and 5. The more P.O. Boxes a user sends an after (B) connecting to a larger network. Asynchronous message to, the faster the messages will arrive.

Page 5054 Figure 9: Average number of known P.O. Box addresses at each phase

In the simulation two types of datasets were used. First, a small star topology was generated. It was used to test that the protocol could work in small topologies, 6.2. Data output and for testing Asynchronous messaging success rates. A small topology is sufficient as the size of the The simulator takes a configuration file as an input. network is not a significant factor for messages. This This configuration file includes the global variables is due to the limited number of nodes involved in that affect the behavior of the network or the nodes. asynchronous message sending, in contrast to address These configurations control for example the topology propagation. to use, online frequency for the nodes and the number For large scale testing, mainly to test P.O. Box of P.O. Boxes to use. propagation, it was necessary to get a topology that is For each of these configuration inputs, the large enough and made up of different sub topologies. simulation outputs data. First, is every message that In order to best simulate the behavior of a system was sent including its origin, target, sent time and based on the THiCC protocol in a real-world optionally received time. With this data, it is possible environment, the network topology should resemble a to determine the success rate of messages sent, as well real-world network as closely as possible. as the average time a message takes to arrive. Second, Furthermore, it needed to be temporal, meaning the simulation outputs which P.O. Boxes were known new connections between nodes are timestamped. This to which nodes and at what time-point. Using this is so we can observe the graph growth over time and information, it is possible to map out the rate and simulate how a network would grow. Since an instant efficiency at which P.O. Boxes propagate through the messaging is made up of friends or people who have a system. relationship, it would likely take a similar topology to a social network, which is a complex network [22]. 7. Results There are two ways to get such a topology: generate one using an algorithm; or use an existing topology. First, we set out to test the hypothesis regarding the To make sure the simulation is as close to reality as propagation of P.O. Box addresses throughout a large possible, a real network topology was used from the network. To test this hypothesis, a simulation was run Digg social network [23]. The Digg topology is made on a large-scale network, using a topology from a up of millions of nodes, so a slice in time was used social network site. The iteration when an address was instead of the full topology. shared to each node was logged and grouped into 10 In a real scenario, every node in the network is a equal phases (for ease of analysis). real person with a different use case and behavior, Figure 9 shows the average number of P.O Box mostly different online times and online periods. In the addresses known by the nodes in the network, over the simulation all P.O. Boxes and clients share the same ‘phase’. One phase is simply a tenth of the iterations. overall online time statistics. This also means that the As seen in Figure 9, the results of the simulation algorithm for prioritizing P.O. Boxes was not support the first hypothesis that he ‘the average implemented since its irrelevant to prioritize identical number of known P.O. Box addresses will increase nodes. over time’, by showing that average known number of P.O. Boxes increases steadily over the separate phases. This suggests that given enough time, a large network which is structured and grows like a real social

Page 5055 network would allow the nodes to learn new addresses. online ratios.

The results of the simulation suggest that a network with nodes which is spend less time online are less likely to be able to send the messages at all. Further analysis shows that any message which has failed to upload was attempted during the first quarter of the simulation. This suggests that this behavior is caused by a low propagation of P.O Box addresses in the early stages of the network. These final two hypotheses consider the number of P.O. Boxes used in the delivery of messages. The expectation is that the more boxes used, the higher the Figure 10: Delivery percentage (blue) and chance the messages will be delivered and the less message delivery time (red) by differing online time it would take. Figure 12 shows the delivery ratios percentage and message delivery time by the number of P.O. Boxes used by each message. The second and third hypothesis refer to the online As expected, the observation shows that an time or ‘online ratio’. For this purpose, the simulation increase in the number of P.O. Boxes used has an included several test runs. Each run was configured to impact on both the message delivery time and delivery run with identical configurations, with the only percentage. The higher the number of P.O. Boxes difference being the ‘online ratio’ (the percentage of used, the more reliable and the higher performance time the node spends online in a period). The you get from the protocol in terms of delivery expectation is that the longer a node is online, the percentage and message delivery time. better chances it has to deliver a message and will therefore do so faster. As seen in Figure 10, the delivery percentage increases and the message delivery time decreases as the online ratio increases. This means that the more time a node spends online, the more likely it is for that node to receive the asynchronous messages sent to it, and the faster it will receive them. These observations support the hypothesis presented earlier and suggests that the simulation behaves as expected.

Another consideration is what happens when a Figure 12: Delivery percentage (red) and message node wanted to send an asynchronous message, but it delivery time (blue) by different number of P.O. did not have any online P.O. Boxes to deliver the Boxes used. message to. This would not register as a message that was sent and not delivered, it would instead not be sent To support this observation, a significance test was at all. However, for the receiving node the result is conducted which shows that the delivery percentage similar, where the asynchronous message did not and message delivery time’ are significantly** come across. Figure 11 illustrates how many messages different from all the values being equal. Furthermore, failed to upload to P.O Boxes at all at each different no significant difference could be found from online ratio. choosing four, five or six P.O boxes. In addition, a F- test showed significant** difference between three and four P.O Boxes used. This suggests that four P.O. Boxes is fitting number for the configuration, given the other configurations used. The hypothesis which were presented and analyzed were helpful to determine how the protocol behaves in a simulated environment, and the review the reliability of the simulator to work as expected. In addition to reviewing the way the nodes using the protocol can send and receive messages, the overall performance of the protocol can be reviewed. As seen the in previous Figure 11: Upload failed percentage over different figures, the protocol can reach message delivery

Page 5056 probabilities of about 98-99% in the simulated The authors are aware that this protocol might be environment, depending on the configurations used. used by individuals with malicious intents, to While this does not guarantee a reliable communicate and plan, limiting the possibilities law performance in a real-life environment, it suggests that enforcement agencies might have. We believe that it is the protocol could work and is worth further impossible to create technologies which is only used investigation. for good intents and this protocol is no different.

8. Discussion 9. Conclusion and Future Work

In this research paper we have presented a novel, In this paper, a design of an instant messaging fully distributed, private and anonymous instant protocol is described. The was to allow messaging protocol, which also supports asynchronous messaging while also maintaining asynchronous messaging. This protocol is built on top privacy, anonymity, security and availability of the of Tor onion services. system for the users. After the protocol was designed, Analyzing the results of the simulation, we predict a simulation was performed, and the results show that that the protocol will perform with a high degree of the protocol performs as expected, even under strained reliability and low delays in delivering messages. conditions. However, since the protocol doesn’t use name servers In the future, we would seek to add the ability to due to the requirement of full distribution, different conduct group chats as we deem this the most networks of users are not forced to merge, and important feature to allow a software based on the therefore, situations may occur where a network is too protocol to compete in the current market of instant small to have enough P.O. boxes to provide the messaging applications. This is however, technically redundancy needed for high degrees of reliability. challenging, as currently, asynchronous group However, this is a small limitation, as the protocol is encryption remains an unsolved problem if we exclude designed to ensure that once any node in a network N times protocols where a with each connects to a node from a different network, the P.O. person in the group is required. This is especially true box addresses will propagate. without a central entity like a server. However, future To verify and test the protocol, we used a work on the MLS protocol [26] may prove to be a simulation software, intended to test the key aspects of possible solution. the protocol such as the P.O. box propagation and message delivery rates and delays. However, the 10. References simulation is implemented such that all the nodes have the same Online/Offline characteristics. This means all [1] D. Balchasan, N. S. Steffensen, . Ozaniak, nodes, on average, are online the same proportion of and Y. Schwartz, “ATHiCC - Asynchronous the simulation time (but not necessarily the same Tor Hidden Chat Communication,” times). This behavior is unlikely in a “real life” Copenhagen, 2018. environment, where users have varying behaviors and [2] The , Universal Declaration patterns, and it may be worth running the simulation of Human Rights. 1948. with real user online time data. Yet, we predict it [3] S. Landau, “Making Sense from Snowden: would not vary the results significantly. What’s Significant in the NSA Surveillance Another consideration was whether or not to Revelations,” IEEE Secur. Priv., vol. 11, no. formally verify the protocol [24][25]. On the one hand, 4, pp. 54–63, 2013. verifying the protocol could definitely prove the it [4] K. Granville, “Facebook and Cambridge would work, on the other hand, it would not indicate Analytica: What You Need to Know as anything about performance, which is critical in this Fallout Widens,” , 2018. case, and therefore a simulation was chosen. [Online]. Available: An implementation of ATHiCC would surely be in https://www.nytimes.com/2018/03/19/technol a context, where total anonymity and high levels of ogy/facebook-cambridge-analytica- security is required. Such implementations would explained.html. [Accessed: 22-May-2018]. include messaging software for intelligence services [5] “Most popular 2018,” and undercover journalist, for whom being anonymous Statista, 2018. [Online]. Available: and hidden might in extreme cases mean the difference https://www.statista.com/statistics/258749/m between life and death. Military use would also be ost-popular-global-mobile-messenger-apps/. suitable case, in times when existing network [Accessed: 13-Jun-2018]. infrastructure can be used. [6] “Messenger.” [Online]. Available:

Page 5057 https://www.messenger.com/. [Accessed: 13- Networks,” Nature, vol. 410, no. 6825, pp. Jun-2018]. 268–276, Mar. 2001. [7] T. Warren, “Russia orders immediate block [23] “Digg,” 2018. [Online]. Available: of Telegram messaging app,” , 13- http://digg.com/. [Accessed: 22-May-2018]. Apr-2018. [24] R. Lai and A. Jirachiefpattana, “Protocol [8] M. Dornseif, “Government mandated Verification,” in blocking of foreign Web content,” CoRR, Specification and Verification, Boston, MA: vol. cs.CY/0404, 2004. Springer US, 1998, pp. 143–163. [9] “Tox,” 2018. [Online]. Available: [25] M. G. Gouda, “Protocol verification made https://tox.chat/. [Accessed: 22-May-2018]. simple: a tutorial,” Comput. Networks ISDN [10] “Ricochet.” [Online]. Available: Syst., vol. 25, no. 9, pp. 969–980, 1993. https://ricochet.im/. [Accessed: 13-Jun-2018]. [26] R. Barnes, J. Millican, E. Omara, K. Cohn- [11] W. Bai, M. Namara, Y. Qian, P. G. Kelley, Gordon, and Robert. R, “The Messaging M. L. Mazurek, and D. Kim, “An Layer Security (MLS) Protocol,” 2018. Inconvenient Trust: User Attitudes toward Security and Usability Tradeoffs for Key- Directory Encryption Systems,” in Twelfth Symposium on Usable Privacy and Security ({SOUPS} 2016), 2016, pp. 113–130. [12] “Tor.” [Online]. Available: https://www.torproject.org/. [Accessed: 17- Dec-2017]. [13] “Tor - Onion Service.” [Online]. Available: https://www.torproject.org/docs/onion- services.html.en. [Accessed: 17-Dec-2017]. [14] G. Owen and N. Savage, “Empirical analysis of Tor Hidden Services,” IET Inf. Secur., vol. 10, no. 3, pp. 113–118, 2016. [15] “.” [Online]. Available: https://signal.org/blog/advanced-ratcheting/. [Accessed: 17-Dec-2017]. [16] “Signal.” [Online]. Available: https://signal.org/. [Accessed: 17-Dec-2017]. [17] “WhatsApp.” [Online]. Available: https://www.whatsapp.com/. [Accessed: 17- Dec-2017]. [18] “Google Allo - A smart messaging app.” [Online]. Available: https://allo.google.com/. [Accessed: 13-Jun-2018]. [19] “Tox Wiki - Offline Messaging,” 2018. [Online]. Available: https://wiki.tox.chat/users/offline_messaging. [Accessed: 22-May-2018]. [20] M. G. Reed, P. F. Syverson, and D. M. Goldschlag, “Anonymous Connections and Onion Routing,” IEEE J. Sel. Areas Commun., vol. 16, no. 4, p. 15, 1998. [21] R. M. Fujimoto, K. Perumalla, A. Park, H. Wu, M. H. Ammar, and G. F. Riley, “Large- scale network simulation: how big? how fast?,” in 11th IEEE/ACM International Symposium on Modeling, Analysis and Simulation of Computer Systems, 2003. MASCOTS 2003., 2003, pp. 116–123. [22] S. H. Strogatz, “Exploring Complex

Page 5058