mailpile : blog

Posted by Smári on October 31, 2013 ( Content may be obsolete! )

Over the last couple of days, a lot of people have contacted us asking if we are going to support or implement DarkMail, a project announced yesterday by the developers of LavaBit and Silent Circle. The idea of increasing e-mail privacy and security is one of our core goals, after all.

The short answer is: until DarkMail is an open standard, we can't really comment on what it means to Mailpile.

However, we can say that there are certain things DarkMail could do which would make us very interested in working with them. And conversely, there are things they could do which we would strongly disagree with. There is much public uproar about government surveillance at the moment, and it is disappointing to see that a lot of it is leading to projects that, while being driven by honest intentions, are skirting past important details or developing them behind closed doors. Hopefully, DarkMail won't make that mistake.

This isn't just about lofty ideals or personal politics, this is about security. When developing a system that is to be secure, the golden rule is Kerchoffs' principle, which states that such systems should always be designed with the assumption that attackers have full knowledge of how they work. Projects that do not guarantee their designs will be open to public scrutiny, may be attempting to provide security through obscurity - which isn't security at all. The correct way to develop something like this, is out in the open, where it can be scrutinized, attacked, gutted and ripped apart a thousand times over by the best cryptographers, protocol designers and systems engineers in the world, so that when a final decision is made, it'll be a good one. That applies to the code and doubly so to the standard it implements. Yes, yes, we know that standards processes are painfully slow and wrought with horror, but that doesn't mean that skipping them is a good idea.

At this point, it is unclear how open DarkMail plans to be or how centralized. They promise to release code as open source, but less has been said about the more important question of how the underlying protocols themselves will be designed. So, while we very much support their goals, we ask that the DarkMail group do certain things to make sure that it becomes all it can be:

1. Reach out to the developers of other e-mail applications, including but not limited to Thunderbird, Evolution, and Mailpile, and invite them to participate in the process of delineating a standard.

2. Work the entire process through an IETF Internet draft standard process. The IETF meeting in Vancouver next week might be a prime oportunity to broach this subject and get it moving.

3. Share their working codebase with the public as soon as possible. Even though they're probably pretty far from a stable release, the notion of "release early, release often" is a tried and tested concept that we advocate strongly.

It is crucial that DarkMail be open about what they're doing, not just in word but also in action. Press releases make bad technical specifications, and handwaving makes bad crypto. Any realistic solution to the problem of mass surveillance of digital communications needs to be one that is fully in line with current best practices. Considering what is at stake, anything less is unacceptable.

So, until we have clear answers to these questions, we're going to keep working with what we have: an almost 50 year old, open, decentralized communications protocol with 2.3 billion users worldwide, running of a standards base that has left a lot of room for iterative improvement.