The people from Lavabit and SilentCircle announced their Dark Mail Alliance which is going to develop a new end-to-end encrypted protocol to better secure email. Since, the media reports about this were scarce on details, I watched the recording of their presentation and will summarize what is interesting to me below,  in case it might also be interesting to you.

They call their new Dark Mail system peer to peer. The end-to-end encryption should be integrated into the protocol and keys should be generated on the users device without any interaction by the users so it will be as easy to use as email today. For each message exchange there will be a new key to not compromise more than a single message at once.

The system should be compatible with today’s email by some sort of an SMTP bridge. A Dark Mail capable client should show a red warning when a mail goes out of Dark Mail.

Their aim is to use as much existing work as possible. Currently, their idea is to use XMPP (Jabber) for communication between parties. The actual body of the message should not the in the XMPP message itself, but encrypted in some cloud storage and only the participants of the conversion should be able to decrypt it.

Ladar Levison from Lavabit is planning to eventually implement the Dark Mail protocol into the existing Lavabit source code and then release it as Free Software to enable other people to make use of it. At the same time he wants to build a Free Software service around Dark Mail offering services and consulting.

I welcome the effort to improve upon the current email standards trying to make them more secure and more resilient to eavesdropping and surveillance. After listening to the presentation of the Dark Mail initiators, I still have many open questions and I am curious how they will be answered once their protocol evolves into an implementable and reviewed form.

For example, they call their protocol peer to peer and still want to use XMPP which heavily relies on servers. If it will be really peer to peer, how will they prevent it being even more susceptible to SPAM? How do they plan on handling session initialization and key exchange when one receiver of a message is not online at the same time as the sender? Why store messages encrypted in the cloud and not deliver them right away?

I guess all this will become clearer once they publish first drafts of the actual protocol. Ladar Levison himself mentioned that he does not want to go to much into the technical details, because a lot of them might still change. It is certainly a tough nut to crack to do this right, but it is good to see that people now start cracking this nut!