Silent Circle, Lavabit Unite For 'Dark Mail' Encrypted Email Project 195
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."
Dump SSL / Certificate-based Security (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.
Re:Dump SSL / Certificate-based Security (Score:5, Insightful)
Re:Dump SSL / Certificate-based Security (Score:4, 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).
right from the white paper (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:
Does anyone else see a problem with with the wording "NIST-approved methods and protocols?" NIST/NSA [epic.org]
Re:Dump SSL / Certificate-based Security (Score:3, Insightful)
As soon as you trust key servers you have the same issue as the root CA's they can be manipulated.
PGP/GPG potentially works rather well, it's weakness is having to move around and validate public keys. The secondary issue is halving to store them on a PC. An opensource smartcard device would seem to deal with the second part. But centralized key stores just beg to be abused.
Re:Called it (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 [wordpress.com]. 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:Did the NSA just kill SMTP? (Score:5, Insightful)
Re:Dump SSL / Certificate-based Security (Score:5, Insightful)
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.
Why DarkMail? (Score:5, 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.
Re:Dump SSL / Certificate-based Security (Score:4, 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.