Silent Circle, Lavabit Unite For 'Dark Mail' Encrypted Email Project

← Back to Stories (view on slashdot.org)

Silent Circle, Lavabit Unite For 'Dark Mail' Encrypted Email Project

Posted by timothy on Thursday October 31, 2013 @12:56AM from the it's-so-spooky dept.

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."

24 of 195 comments (clear)

Min score:

Reason:

Sort:

Did the NSA just kill SMTP? by Defenestrar · 2013-10-31 01:06 · Score: 5, Interesting

It's been around for what, 40 years? Working, (relatively) anonymous, and totally insecure mail transfer with tons of inertia. Never thought I'd see the day where there might be a small sliver of opportunity for another protocol to actually happen. Ars has a nice article about it too.
1. Re:Did the NSA just kill SMTP? by Vanderhoth · 2013-10-31 01:53 · Score: 5, Insightful
  
  There is the added advantage that if everything is encrypted, and snoopers had to decrypt everything to find something of value, it would be a serious drain on their resources. On the flip side, if everything, except that which absolutely required encryption, was sent in and easily accessible format then encrypted messages are a big red flag that says "Look at me I'm important!!", which allows snoopers to be selective about where they spend their resources. But that's just my take on it.
2. Re:Did the NSA just kill SMTP? by jones_supa · 2013-10-31 02:12 · Score: 4, Informative
  
  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.
3. Re:Did the NSA just kill SMTP? by mlts · 2013-10-31 02:40 · Score: 3, Interesting
  
  What might be a decent replacement for SMTP, but for small messages only (under 1-5 megs) would be a NNTP-like structure.
  User "A" at site foo.com wants to send a message to user "B" at bar.com. The message is encrypted with OpenPGP to b@bar.com. Then, the server at foo.com drops it into a store and forward pool similar to a newsgroup. bar.com eventually receives the latest messages, notices a message addressed to one of its users, copies it out of the "newsgroup", and into the user's mailbox.
  Of course, a blinding factor can be attached so no other machines with the NNTP-like pool can tell that the message is addressed to someone at bar.com, they can tell it is injected from foo.com and expires in a few hours, but that is that.
  Of course, the disadvantage is that a whole lot of irrelevant info goes between company servers. The advantage is that communications are protected, as one might see a server drop a message into the stream, but there is no way to detect a server fishing one out.
4. Re:Did the NSA just kill SMTP? by V+for+Vendetta · 2013-10-31 03:15 · Score: 3, Informative
  
  They want to build it upon XMPP, according to the Ars article I read earlier this day.
5. Re:Did the NSA just kill SMTP? by UnderCoverPenguin · 2013-10-31 03:43 · Score: 4, Informative
  
  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
6. Re:Did the NSA just kill SMTP? by dpilot · 2013-10-31 05:39 · Score: 3, Interesting
  
  RTFA - their intent is to make an Open Source solution. Given that these people shut down their businesses rather than compromise their principles, I'd find it hard to believe they were about to release patent-encumbered source code on the world.
  
  --
  The living have better things to do than to continue hating the dead.
Another mail protocol by gmuslera · 2013-10-31 01:12 · Score: 4, Interesting

This one with security/encryption built in from the ground up this time. Would be more interesting that instead of the comments of Microsoft (with deep ties with the NSA), yahoo and google (both may not be very happy with the NSA, but still must give them their users accounts info by law) the article focused on comments from people from i.e. the IETF for implementing it as an standard in a more worldwide (even personal) way.
Dump SSL / Certificate-based Security by Anonymous Coward · 2013-10-31 01:17 · Score: 5, Insightful

The whole paradigm of certificate trust, and the fact that you just have to trust Root CAs, is a farcical model of security.
We should all be aware by now that the Root CAs we all know and trust are compromised by NSA and that they can MITM any SSL connection they want at any time.
Until we can move beyond this whole third party certificate trust issue, there will never, EVER be truly secure email.
1. Re:Dump SSL / Certificate-based Security by CimmerianX · 2013-10-31 01:29 · Score: 4, Insightful
  
  Problem with PGP/GPG is that the tech concept is beyond many end users. If a solution is not easily adopted by the noobish masses, it will never gain a foothold.
2. Re:Dump SSL / Certificate-based Security by grub · 2013-10-31 01:34 · Score: 3, Informative
  
  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,
3. Re:Dump SSL / Certificate-based Security by landoltjp · 2013-10-31 01:43 · Score: 3, Insightful
  
  Is it fair to say that another shortcoming of PGP/GPG is that it encrypts the message body only, leaving the envelope in the clear?
  If this is indeed the case then we're right back to the metadata situation where the [who | when | where] I communicate it known, but not necessarily the _what_ (I'm sure the NSA will make up their own justification for _why_ I'm communicating).
4. Re:Dump SSL / Certificate-based Security by davecb · 2013-10-31 01:49 · Score: 3, Informative
  
  PGP's author is somewhat aware of that (;-)) He's a principal at Silent Circle
  
  --
  davecb@spamcop.net
5. Re:Dump SSL / Certificate-based Security by mlts · 2013-10-31 02:04 · Score: 3, Informative
  
  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.
