The Diluvian Network (DiNet) is a simple solution to the problem of encrypted anonymous communication: how can you detach the user from their intended communicating partner?

The Basics

A user who wants to chat on DiNet will connect his DiNet client to a DiNet, of which there can be many distinct implementations as there are with IRC networks. Each message utilizes a 128-bit number which doesn't need to be unique. Users pick a prefix of the 128-bit number to filter out the deluge of messages on the network.

When the user sends a packet to a DiNet edge node, the router attached forwards the packet to all routers who are listening to it. If they have not seen a packet with this checksum recently, those routers in turn forward this packet to all listening routers. In this way, all messages should be propegated to all nodes of the network.

Routing

Each router keeps a short history of packets it has seen recently, indexed by checksum. If it has seen this packet recently, it does not forward it. If it hasn’t seen this packet recently, it adds it to the table and forwards it. This way the network is flooded with every packet, and each edge node should eventually get a copy. Users inform the edge nodes with what messages they want to receive by the prefix they provide, and the edge nodes deliver all packets matching that to them.

Care must be taken by edge nodes to avoid accepting too many packets. Otherwise the network will be overcome with data.

Example

Note: these 16 byte numbers correspond to message IDs, not linking to changesets

Sally connects to Edge node 1 with two prefixes: 6a78 and 30, both chosen in advance by her and her communicating partners. Soon, messages begin to arrive from the network that Edge node 1 connects to. Messages like 517a7d1af7b9a76f68a52f5e96b6207a and 4d8da44181379233a851c53c25599e59 are not included by Edge node 1 when responding to Sally's request because they do not start with 6a78 or 30.

Sally sends several messages with IDs like 9a7a3646d4818f937d33f4b36cda3d35 and 6a78b89d88ff02c8720bf2698f49a5855. Notice how the first message doesn't start with any of the prefixes Sally has registered with Edge node 1, but the second one does. For messages sent to Edge node 1, the conversation Sally is having may be asymmetric (Sally uses the prefix 9a7a for outbound messages, but 30 for incoming) or it may be fake data that Sally generated to confuse people snooping.

When a message with IDs like 30bf4ed7edbdefc133dd7f5bd985a8b0 or 6a7818177cf0236d417bb93ae2fdb579 arrive at Edge node 1, the server there forwards the messages to Sally. If they are actually part of Sally's conversation, her dinet client will verify and if necessary, decrypt them before displaying them. If they are not verified, they are silently discarded.

Possible Use Cases

There are many ways to use the network.

Using the DiNet Client

The offical jQuery dinet client is designed to be used when communicating with one or more parties. All users that wish to communicate pick a prefix and a password. The shorter the prefix, the more messages they will all receive, because more users will share that prefix with them.

It uses AES-256 in CBC mode, where the IV is the id of the message sent over the network.

Custom Methods

Since DiNet is a network, it can be used by custom clients with custom encryption schemes. Here are a few ideas:

• IDs change with every message via some secure, unpredicatable function
• Posting parts of messages to different IDs and combining them
• Submitting the same message to multiple endpoints to avoid malicious routers dropping packets