sean cassidy : The Origins of the Diluvian Network

Last year, sometime around June, I heard of Cryptocat and thought it was a pretty cool idea. Someone actually making cryptography available for the masses in an intuitive way without needing complicated key exchanges or a web of trust! Finally.

However, it was not, at the time, very secure. Bruce Schneier commented on Cryptocat that it was similar to Hushmail in its security. Trust them to keep your data safe. That's not really very secure for anything worth hiding. Matthew Green did some analysis on Cryptocat, which wasn't very positive from a security perspective.

There was also a big gap in Cryptocat from my perspective: a lack of anonymity. That's not important for many people, but if you want to "topple an oppressive government" as Dr. Green puts it, it is important. So what to do?

While I'm interested in cryptography and have taken several university level classes in it, I am by no means an expert in cryptography. How could I build a system that was more secure and more anonymous? By solving a different problem.

Imagine a new version of Cryptocat where all the messages on the network are sent to every member who is online. As they are all encrypted, the conversations are still private. However, you now cannot tell who is communicating with who easily1. Your encryption will need to be top-notch, though, as it would be trivial to get all encrypted messages.

That sounds like a lot of data, though. It won't scale to thousands of users. Why don't we limit the amount of data deliver to each user? Let's put an ID on each message, and take only messages starting with a particular prefix. Then, before communicating, interested parties would share their prefix, so that we'd all be communicating on the same channel.

This is just one of many possible applications which can be built on top of the Diluvian Network, also known as dinet. It is a simple idea, really: each router will deliver every message it hasn't seen recently to every router that's listening. Router links are not automatically bidirectional; each router must specify who it is subscribing to and where other routers can listen for updates. The message format is exactly this:

typedef struct {
    uint8_t id[16];
    uint8_t data[1024];
    uint8_t checksum[32];
} __attribute__ ((packed)) dpacket;

That's it. It's a lot simpler than other protocols and designed to be easy to implement2. There are essentially no message parsing, decoding, or endianness issues to consider. The two ways a packet is invalid are if its SHA-256 checksum does not match and if the packet is of an incorrect length. That's it!

The fixed message size was chosen to limit plaintext length attacks (see Kelsey or Tezcan-Vaudenay). As the network was designed for short text messages (unlike Tor or I2P), this was an important consideration.

By building a network instead of an application I hope that people with clever ideas can use this as an effective tool for creating messaging programs. There is a basic dinet client up now, but there is only one node running, which isn't much of a network at all. It uses the built in HTTP REST API. Also, my Javascript skills aren't great (yet) so the client is pretty rough.

Let me know what you think. Obviously dinet is still (at best) beta quality software, so do not use it for anything that requries serious security.

  1. Yes, you might be able to tell from timing, but there are ways to fix that too. 

  2. There are also no restrictions over how to deliver these messages to other routers. Currently ZeroMQ 3 is used, but you could make an implemenation that used a completely different technology. The only important aspect to remember is that since there are no routing tables, all messages must be delivered to all routers that are subscribed to you.