GRIN/nym
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

concepts 2nd pass

Browse Source
This commit is contained in:
mfahampshire
2024-09-25 18:56:34 +02:00
parent fc8275c372
commit c85b100517
5 changed files with 6 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/docs/pages/network/concepts/_meta.json
-1
View File
@@ -2,6 +2,5 @@
"mixing": "Packet Mixing",
"loopix": "Loopix",
"cover-traffic": "Cover Traffic",
"epochs": "Epochs",
"anonymous-replies": "Anonymous Replies"
}
documentation/docs/pages/network/concepts/anonymous-replies.mdx
+1 -1
View File
@@ -7,6 +7,6 @@ Luckily, SURBs allow for anonymous replies. A SURB is a layer encrypted set of S
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.
If a reply is too large still (i.e. it would use more space than the available combined payload of the SURBs 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).
documentation/docs/pages/network/concepts/cover-traffic.mdx
+4 -2
View File
@@ -1,9 +1,11 @@
# 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.
> The Nym mixnet generates cover traffic "loops" ... [l]oops 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
In order to avoid timing attacks where an attacker tries to deanonymise which clients are communicating with each other, cover traffic is implemented. As soon as any client is connected to the mixnet, they will send Sphinx packets in 'loops' between nodes at a steady rate, inserting packets containing actual payload data (i.e. actual messages being sent between clients) when they are available.
In this way, Sphinx packets containing actual payload data are hidden in a steady stream of 'background noise' in the form of 'cover' Sphinx packets with empty payloads, but which are indistinguishable to an observer.
An in-depth explainer can be found in §4.6 of the [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf).
documentation/docs/pages/network/concepts/epochs.mdx
View File
documentation/docs/pages/network/concepts/loopix.mdx
+1 -1
View File
@@ -3,5 +3,5 @@ The Nym Mixnet is based upon the [Loopix](https://arxiv.org/pdf/1703.00536) desi
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.
- Messages are routed through an Entry Gateway, 3 layers of Mix Nodes, and an Exit 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.