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
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
- fetch all the blocks with the ID specified in the decrypted list
- join all the blocks
- decrypt the received email