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

Comments

Did the NSA just kill SMTP?

[Defenestrar]

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.

Re:Did the NSA just kill SMTP?

[Vanderhoth]

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.

Re:Did the NSA just kill SMTP?

[jones_supa]

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.

Re:Did the NSA just kill SMTP?

[UnderCoverPenguin]

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))

Another mail protocol

[gmuslera]

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

[Anonymous Coward]

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.

Re:Dump SSL / Certificate-based Security

[CimmerianX]

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.

Re:Dump SSL / Certificate-based Security

[CreatureComfort]

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.

Thanks Snowden

[Jakosa]

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

[imatter]

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

[Alain Williams]

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

[slashmydots]

I knew you were going to post that.

Why DarkMail?

[jotaeleemeese]

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.