6. Re:Dump SSL / Certificate-based Security by CreatureComfort · 2013-10-31 02:31 · Score: 4, Insightful
  
  Bonehead easier would be better.
  
  1. Generate key pairs behind the scenes. There is no value added to my (any user) choosing to manually generate a key pair and manage it. The software should be perfectly capable of generating my personal key pair(s).
  2. EVERY email sent should have the sender's public key in the Header, placed there automatically by the email client. No reason any typical user should ever have to see the key block. Public key blocks at the end of your signature are just geek peen waving.
  3. Email clients should be able to invisibly read the public key in the header, and add that to the local managed keyring, with no user intervention.
  4. Email clients should automatically encrypt emails sent to an address for which it has a public key in the keyring, and automatically decrypt incoming messages.
  5. If an email is being sent to an address with no key in the ring, then an initial email should automatically be generated sending a request for that address' public key (of course the sender's public key would be in the sent header). A specially formatted subject line or header value could be implemented so the the receiving email client would automatically respond with the public key, encrypted by the key it received in the header, and the request email need never even show up in the user's inbox. The body of the request message could simply be a request for the receiving user to implement a compliant email client, since the recipient would only see it if they were using a non-compliant client.
  6. Upon receiving the response email, the original sender's client could compare the encrypted key it receives against the public key in the header, add the public key for that address to the key ring, and then send the email (encrypted) that the original user wanted to send.
  
  The initial exchange of keys could happen very quickly and entirely automated in the background, so the users never even need to realize it is happening.
  
  Implement these six steps in every email client, and the problem would be mostly solved. Of course, there is the rub. Anything that isn't put seamlessly into Outlook, Gmail, iOS Mail, Yahoo, etc. will never get enough widespread use to be anything but blazing sign that this person has something they want to hide, and are willing to annoy all of their email contacts enough to keep sending requests for public keys. with every message.
  
  --
  "Unheard of means only it's undreamed of yet,
  Impossible means not yet done." ~~ Julia Ecklar
7. Re:Dump SSL / Certificate-based Security by heypete · 2013-10-31 02:31 · Score: 3, Informative
  
  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.
8. Re:Dump SSL / Certificate-based Security by jbolden · 2013-10-31 03:18 · Score: 3, Insightful
  
  The problem with PGP is it makes the end user responsible for key management. End users don't understand encryption. Their needs to be a key management services around PGP to make it viable for mass usage.
Thanks Snowden by Jakosa · 2013-10-31 01:31 · Score: 5, Interesting

When I first saw the Snowden-film from Hong Kong I thought: "damn! he has forfeited his life and nobody will care. And now this! Not only has he shaken the political world-society, he has also aroused the tech-world and made it possible to make some major changes. Hope I will be running this new protocol by next year and be able to send super-secret Christmas-cards to the select few who is also using it!
right from the white paper by imatter · 2013-10-31 01:45 · Score: 5, Insightful
SCIMP provides strong encryption, perfect forward secrecy and message authentication.Further, we have incorporated many NIST-approved methods and protocols into its design including:
- Elliptic Curve Diffie–Hellman (ECDH), NIST 800-56A
- Counter with CBC-MAC (CCM), NIST 800-38C
- Key Derivation, NIST 800-108
- Secure Hash Standard, FIPS 180-4
- Advanced Encryption Standard (AES), FIPS 197
Does anyone else see a problem with with the wording "NIST-approved methods and protocols?" NIST/NSA
Re:Called it by Alain+Williams · 2013-10-31 01:51 · Score: 5, Insightful

Registrant Country:US
I'd just feel a bit happier if the new effort was based somewhere other than the USA; somewhere a bit harder for the NSA to get its sticky paws into. I have in mind how the NSA screwed with IPSec. Mind you: discussion would have to be international, I am not sure how much harder it would make things for them if this was based in, say, Bolivia.
Re:Called it by slashmydots · 2013-10-31 02:10 · Score: 5, Funny

I knew you were going to post that.
Why DarkMail? by jotaeleemeese · 2013-10-31 02:31 · Score: 4, Insightful

Many outlets in the right wing media will have a field day with the name alone.
If one is going to try to occupy the moral high ground the choice of language really matters: you are framing the debate by how you word every single relevant item related to a given project, and which item will have greater visibility than the very name of your project?
By using such a name they are serving in a silver plate the opportunity to malicious, uninformed and naive commentators to badmouth whatever they come up with and that before having put forward a single detailed sentence about the proposal.
DarkMail may sound cool, but from the start is eliciting all the wrong kind of associations, I am sure many parties in the field could be interested to join such an effort, but the DarkMail name alone may put some people off.
The name really should be changed, these battles are difficult as it is, people shouldn't make it unnecessarily harder than it is going to be.
Let me put an example, lets compare these 2 headlines:
"Terrorists confess to using DarkMail"
and
"Terrorists confess to using PrivateMail"
Look, at the end I know it is the same thing, but while a headline would push many to say "yeah, tell me something new" the other may elicit comments of the kind of "What? That is what I use to email my bank"
I really think that name ought to go.

--
IANAL but write like a drunk one.
It already exits and is free by shellster_dude · 2013-10-31 04:03 · Score: 3, Interesting

Bitmessage: P2P, encrypted, anonymous. The project is pretty new, but other than a couple scalability issues, I think this project has major potential. http://bitmessage.org/
Re:Maybe they should change the name by c0d3g33k · 2013-10-31 04:16 · Score: 3, Informative

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