Flesh out threat model

[keorn]

Also the section on what class of attacks it should / will not / may protect against.

[burdges]

In short, we need to protect metadata of both senders and receivers, and protect them from one another, not just third parties.

We'll collaborate with the Nym project by Harry Halpin, George Danezis, etc. for more nuanced protections against attack on mixnets, but if we basically design for Loopix-like cover traffic then anything we build should be amenable to their goals.

[robertkiel]

We should also take care of network attacks.

1. When starting the node: there need to be a protection against malicious nodes that flood the new node with addresses of colluding nodes - in other words, there should be a secure / safe way to crawl the network.

2. When receiving a packet, there need to be a safe way to determine how to connect to the next node. It must be especially intractable for malicious nodes to spam that node with fake addresses in order to block communication.

[burdges]

A priori, I'd envision identifying the subsequent node by their public routing key. Routing keys must rotate say once per week or month, so nodes have a couple routing keys simultaneously. We thus need to identify the specific routing key in the packet, or else use either trial description. If all a node knows about the next node is its public key, then it must look up that node in a database, which includes its transport layer signing keys, and must drop the packet if the key cannot be found.

We cannot do the node PKI by simple gossip in long term anyways. I opened a literature collection thread on this topic: https://forum.web3.foundation/t/random-peer-sampling-literature-thread/45

We might try gossip-like approaches like Brahms, which protect against 1, but do not provide protection against epistemic attacks. Julius Bunger is doing work around Brahms for GNUNet, but avoiding epistemic attacks likely requires verifiability tricks, which I doubt he looked into.

We could temporarily go with a Tor-like global PKI as "accounts" associated to some blockchain, which sounds semi-viable long-term if we're paying all the nodes anyways. In we actually want this long-term, we require "lite clients" to sample this blockchain PKI without downloading everything. We could use a specialized parachain of polkadot that serves up accounts using epsilon-PIR, assuming either enough "full nodes" who know all the accounts, or adapting the epsilon-PIR scheme to only "partially full nodes".

[burdges]

We discussed this extensively at the meeting and decided upon taking am ore nuanced approach than I previously envisioned.