|Sarah Jamie Lewis 4ef486b081||1 month ago|
|.idea||1 month ago|
|niwl||1 month ago|
|niwl-client||1 month ago|
|niwl-rem||1 month ago|
|niwl-server||1 month ago|
|references||1 month ago|
|.gitignore||1 month ago|
|Cargo.lock||1 month ago|
|Cargo.toml||1 month ago|
|LICENSE||1 month ago|
|README.md||1 month ago|
niwl (/nɪu̯l/) - fog, mist or haze (Welsh).
niwl is an experimental bandwidth efficient anonymous communication system based on fuzzytags in combination with untrusted mixing nodes and an additional untrusted routing server.
This workspace provides a prototype set of libraries, clients and servers.
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) 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.
Instead of placing messages into deterministic buckets based on the recipient, Fuzzy Message Detection
allows each message to probabilistically address itself to several parties in addition to the intended party - utilizing the anonymity of the whole set of participants, instead of the ones who happen to share a bucket for a given round.
Unfortunately, naive deployments are vulnerable to intersection attacks and statistical analysis which forces a requirement an additional layer of sender anonymity is necessary to prevent metadata analysis.
In order to obtain sender anonymity without introducing an external mix network or anonymizing overlay network such as tor or i2p, we can observe that clients are free to implement any behaviour they want directly on top of the fuzzy message detection system - and that includes mixing.
A niwl system relies on a single, untrusted routing server that acts as a bulletin board. We assume that clients communicate with this server via https such that network adversaries are unable to determine the exact messages sent and received by each client.
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 and Fuzzy Message Detection)
In order to provide statistical anonymity , the above base functionality is extended by a special class of client
random ejection mixers or
REMs for short.
REMs reinforce the anonymity of the system in two ways:
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
Clients can wrap messages to other clients in a message that is first forwarded to a
REM then decrypts
the message and adds it to a store of messages - ejecting a previously stored message (at random) first to make space.
Note: This comes at the cost of doubling the traffic in the system (1 message to the REM and another message to the end client). Fuzzy message detection allows clients to reduce the amount of messages they have to download.
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:
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.
Fuzzytags themselves can only be linked to receivers via those in position of a RootSecret or niwl Servers who
DetectionKey - 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.
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:
Before diving into mitigation strategies it is worth outlining a few properties of niwl that differ from other mixing-based anonymity systems.
Additionally, we should also enumerate what could go wrong, in addition to an active attack on a particular mix.
The niwl server may deliberately drop or delay packets arbitrarily. Beyond this prototype it is worth considering incentive mechanisms such as (token-based services) to mitigate this.
niwl may attempt to perform a “tagging attack” however there is nothing within the structure of niwl packets that allows a tag to be placed on a message. The fuzzytags themselves will fail to verify if they are modified in any way, and the ciphertext itself is bound to the fuzzytag both through the derived encryption key, and the nonce. And interference with a packet is equivalent to dropping a packet.
Malicious entities can only tag their own message through the system (something that requires collusion to take advantage of). (NOTE: this is functionally equivalent to Sphinx, and it might be worth just converting this over to use Sphinx)
niwl servers may attempt to passively profile traffic originating from clients in an attempt to determine mixing nodes. REMs always download all messages from the niwl server and so the only available metadata exposed is the rate at which a REM sends messages. This can be partially mitigated by introducing random delays between individual sends, and between syncing periods.
REMs employ heartbeat messages (messages periodically sent to the niwl server addressed to the REM) to detect such attacks. If a REM does not receive its own heartbeat message shortly after it is sent, it begins injecting random messages into its pool to thwart mixers. It can also display this status publicly and/or include the status in legitimate messages alerting other clients to the malicious niwl Server.
The rate at which a niwl sends out a heartbeat message is also a vector for passive profiling. Heartbeats must not be distinguishable from other niwl traffic through their rate.
Finally, the fact that a REM operates 24/7 will make it stand out from a party that only uses the system for part of the day (or week...etc.) - the only practical defense to this is to have more services and bots make use of the niwl system other than mixers - as traffic diversity increases, the less utility tells like frequency of message sends ultimately have.
For the purposes of this prototype message are encrypted using a simple one-use, unidirectional diffie-hellman derived key, where the sending party generates an ephemeral keypair (which then uses libsodiums secretbox to perform the actual encryption). This key binds the message to a particular fuzzytag (which prevents tampering) but does nothing else to certify the authenticity of the message.
Because of this only confidentiality and integrity of the message contents is asserted - no authentication mechanisms is provided.
Any party that knows the
PublicKey and the public
TaggingKey of another party can encrypt and send messages to them,
and the recipient party has no mechanism to certify the origin of these messages.
Any applications built on top of niwl need to provide an additional encryption layer that provides authenticity (e.g. a complete diffie-hellman key exchange involving pre=exchanged long term identity public keys).
niwl is designed to provide metadata security when operated over an unprotected network. Ideally, a niwl server should learn nothing about the habits of a particular IP address other than they are using niwl. In practice, as discussed above a server can likely distinguish between automated services and manual clients.
Clients may wish to hide their use of niwl from a network adversary (at a risk of revealing that they are using another anonymizing network). This will also further reduce the ability of niwl to correlate senders with specific behaviour and can be seen as complimentary, but optional.
There is no reason that a client could chain a sequence of mixers together via onion encrypted their original message to multiple mix nodes. In that sense we can treat the system as a superposition of free-route mix networks.
Analysis should be done to determine the anonymity of this system and the impact of added more mixers to the overall anonymity of the fuzzy message detection.
niwl provides common library functions useful to all other packages.
niwl-server provides a web server with a json API for posting new tags and querying the tags database.
niwl-client provides a command-line application for managing secrets, tagging keys of parties and posting / querying for new tags.
niwl-rem provides an implementation of the random ejection mixer.
For a more detailed overview please check out each individual crate.
Beck, Gabrielle, et al. “Fuzzy Message Detection.”
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.
Sampigethaya, Krishna, and Radha Poovendran. “A survey on mix networks and their secure applications.” Proceedings of the IEEE 94.12 (2006): 2142-2181.