This crate workspace provides and documents a novel and highly experimental metadata resistant communication system.
The code has not undergone any significant review.
Further, it is based on an [experimental implementation (fuzzytags), of an experimental cryptographic scheme (FMD2)](https://git.openprivacy.ca/openprivacy/fuzzytags)
which also has a large list of security warnings.
I urge you to not rely on this code or derivative systems until it has been reviewed and given considerable thought.
A Niwl system relies on a single, untrusted routing server that acts as a bulletin board.
Niwl clients can post and fetch messages to and from the server. When posting a message a client attaches a fuzzytag
generated for the receiver that allows the receiver to not only identify the message, but also to restrict the number
of other messages they have to download (see [Fuzzytags](https://docs.openprivacy.ca/fuzzytags-book/introduction.html) and [Fuzzy Message Detection](https://eprint.iacr.org/2021/089))
In order to provide statistical anonymity , the above base functionality is extended by a special class of client
called `random ejection mixers` or `REMs` for short.
`REMs` reinforce the anonymity of the system in two ways:
1.`REMs` download all the of messages from the server. Thus providing cover for receivers who download only a fraction
of the messages. A Niwl server cannot distinguish between a message intended for a REM from a message intended for an
ordinary client.
2. Clients can wrap messages to other clients in a message that is first forwarded to a `REM`. The `REM` then decrypts
the message and adds it to a store of messages - ejecting a previously stored message (at random) first to make space.
## Random Ejection Mixers (REMs)
A REM starts with a store of `n` randomly generated messages with randomly generated fuzzytags. These messages are
for all intents and purposes "noise". Each REM also generates a TaggingKey that it can provide (publicly or privately)
to other clients who wish to use the REMs services.
Each REM constantly checks the Niwl Server for messages. It checks each message it downloads against its RootSecret
and if the FuzzyTag verifies then it proceeds to decrypt the message.
The primary service a REM provides is anonymous mixing. A decrypted mixpacket contains 2 fields:
1. The fuzzytag of the message to forward.
2. The message itself, which we will assume to be encrypted by some out-of-scope process.
Once a message is decrypted, an existing message from the store is randomly chosen to be ejected by the mix - and is
posted to the Niwl Server. The new decrypted message takes its place in the message store.
### On the Privacy of REMs
Fuzzytags themselves can only be linked to receivers via those in position of a RootSecret *or* Niwl Servers who
possess the `VerificationKey` - as such, assuming that there is no collusion between a particular REM and a Niwl Server
there is no mechanism through which a REM can associate message with a (set of) receiver(s).
Further, (again assuming no collusion between a particular REM and a Niwl Server), there is no mechanism for a REM to associate
a message with a particular sender.
Finally, and perhaps most importantly, there is no limit on the number of REMs permitted in a particular system. Different
parties can select different REMs with different trust valuations. REMs can join the system at any time without permission
from any other entity. In other words, unlike traditional mixnets or onion routing, the system does not rely on consensus
regarding the mixing entities to ensure privacy.
### On the Security of REMS
`n-1 attacks` / `flooding attacks` and other active attacks on mixers are a valid concern with any mixing strategy.
This broad genre of attacks can be generalized as follows:
1. REMs start with a pool of randomly generated messages, this protected initial messages sent to the REM.
2. Over time this pool is probabilistically replaced by messages from the network.
3. A malicious Niwl server, having identified a REM, can flood the REM with its own messages.
* Danezis, George, and Len Sassaman. "Heartbeat traffic to counter (n-1) attacks: red-green-black mixes." Proceedings of the 2003 ACM workshop on Privacy in the electronic society. 2003.
