The risk analysis now seems done.
Quite some time has passed since we proposed the first draft of the FlowingMail protocol.
The first version of FlowingMail came out as a sparks in our brain and was immediately put on paper, but then a calm period followed during which we slowly started a risk analysis of our proposed implementation.
After major trimmings and adjustments, a completely different version of the protocol was born: the original goals are still there, but the new version of FlowingMail has little resemblance with the original proposal.
The following image represents the latest risk analysis (generated from the XML file in https://bitbucket.org/flowingmail/protocol/commits/all). Click the image to enlarge.
The green boxes are requirements, the other boxes are risks and their color depend on the risk severity after it has been mitigated by the requirements.
What are the difference between the new proposal and the original one?
- The new protocol is much simpler: the columns and the possibility to have several values per hash in the DHT are gone. Now the DHT can store one value per hash
- The addresses are now 256 bits wide (up from 160)
- The public keys are embedded in self-signed X509 certificates. A CA can sign the certificate for closed private networks.
- The ID of the nodes is the SHA256(SHA256(certificate bytestream))
- The X509 certificate contains a field that stores the SCRYPT hash of all the fields in the certificate. This slows down the creation of certificates targeted at a certain region of IDs
- The X509 certificate contains an ID of the revocation certificate. When the revocation certificate is published then the original one is void and the revocation one takes over. The node changes ID
- When a node wants to send an email then it sign and encrypts the message, then splits it into several blocks that have as ID the SHA256(SHA256(block content)).
Then a header block is generated. The header contain the IDs of all the blocks in the mail, then it is signed and encrypted. Additionally, the last bytes of the header are changed until the SHA256(SHA256(header content)) is close enough to the recipient’s ID. This servers also as proof of work to avoid spam.
All the message blocks, including the header, are then sent to the DHT and stored in the relevant nodes. Because the header has an ID close to the recipient then the DHT will redirect the block to the recipient. If the recipient is offline then it will receive the header from a neighbor node when it will go back online.
When a node is able to decrypt the header then it can start downloading the message.
The new protocol is suitable only for desktop PCs (the calculation of the header ID requires intensive computational resources), therefore the mobile application will just connect to an user’s PC and use the PC as a FlowingMail gateway.
A complete specification paper will be published soon, then finally the development of a client application can start, for real.