first pass concepts
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
# Core Concepts
|
||||
There are a lot of moving parts with the Nym system, conceptually and otherwise. This section contains an overview of the main concepts, as well as links to further literature.
|
||||
@@ -0,0 +1,7 @@
|
||||
{
|
||||
"mixing": "Packet Mixing",
|
||||
"loopix": "Loopix",
|
||||
"cover-traffic": "Cover Traffic",
|
||||
"epochs": "Epochs",
|
||||
"anonymous-replies": "Anonymous Replies"
|
||||
}
|
||||
@@ -0,0 +1,12 @@
|
||||
# Anonymous Replies using SURBs
|
||||
SURBs ('Single Use Reply Blocks') allow clients to reply to incoming messages anonymously.
|
||||
|
||||
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**.
|
||||
|
||||
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.
|
||||
|
||||
If a reply is too large still (i.e. it would use more SURBs than sent with the original message), the receiver will use a SURB to ask the sender for more SURBs.
|
||||
|
||||
You can read more about SURBs in §4.5 of the [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf).
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
# Cover Traffic
|
||||
|
||||
> The Nym mixnet generates cover traffic "loops" as described in Section 4.6. Loops generated by mix nodes ensure a minimum level of anonymity at all times, while end users can generate loops to obfuscate the timing and volume of their active communication through Nym and thus achieve unobservability.
|
||||
>
|
||||
> [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) §4
|
||||
|
||||
TODO
|
||||
|
||||
An in-depth explainer can be found in §4.6 of the [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf).
|
||||
@@ -0,0 +1,7 @@
|
||||
# Loopix
|
||||
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:
|
||||
- Traffic path selection is chosen independently per-message, unlike designs such as Onion routing.
|
||||
- Messages are routed through an ingress Gateway, 3 layers of Mix Nodes, and an egress Gateway, where each node is connected only to adjecent layers.
|
||||
- Continuous-time mixing is employed, wherein connected clients and nodes continuously generate packets that are sent into the network. This generation can by modeled by a Poisson process. Whether a packet contains a user-defined payload or not defines the difference between 'real' and 'cover' traffic but it is impossible to make this distinction by just monitoring the traffic flow itself by an observer.
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
# Packet Mixing
|
||||
|
||||
> Continuous-time mixing strategies ... delay each message independently, forwarding it to its next destination once a specified delay has timed out. The aggregate effect of independently delaying each message is an output sequence of messages that is randomly reordered with respect to the input sequence.
|
||||
>
|
||||
> [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf) §4.4
|
||||
|
||||
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.
|
||||
|
||||
> 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.
|
||||
|
||||
TODO ADD DIAGRAM
|
||||
Reference in New Issue
Block a user