[guardian-dev] Lavabit's Dark Mail Initiative

Natanael natanael.l at gmail.com
Mon Nov 18 19:23:56 EST 2013

Bote mail on I2P seems to have everything but forward secrecy. It is
serverless and uses DHT for delivery and public keys as addresses, with all
emails being encrypted. There are Bote-SMTP proxies you can use (same
warning as for Tor outproxies apply, use PGP!)

- Sent from my phone
Den 19 nov 2013 01:19 skrev "elijah" <elijah at riseup.net>:

> 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
> _______________________________________________
> Guardian-dev mailing list
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To Unsubscribe
>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>        Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/
> natanael.l%40gmail.com
> You are subscribed as: natanael.l at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20131119/ea7e9735/attachment-0001.html>

More information about the Guardian-dev mailing list