FlowingMail: a decentralized, secure, encrypted email system

facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail  twittergoogle_plustwittergoogle_plus

FlowingMail is the name of a new decentralized, secure and encrypted email protocol.

The most used email systems rely on a central server that receives, stores and forward the messages: FlowingMail is decentralized and does not rely on a central server to deliver the encrypted emails.

The scope of the FlowingMail protocol is to hide the information being transmitted and the parties involved in the communication.

The main component of the FlowingMail protocol is a Kademlia Distributed Hash Table (DHT), which is responsible for storing the encrypted emails while they are in transit and the certificates of the participants in the FlowingMail network.

Overview

Warning: For simplicity this section intentionally omits some details (e.g. key revocation). In order to have the full protocol specifications please read the full “Protocol specifications”.

All the FlowingMail clients are nodes of a Kademlia Distributed Hash Table (DHT) and are identified by an unique 256 bit ID.

From now on the terms “client” and “node” will be used interchangeably.

The DHT is seen as a global storage pool that stores blocks of information identified by an unique 256 bit ID: each block is stored in few DHT nodes (FlowingMail clients) that have an ID similar to the block ID. Each stored block is accessible by every node that knows the block’s ID.

The DHT is used to store:

The ID of each block can be found by hashing twice the block content using the SHA-512/256 algorithm, while the ID of each node or FlowingMail client can be found by hashing twice the block that contain the node’s public key:

block_id = *SHA-512/256* (*SHA-512/256* (block_content) )

node_id = *SHA-512/256* (*SHA-512/256* (block_containing_the_public_key) )

Since the block containing the public key has the same ID as the one of the node it represents, it is usually stored in the node itself and its neighbours (nodes that have a similar ID).

Sequence of operations

When a node wants to send an email then it performs the following operations:

The block containing the encrypted list of IDs will be stored also in the recipient node because the block’s ID will be similar to the recipient’s ID. If the recipient is offline then it will receive it when it goes back online because neighbour nodes republish their content at predefined intervals.
Each node tries to decrypt all the blocks that it receives and stores, but it will manage to decrypt only the blocks encrypted using its public key.
When a node receives a block containing the list of IDs and manages to decrypt it then it performs the following operations: