[guardian-dev] Lavabit's Dark Mail Initiative

elijah elijah at riseup.net
Mon Nov 18 19:19:51 EST 2013


On 11/18/2013 09:37 AM, Josh Steiner wrote:

> http://www.kickstarter.com/projects/ladar/lavabits-dark-mail-initiative
>
> Basically, it is an initiative to open source the lavabit's internal
> code and turn it into a new secure mail protocol they are calling
> "Dark Mail"

The really annoying thing is that lavabit's platform and Dark Mail are 
totally incompatible and have nothing to do with one another. So the 
kickstarter is meaningless.

* lavabit's prior software allowed the service provider to encrypt a 
user's IMAP disk storage individually to the password of the user.
* darkmail is a project driven mostly by silentcircle that is to create 
something entirely new that is email-like, but not email.

In case you missed it, moxie did a pretty good job explaining why 
lavabit's old code should die and should most definitely NOT be open 
sourced or used by anyone: 
http://www.thoughtcrime.org/blog/lavabit-critique/

This critique was later posted to arstechnica, and then later there was 
an exchange on reddit under Ladar's AMA in which Ladar doubled down on 
his completely unjustified claims and Moxie doubled down on lavabit 
being total snakeoil:

http://www.reddit.com/r/IAmA/comments/1qetvk/i_am_ladar_levison_owner_and_operator_of_lavabit/

It is not pretty. Moxie is correct, of course, but a valid defense of 
the lavabit model would have been to talk about how US law treats data 
at rest very differently than data in transit. This was not the approach 
Ladar pursued. It does not totally matter, because that potential 
justification doesn't hold true anymore based on what we now know. So, 
really, there is no justification for making the lavabit approach open 
source.

The darkmail project is interesting in that they have promised all 
things to all people:

* end-to-end client-side encryption
* automatic management of keys
* not email, but xmpp used in an email-like way
* but maybe also gateways to email for backward compatibility
* asynchronous forward secrecy and metadata protection via SCIMP 2.0
* thunderbird extension
* local imap & smtp server so you can use existing mail user agent
* open protocol and open source code so anyone can adopt
* tools to make it easy for a service provider to use

Because we don't have any details yet on darkmail it is impossible to 
critique. What we do know is that SCIMP 1.0 doesn't have the properties 
that are promised, and they can't be added without basically a whole new 
protocol. But I think darkmail is exciting and is making the right 
promises (total end-to-end security). I certainly hope they will answer 
my emails :)

Of course, LEAP (https://leap.se/email) already does almost everything 
that darkmail wants to do, with the one caveat that currently we use 
SMTP exclusively and rely on the service provider for PFS and metadata 
protection (although we have a plan to fix this in the future).

-elijah


More information about the Guardian-dev mailing list