Slashdot Mirror
Silent Circle, Lavabit Unite For 'Dark Mail' Encrypted Email Project
angry tapir writes "Two privacy-focused email providers have launched the Dark Mail Alliance, a project to engineer an email system with robust defenses against spying. Silent Circle and Lavabit abruptly halted their encrypted email services in August, saying they could no longer guarantee email would remain private after court actions against Lavabit, reportedly an email provider for NSA leaker Edward Snowden."
I believe it was 2 days ago that I mentioned Lavabit would start a new project with self-signed or otherwise decentralized peer to peer encrypted e-mail with their newfound publicity. Tada, here it is.
PGP/GPG is boneheaded easy to use these days. Generate a keypair, uploaded to the keyservers automatically, install mail plug in.
From there it's virtually automatic.
Trolling is a art,
PGP's author is somewhat aware of that (;-)) He's a principal at Silent Circle
davecb@spamcop.net
PGP/gpg's weakness is noticeable, but in this case, the perfect is the enemy of the good, and a WoT is the security solution that sucks the least.
Yes, it takes some time to get keys signed, but the advantage of a WoT over SSL is that you can take a couple people whom you never met, but whom your friends trusted, add up their semi-trust, and be pretty sure that an unknown key is genuine.
No. SMTP was never meant to be secure and was never advertised to be secure. It's "secure enough" for casual and most business emails. I'd venture a guess that 99.999% (and that may even be low) of email sent would have zero benefit of being encrypted because no one cares what the content is.
It'd be like encrypting every conversation at a football game. Yeah all the conversations would be private, but aside from the two parties talking, no one cares.
Many protocols used over Internet were not designed with encryption because it didn't seem that important at the time. Internet was built with the intention that everyone plays nice and the networks are trusted. With NSA, times have changed, as they can set up a MiTM attack anywhere and the wire cannot be trusted anymore. It's not that they would only get a criminal warrant for the ISP to reveal your mailbox contents, but instead they are actively snooping in random places where they shouldn't be.
StartSSL offers free-of-charge domain-validated certificates that are widely trusted. Other CAs like GoDaddy and Comodo offer (often through resellers) domain-validated certs that cost less than $20/year. Thawte DV certs from resellers cost about $30/year. The cost (or lack thereof) for such certs is probably the least important reason why people aren't using HTTPS more.
EV certs are well within the budget for even small businesses, and usually cost around $150/year. Again, hardly unreasonable.
It'd be nice to see more hosting companies implement Server Name Indication (SNI) so that clients can implement SSL/TLS without needing to waste a dedicated IP address. This really should be the default.
They want to build it upon XMPP, according to the Ars article I read earlier this day.
Many protocols used over Internet were not designed with encryption because it didn't seem that important at the time.
Contrary to popular belief, "designing in security" does not mean every protocol has encryption built-in. It does mean that when designing an implementation of a protocol, security is properly factored in. And, in a system, that encryption is used in the appropriate places.
Most protocols on the Internet are application level protocols. Some applications would benefit from application level encryption because this reduces (not eliminates) risk of exposing unencrypted data. For most applications it's more efficient to implement a common encryption service then have the applications use that. That also has the advantage of enabling including encrypting the (final) endpoint identification (and other application identification) by implementing the encryption between the Transport and Network layers. Applications with their own encryption would also benefit from this.
Even with application level encryption, many (maybe most) of the existing protocols are useful. Example: A subset of SMTP could be used in delivering email. The email client application would establish a secure connection to the destination email server then send the actual message(s) using SMTP. Both the client-server connection and the messages would be encrypted. The server needs some meta data to deliver the messages to the mailboxes, but the meta data would otherwise be encrypted on-the-net. The messages would be decrypted by the email client to display to the user. (Even if you used direct IM, the Transport layer meta data would still exist, so you only get a little extra protection from direct IM - but IM is only possible when both parties are online.)
There is also value in implementing encryption just below the Network layer as this will encrypt the routing information as well. Still end-to-end at either the Transport layer or in the application (or, both) is vitally important.
(For those not familiar, the Network layer is responsible for moving data packets around the network, ultimately delivering data to the destination host. The Transport layer is responsible for end-to-end communications and represents the host. The host is the collection of applications running in a machine (physical or virtual) that use the Transport layer to communicate with applications running in other hosts. The "final" endpoint is what TCP, UDP and several other transport protocols call the "port" (example: port 80 for HTTP/HTTPS servers))
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
Why call it Dark-Mail?
Because it was better than the first name the came up with. From TechDirt:
Levison joked that they went with "Dark Mail" because "Black Mail" might have negative connotations.
http://www.techdirt.com/articles/20131030/11091025070/dark-mail-alliance-lavabit-silent-circle-team-up-to-try-to-create-surveillance-proof-email.shtml