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...

The risk analysis has been updated (https://bitbucket.org/flowingmail/protocol/commits/all). The following chart represents the requirements (green) and risks present in the risk analysis. The color of the risks ranges according to the severity and likelihood after the mitigation: from red (high severity and likelihood) to cyan (low severity and likelihood). There have been considerable changes since the first version of the protocol: a proof of work is now necessary to send an email: because the block that initiates the email must be indistinguishable from the blocks that contain the mail content, the sender must form the initiation block so that its SHA2 is really close to the recipient’s ID, so it will reach the intended node. The difficulty of the proof of work depends on the number of connected nodes, but this will most likely force the usage of a GPU for the calculation of the hash the recipient must try to decrypt all the blocks that it receives for storage because it may receive a mail initiation block that specifies the ID of the first mail’s block the modified protocol distributes better the information between the nodes the “bittorrent” way of transferring data is not used anymore: this prevented an uniform distribution of the blocks between the nodes The first draft of the protocol will be published...

A revised version of the file containing the risk analysis has been committed here: https://bitbucket.org/flowingmail/protocol/commits/all A custom tool (that will be published soon with an open source license) generated the following graph of requirements (green) and risks (color changes according to the risk factor after the mitigation). Requirements may introduce new requirements or risks, while risks can be mitigated by new requirements  

This page is no longer valid. Revocation IDs will be implemented instead. We are thinking about implementing Alternative Identities into FlowingMail. This is a small description on how it should work. As soon as your FlowingMail client will create your new public/private keys and ID, it will also create an alternative set of keys (and therefore also a different ID) to be used only in the case that the original one gets compromised. The alternative ID (signed) will be published in the DHT together with the original public keys, but the alternative keys will be kept hidden. Ideally you will have to keep the alternative keys separate from your PC (ideally in a CD or other medium like USB key in a different location). When a client adds your ID to its own contacts, it will add immediately also the alternative ID and just store it. As soon as the keys for the alternative ID are published on the DHT, then the clients that have your ID in their contacts will delete the original ID and start using the alternative ID. A new alternative ID will have to be signed and published. This should mitigate the problems that arise when the original private key is lost or leaked to third parties. As soon as you discover the leakage of your private key you should communicate your new ID to your new contacts, because the thief could try to publish its own alternative ID. Old contacts should be on the safe side having downloaded the original alternative ID. To mitigate the release of a fake alternative ID by the thief of the private key: a node that stores an alternative ID must not change its value, only refresh it. Nodes that try to store a different alternative ID must be blacklisted a query for an alternative ID should query several nodes (like a lookup), not just the first one that returns a value. If different alternative IDs are found then a warning should be displayed. a new alternative ID cannot be used during the 5 days from the date of first publication: a node should not respond to request for alternative IDs that have been published for less than 5 days clients should try to load the alternative ID for their contacts as soon as possible, and then they shouldn’t modify it warnings should be issued if a contact starts using an alternative ID UPDATE Using also the alternative ID to hash the original ID is also an option, but in this case a longer sequence of alternative IDs must be generated at once. This would prevent the thief of the original ID to generate its own alternative one. Just thinking...

Few comments about FlowingMail ask: “Why FlowingMail? Why not BitMessage? Why not Retroshare? Why not something else?” For me, it is about compromising security and usability: finding the right position in the Usability-Security dial is a personal matter, and my choice doesn’t fit in neither BitMessage nor Bote I2P nor Retroshare nor Emails. I’ve tried to like BitMessage, but the delivery time of several hours has putted me down. Plus, the bandwidth needed by the client was simply too much: BitMessage transmits everything to everybody in order to hide the parties involved in the communication, but this limits its application to desktop machine connected to a large bandwidth network (a no-no for mobile devices). Here there is a comparison table, and FlowingMail ticks the right boxes for me, but it may not be suitable for you. For instance, for me the possibility to change the encryption keys every now and then is a good thing: in the case your machine get compromised and the private encryption key is leaked then the attacker could decrypt only the mails sent with the compromised key. FlowingMail BitMessage RetroShare I2P Bote Plain Email Ease of use Easy Easy Easy, once the keys have been exchanged by normal email Medium Easy Encrypted Yes Yes Yes Yes No Scalable Yes No Yes Yes Yes Anonymous Not now Extremely Yes Yes No Encryption key can be changed Yes, with expiration date No No No Not...