more for networking pages
This commit is contained in:
@@ -1,5 +1,8 @@
|
||||
# Network Components
|
||||
|
||||
TODO add whitepaper ref
|
||||
TODO new diagram
|
||||
|
||||
Core components:
|
||||
* A **Mixnet**, which encrypts and mixes Sphinx packet traffic so that it cannot be determined who is communicating with whom. Our mixnet is based on a modified version of the [**Loopix** design](concepts/loopix). This is made up of [Nym nodes](architecture/mixnet/nodes) runnning on servers around the world.
|
||||
* Various [**Nym clients**](architecture/mixnet/clients) which manage sending and receiving Sphinx packets, encrypting/decrypting traffic, and providing [cover traffic](../concepts/cover-traffic) to hide 'real' traffic timing.
|
||||
|
||||
@@ -1,9 +1,14 @@
|
||||
# Anonymous Replies using SURBs
|
||||
SURBs ('Single Use Reply Blocks') allow clients to reply to incoming messages anonymously.
|
||||
|
||||
> SURBs are pre-computed Sphinx packet headers encoding a mixnet route that ends in the participant that created the SURB. A sender can generate one or more SURBs and include them in their Sphinx message to a recipient. The recipient can use the SURBs as Sphinx headers to send back replies – or acknowledgements – that anonymously reach back the original sender after going through the mixnet.
|
||||
>
|
||||
> SURBs are the Sphinx equivalent of "onion addresses" in Tor, with the caveat that a SURB can only be used once (to prevent replay attacks) and within its epoch of validity (the mix node public keys used to prepare the SURB are only valid for a limited period). SURB headers are encrypted by the sender, so the recipient sending it back cannot infer from it any information about the message route, the per-hop latency, or the sender’s address, which is encoded in the innermost (last) routing layer of the SURB. SURBs ('Single Use Reply Blocks') allow clients to reply to incoming messages anonymously.
|
||||
>
|
||||
> [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) §4.5
|
||||
|
||||
It will often be the case that a client app wants to interact with a service of some kind, or a P2P application on someone else's machine. It defeats the purpose of the whole system if a client app needs to reveal its own gateway public key and client public key in order to get a response.
|
||||
|
||||
Luckily, SURBs allow for anonymous replies. A SURB is a layer encrypted set of Sphinx headers detailing a reply path ending in the original client's [Nym address](../traffic/addressing-system). SURBs are encrypted by the client, so the recieving service/app can attach its response and send back the resulting Sphinx packet, but it **never has sight of who it is replying to**.
|
||||
Luckily, SURBs (Single Use Reply Blocks) allow for anonymous replies. A SURB is a layer encrypted set of Sphinx headers detailing a reply path ending in the original client's [Nym address](../traffic/addressing-system). SURBs are encrypted by the client, so the recieving service/app can attach its response and send back the resulting Sphinx packet, but it **never has sight of who it is replying to**.
|
||||
|
||||
MultiSURBs were implemented in `v1.1.4`. Clients, when sending a message to another client, attach a bundle of SURBs which can be used by the receiver to construct large anonymous replies.
|
||||
|
||||
|
||||
@@ -1,4 +1,11 @@
|
||||
# Loopix
|
||||
|
||||
> Hiding "who messages whom" is a necessary mixnet property in terms of metadata protection – but it is not always sufficient to prevent surveillance. Adversaries that observe the volume and timing of sent and received messages over time may still be able to infer private information, even if individual messages are strongly anonymized. Detailed data on the volume and timing of user interactions leaks information over time about which services the user accesses and the patterns of usage of such services. If the user engages in persistent behavior (e.g., always messaging the same friend or always accessing the same service), communication profiles may leak over time and be recoverable through long-term statistical disclosure attacks. Mixnets – including classical Chaumian batch mixnets – provide unlinkability, but do not provide unobservability. In order for access to Nym to be unobservable, the adversary should not know when or how much actual traffic is being sent or received by a participant.
|
||||
>
|
||||
> Cover traffic disguises real traffic patterns by adding “dummy” messages that carry no payload data and are simply discarded at their final destination. While routing a message, mix nodes cannot distinguish whether it is a dummy message or a normal message carrying user data. Routing dummy traffic to circle back to the sender rather than ending at a randomly chosen destination was originally proposed to proactively detect active attacks on mixnets. Loopix, the name of which refers to its use of "loops" of dummy traffic, extends this approach to guarantee both a lower bound on anonymity and unobservability properties for end users. Nym follows a similar approach, with participants generating dummy messages that travel in a loop and have themselves as final destination.
|
||||
>
|
||||
> [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) §4.6
|
||||
|
||||
The Nym Mixnet is based upon the [Loopix](https://arxiv.org/pdf/1703.00536) design.
|
||||
|
||||
This design lays out a stratified design of several layers of Mix Nodes and Gateways in which:
|
||||
|
||||
@@ -6,8 +6,13 @@
|
||||
|
||||
Mixnets are networks of nodes that route traffic in a way that makes it untraceable, even for Global Passive Adversaries employing Machine Learning to try and deanonymise traffic based on timing and fingerprinting attacks.
|
||||
|
||||
One of the key features of a Mixnet - unsurprisingly - is that these nodes 'mix' traffic. As traffic moves through the network, each node, on receiving a message, will wait a variable length amount of time before sending it onwards - aka nodes do **not** pass messages on in a FIFO manner.
|
||||
One of the key features of a Mixnet - unsurprisingly - is that these nodes 'mix' traffic. As traffic moves through the network, each node, on receiving a message, will wait a variable length amount of time before sending it onwards - aka nodes do **not** pass messages on in a FIFO manner. An easy analogy is each node constantly receiving and sending out cards, shuffling their local deck each time and randomly selecting a card to pass along in the chain of messages.
|
||||
|
||||
> An easy analogy is each node constantly receiving and sending out cards, shuffling their local deck each time and randomly selecting a card to pass along in the chain of messages.
|
||||
The Mixnet employs continuous-time mixing, in which each message is dealt with independently of the other messages in the node's local storage. This is in contrast to other Mixnet designs which rely on nodes sending out periodic bursts of accrued messages, such as the Chaumian Mixnet design _"which collects a number of input messages and outputs a random permutation of those messages, is known to suffer from some disadvantages: the end-to-end latency of messages in such mixnets is neither bounded nor predictable, and the bursty communication caused by periodically flushing batches of messages makes these mix designs inefficient at utilizing bandwidth. In terms of anonymity, simple batching strategies are known to offer low anonymity as well as being particularly vulnerable to attacks"_ ([Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) §4.4)
|
||||
|
||||
The Mixnet employs continuous-time mixing, in which each message is dealt with independently of the other messages in the node's local storage. This is in contrast to other Mixnet designs which rely on nodes sending out periodic bursts of accrued messages.
|
||||
Continuous-time mixing, in contrast:
|
||||
- _"offer[s] optimal anonymity properties for a given mean end-to-end latency"_ due to the per-message randomised delay amount: by using an exponential delay distribution, we acheive a situation in which _"if we observe two messages going into the mix node at times t0 < t1, and a message coming out at a later time t2, the probability that the output is any of the two inputs is equal, regardless of
|
||||
differences in their arrival times t0 and t1."_
|
||||
- offers a larger anonymity set than Chaumian batch Mixnets such as [Elixxir](https://learn.xx.network/) due again to the exponential delay distribution: _"even if most delays will be short, there is a non-zero probability that a message will incur a large delay; therefore, the adversary cannot discard future mix output messages as candidates for an input it wants to trace"_
|
||||
- allows nodes to send data more efficiently by continously sending/receiving packets.
|
||||
- allows for a lower overall latency due to not having to wait for batches to be filled before messages are sent through to the next hop.
|
||||
|
||||
@@ -8,8 +8,8 @@ Even if the content of a network request is encrypted, observers can still see t
|
||||
|
||||
The Nym mixnet provides very strong security guarantees against this sort of surveillance. It _packetises_ and _mixes_ together IP traffic from many users inside the _Mixnet_. It does this by obfuscating and anonymising traffic patterns: hiding the signal in background noise. It aims to make passive network surveillance obselete by hiding who is talking to who at any one time at the _network level_; using an anonymous email service, even one paid for anonymously, is not enough to protect you from surveillance unless you are also hiding your IP and other metadata which can be used to deanonymise you over time. We are up against agencies and companies employing enourmous compute resources scraping the web for swathes of traffic information and piping this into Machine Learning algorithms.
|
||||
|
||||
## Mixnet TL;DR TODO ADD LINKS ALL THROUGHOUT
|
||||
The Mixnet is a decentralised network of nodes run by various operators in various jurisdictions around the world, who are incentivised to do so via `NYM` token rewards: cryptocurrency allows for the creation of an incentivised network of decentralised privacy architecture.
|
||||
## Mixnet TL;DR
|
||||
The Mixnet is a decentralised network of nodes run by various operators in various jurisdictions around the world, who are incentivised to do so via `NYM` token rewards: cryptocurrency allows for the creation of an incentivised, decentralised privacy network.
|
||||
|
||||
> If you're into comparisons, the Nym mixnet is conceptually similar to other systems such as Tor, but provides improved protections against end-to-end timing attacks which can de-anonymize users. When Tor was first fielded, in 2002, those kinds of attacks were regarded as science fiction. But the future is now here.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user