FlowingMail: a P2P, secure, encrypted email system

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:

blocks containing the public key of each participating node blocks containing slices of encrypted emails
blocks containing slices of encrypted emails
blocks containing an encrypted list of IDs of blocks that together form a complete encrypted email

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:

fetch the public key of the recipient’s node by querying the DHT for the block with ID equal to the recipient’s ID
encrypt the mail using the recipient’s public key
split the encrypted mail in several blocks and store them in the DHT: each block will be stored in few nodes that have an ID similar to the block ID
build a list of IDs of the blocks that contain the encrypted email
build a block that includes the encrypt the list of blocks IDs
add to the block containing the list of IDs a sequence of bytes that cause the ID of the block to be similar to the ID of the recipient, then store the block in the DHT. This operation is computationally intensive and is used as “proof of work” to prevent spam

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:

fetch all the blocks with the ID specified in the decrypted list
join all the blocks
decrypt the received email