Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted about a year ago | from the it's-so-spooky dept.

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

Sorry! There are no comments related to the filter you selected.

Right now ... (1)

Anonymous Coward | about a year ago | (#45289647)

The /. Page says, "There are no comments." Well, duh, they're encrypted so the browser doesn't recognize them.

Re:Right now ... (1)

Cryacin (657549) | about a year ago | (#45289811)

So secure, you can start emailing passwords again.

Re:Right now ... (1)

Runaway1956 (1322357) | about a year ago | (#45290957)

Well, the NSA has already cracked it. I can see your posts now . . . .

Did the NSA just kill SMTP? (5, Interesting)

Defenestrar (1773808) | about a year ago | (#45289651)

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 [arstechnica.com] about it too.

Re:Did the NSA just kill SMTP? (1)

Anonymous Coward | about a year ago | (#45289757)

Just posting anonymously (as to not undo mods) to say, I wish there was a +1 Hopefully mod.

Thanks Snowden (5, Interesting)

Jakosa (667951) | about a year ago | (#45289805)

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!

Re:Thanks Snowden (0)

Anonymous Coward | about a year ago | (#45290147)

Tech was always going to fix the problem anyway. Quietly, incremental fixes to the damage the NSA did.

It was just whether anyone would dare stick up their heads and complain the NSA & GCHQ had seized power in a bloodless coup. You risk being labelled a terrorist for having something to hide. A little **** named William Hague said ordinary people going about their lawful business had nothing to fear. Implying if you complained you weren't a lawful or an ordinary citizen. Want to stick up your head now? And have the security industry spy on you using an illegal warrant signed by this ***** politician without a judge to review it? That is what the situation is in the UK.

UK still is dodgy, GCHQ are still doing mass surveillance illegally of Brits, and Cameron & MI5 are still attacking the free press. William Hague's implied threat still hangs over you.

But things are getting better, people feel freer to speak out, there is momentum there.

Re:Thanks Snowden (0)

Anonymous Coward | about a year ago | (#45290501)

It's problematic if becomes some niche thing like Tor, which the NSA knows to zoom in to, as the people with something crucial to hide might be found there.

Re:Did the NSA just kill SMTP? (0)

cdrudge (68377) | about a year ago | (#45289883)

Did the NSA just kill SMTP?

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.

Re:Did the NSA just kill SMTP? (5, Insightful)

Vanderhoth (1582661) | about a year ago | (#45289963)

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? (4, Informative)

jones_supa (887896) | about a year ago | (#45290135)

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? (1)

jbolden (176878) | about a year ago | (#45290667)

When the internet was built everyone used their real names tied to a work address and they were military or academic associated with the military. There was no privacy so no particular reason to spy.

Re:Did the NSA just kill SMTP? (4, Informative)

UnderCoverPenguin (1001627) | about a year ago | (#45291005)

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

Re:Did the NSA just kill SMTP? (3, Interesting)

mlts (1038732) | about a year ago | (#45290387)

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.

Re:Did the NSA just kill SMTP? (1)

wmac1 (2478314) | about a year ago | (#45289977)

I wish they would also do something fundamental about spam problem. But that would possibly means unique id for senders which would ruin anonymity.

Re:Did the NSA just kill SMTP? (0)

Anonymous Coward | about a year ago | (#45290019)

Unique per person/company. Perhaps registered addresses with a record bound to the company/person's real identity.

Re:Did the NSA just kill SMTP? (0)

Anonymous Coward | about a year ago | (#45290585)

Or use proof-of-work such as HashCash.

Re:Did the NSA just kill SMTP? (1)

mlts (1038732) | about a year ago | (#45290143)

What I fear is that we trade in a protocol at sort of works for one that is patent encumbered or has some unknown issues in it.

Re:Did the NSA just kill SMTP? (3, Informative)

V for Vendetta (1204898) | about a year ago | (#45290685)

They want to build it upon XMPP, according to the Ars article [arstechnica.com] I read earlier this day.

Re:Did the NSA just kill SMTP? (1)

Gerzel (240421) | about a year ago | (#45290463)

And it won't go anywhere at least as they are selling it now. Darkmail? Protect against the NSA? To get widespread adoption you have to sell this as security and as an upgrade not as armor or defense. You have to make Grandma an Grandpa want to have it to help stop what to there minds are hackers and spammers.

Re:Did the NSA just kill SMTP? (0)

Anonymous Coward | about a year ago | (#45290553)

It shouldn't matter what transport protocol is used because everyone should be using end to end crypto and not relying on others to keep their confidentiality.

Called it (1, Informative)

slashmydots (2189826) | about a year ago | (#45289673)

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.

Re:Called it (1)

Anonymous Coward | about a year ago | (#45289737)

Congrats, you could see the same thing everyone else could. You are quite the Nostradamus.

Re:Called it (5, Funny)

slashmydots (2189826) | about a year ago | (#45290121)

I knew you were going to post that.

Re:Called it (0)

Anonymous Coward | about a year ago | (#45289777)

Wow, two days ago. You're practically psychic.

Jon Callas: NSA Exploit Isn't Crypto, It's SMTP [cryptome.org] : 30 August 2013

Domain ID:D50853670-LRMS
Domain Name:DARKMAIL.INFO
Created On:17-Oct-2013 17:36:20 UTC
Last Updated On:17-Oct-2013 17:37:29 UTC
Expiration Date:17-Oct-2014 17:36:20 UTC
Sponsoring Registrar:Network Solutions, LLC (R122-LRMS)
Status:CLIENT TRANSFER PROHIBITED
Status:TRANSFER PROHIBITED
Registrant ID:27619050-NSI
Registrant Name:Merrymeet
Registrant Organization:
Registrant Street1:2134 Ardis Drive
Registrant Street2:
Registrant Street3:
Registrant City:San Jose
Registrant State/Province:CA
Registrant Postal Code:95125
Registrant Country:US
Registrant Phone:+1.4084486801
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:jon@MERRYMEET.COM

Re:Called it (5, Insightful)

Alain Williams (2972) | about a year ago | (#45289951)

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:Called it (1)

Alain Williams (2972) | about a year ago | (#45289971)

Before I get flamed: the above was not intended as a slur against the guys at Lavabit and Silent Circle.

Re:Called it (0)

Anonymous Coward | about a year ago | (#45290431)

Turks & Caicos Islands seems like an ideal location of this encrypted email service to establish its headquarters and operations centre. Nice climate, isolated from any random visits by foreign law (cough, cough) enforcement. A wealthy person could probably finance the island's military and guarantee 24x365.25 air and naval surveillance with shoot-down authorization. Maybe a joint military pact with Cuba if only to annoy the US Government and the raving lunatics in Miami.

Re:Called it (0)

Anonymous Coward | about a year ago | (#45290511)

The darkmail.info alliance information website domain name was registered with a California address. The server itself, 23.92.22.66, looks to be also looks to be in the US. This is the alliance information site, not the actual DarkMail service servers (which do not yet exist).

Re:Called it (0)

Anonymous Coward | about a year ago | (#45290987)

A wealthy person could probably finance the island's military and guarantee 24x365.25 air and naval surveillance with shoot-down authorization.

What's in it for the "wealthy person"? And "shoot-down authorization" doesn't really help - you shoot down a drone circling around, and next thing you know, you've got a thousand troops with the attendant air/sea support on your doorstep, and plenty more where that came from if needed. Even Bill Gates doesn't have the money to finance something that will help against that.

Re:Called it (1)

ArbitraryName (3391191) | about a year ago | (#45291089)

The Turks & Caicos are British.

Re:Called it (2)

BitZtream (692029) | about a year ago | (#45290559)

IPSec was an international effort ...

Re:Called it (0)

Anonymous Coward | about a year ago | (#45289979)

self-signed

The problem with "signed" is that the NSA can self sign too. You know you're talking to exactly one person, but who is that one person? Keyservers don't save you, the NSA just sets up shop one hop up from the keyserver and gives you whatever key they want you to get. Signing authorities aren't helping either, they're happy to sign for whoever hands them the cash, and that's not always even the NSA.

The other problem with self-signed email is that nobody appears to have bothered documenting how to do that with openssl. It's easy to get a signed certificate from somewhere else, you just open your browser (?!) go to their webpage https://nsa.keymaster.com/mail_cert.jsp [keymaster.com] get a certain header that causes your browser (?!) to create a private key and a CSR, then send the CSR to the server where its signed and returns a certificate, that the browser can then export to be imported to your mail client. Even Mozilla's [mozillazine.org] page on s/mime links to a generic google search "how to create a self signed certificate" which is great if you want to use it on a webserver. Your self signed cert is not valid in any mail client, though, even if you've already registered your CA, because there's some flags on the cert that says not to use it for email. The magic incantation to create an email certificate is left as an exercise in frustration and obtuse commandline arguments.

There is something like that. (0)

Anonymous Coward | about a year ago | (#45289687)

i2p mail.

Another mail protocol (4, Interesting)

gmuslera (3436) | about a year ago | (#45289701)

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 [yahoo.com] ties [ibtimes.com] 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.

Re:Another mail protocol (1)

auric_dude (610172) | about a year ago | (#45289795)

It will have to be easy to use by anyone or else it will be just a case of "geek speeking only unto geek" and be no better than geek to geek via PGP over Gmail as things stand toay.

Re:Another mail protocol (1)

gmuslera (3436) | about a year ago | (#45290353)

If is standard and interception proof will be the required "mail" protocol in a lot of governments, organizations and companies. If the first implementation is not easy enough to use it will be shortly improved.

Re:Another mail protocol (1)

BitZtream (692029) | about a year ago | (#45290581)

So ... SMIME then ...

Seriously, if you think we need some new email encryption system, you haven't bothered to look at whats already available.

I for the life of me have no fucking clue why Lavabit or anyone else should have encryption keys that would allow them to give the NSA access to my encrypted email. They are doing it wrong.

SMIME solves the problem from the start, just like PGP but without the retarded 'build your own web of trust' crap.

Re:Another mail protocol (0)

Anonymous Coward | about a year ago | (#45290977)

SMIME is dead because the NSA will tamper the certs.

LOL (-1, Flamebait)

Havokmon (89874) | about a year ago | (#45289711)

It's going to be called 'LavaCircle'. And the whitepaper that's produced to explain it will include a lot of busy work and confusion, and the result will be locally encrypted/decrypted files.

Then, when someone asks how that can actually be secure, Ladar will throw a tizzy and claim all our constitutional rights are being trampled on.

Re:LOL Flamebait? (1)

Havokmon (89874) | about a year ago | (#45289869)

I didn't expect to get modded up - but Ladar's not the white knight that's being presented in the media (if anyone would actually read the documents [documentcloud.org] and see he bought it on himself), and I'm damn tired of it.

I read the documents. (2)

jotaeleemeese (303437) | about a year ago | (#45290497)

In p 31 he is asked to hand over the SSL and TLS keys for his service, which in practical terms it would allow the FBI to eavesdrop in the communications of *everybody* at will, this with all certainty would have meant a breach of contract with his users, lawsuits would have ensued. Would the FBI have paid for the damages?

Most importantly Lavabit was willing to comply with the original request, which was limited to a single email account.

You'll have to try harder if you want to dispel the positive aura around Ladar..

Re:I read the documents. (0)

Havokmon (89874) | about a year ago | (#45290621)

In p 31 he is asked to hand over the SSL and TLS keys for his service, which in practical terms it would allow the FBI to eavesdrop in the communications of *everybody* at will, this with all certainty would have meant a breach of contract with his users, lawsuits would have ensued. Would the FBI have paid for the damages?

Most importantly Lavabit was willing to comply with the original request, which was limited to a single email account.

You'll have to try harder if you want to dispel the positive aura around Ladar..

Of course he was asked to hand over the SSL keys, he refused to hand over the requested information in the first place.

Duplicating incoming and outgoing email, on a server you own and apparently WROTE THE CODE FOR, is trivial. Even Exchange can do it. Page 7 is the request for mailbox contents, but a separate device is NOT REQUIRED . It should be obvious that using SMTP means the data is in clear text until it's encrypted - at rest.

At best, he's an incompetent admin, and you want him to secure your email?

Re:LOL (0)

Anonymous Coward | about a year ago | (#45290481)

It's going to be called 'LavaCircle'.

And then mistyping the domain will get you a date on LaveLife. ;-) That should be enough to confuse the NSA. "Hey Bob! PRISM is reporting an uptick in traffic for LavaLife. Are you flirting with the secretarial pool over at DoD again?

CAPTCHA: misleads

Bitcoin (1)

Anonymous Coward | about a year ago | (#45289723)

Excellent. If they end up accepting Bitcoin (and have sufficient respect for FOSS) then I'll certainly sign up for a premium/professional account.

Dump SSL / Certificate-based Security (5, Insightful)

Anonymous Coward | about a year ago | (#45289727)

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

Anonymous Coward | about a year ago | (#45289789)

We already did. Use PGP.

Re:Dump SSL / Certificate-based Security (4, Insightful)

CimmerianX (2478270) | about a year ago | (#45289799)

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 (3, Informative)

grub (11606) | about a year ago | (#45289825)

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.

Re:Dump SSL / Certificate-based Security (2, Insightful)

silas_moeckel (234313) | about a year ago | (#45289893)

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:Dump SSL / Certificate-based Security (3, Informative)

mlts (1038732) | about a year ago | (#45290073)

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.

Re:Dump SSL / Certificate-based Security (2)

mlts (1038732) | about a year ago | (#45290207)

The advantage of key servers is their replication and the fact that keys can be validated to check for tampering. If the key server is damaged and completely compromised with every key on there being swapped out with a bogus key, it will end up being evident when people check signatures and even though the keys on the server might have signing connections, none of the keys have any valid signatures.

Replication also is a good thing. An attacker can add a key with the same name and ID, but not the fingerprint. If someone deletes keys on one keyserver, it only will affect that keyserver. To remove a key requires hacking all the keyservers that replicate with each other, and then, if just one has the key, it will re-replicate.

Endpoint weakness is also important, and a good point. There are cryptographic tokens, but GPG realistically doesn't support them (I've tried), so one would have to use the commercial version of Symantec's product to generate/store/use tokens. However, tokens do provide a security increase since the key never leaves the device, and the device does the signing/decryption.

What I'd like to see is an "open source" cryptographic token that can work with gpg. This way, the worst an attacker can do is intercept the token's PIN and generate a bogus signature, but the key material is kept secure regardless.

Re:Dump SSL / Certificate-based Security (1)

silas_moeckel (234313) | about a year ago | (#45290521)

You can go even further with requiring the user to approve the key signing even potentially displaying info about whats its doing.

Re:Dump SSL / Certificate-based Security (1)

heypete (60671) | about a year ago | (#45290237)

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.

The key servers don't need to be trusted, at least not in the same way that certificate authorities need to be trusted. The keyservers don't do any sort of crypto at all. They simply store keys that users submit to them and retrieve those that users request.

Someone can simply say "Hey, I have a PGP key with $FINGERPRINT. You can get it on the keyserver." and one can retrieve it. It's trivial to validate that a key retrieved from the keyserver matches the fingerprint given by the expected person.

While not immune to manipulation, keyservers can be difficult to trick: they're append-only (there's no way to remove data from keyservers) and they sync with each other. All keys are self-signed and many are signed by other users. If one keyserver were modified such that a key was altered, that is easily detectable and the changes would likely be undone as the server syncs with others.

Could one upload keys that falsely claim to be someone else? Sure, but that's not a problem with the keyserver, but rather a problem with human validation of fingerprints and other details. In the end, one needs to verify the fingerprint on the key.

Re:Dump SSL / Certificate-based Security (1)

silas_moeckel (234313) | about a year ago | (#45290549)

And your still back to if you send that fingerprint in the clear along with the message it can be manipulated, or passing them around which is impractical at scale.

Re:Dump SSL / Certificate-based Security (4, Insightful)

CreatureComfort (741652) | about a year ago | (#45290289)

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.

Re:Dump SSL / Certificate-based Security (1)

mlts (1038732) | about a year ago | (#45290525)

Devil's advocate:

Maybe the mail client should focus on having a layer of security for protecting data and metadata, but the actual message should be handled by PGP, or at least a separate, independent mechanism?

The reason it is good to have message encryption separate is because OpenPGP has been around longer than SSL, and has stood the test of time. A lot of people use webmail, and if all the security is "baked into" the client, all it would take is for an intruder to compromise the webserver, as opposed to end to end encryption which only gets decrypted on the client side.

Re:Dump SSL / Certificate-based Security (3, Insightful)

jbolden (176878) | about a year ago | (#45290713)

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.

Re:Dump SSL / Certificate-based Security (0)

Anonymous Coward | about a year ago | (#45290619)

Mod parent up

Re:Dump SSL / Certificate-based Security (1)

silas_moeckel (234313) | about a year ago | (#45290659)

2 Trivial to mitm
3 You just inserted the NSA's public key
4 Your happily encrypting the email for the NSA: mitm box
5 Again trivial to mitm

Trust is hard and nearly impossible to automate. PGP/GPG works extremely well in small groups where they can exchange keys face to face, with it's weakness being the machines that store those private keys and the people that own them.

Re:Dump SSL / Certificate-based Security (0)

Anonymous Coward | about a year ago | (#45291125)

You should offer the good people developing Mailpile [mailpile.is] a piece of your mind. This might be right up their alley.

Re:Dump SSL / Certificate-based Security (2)

SirGarlon (845873) | about a year ago | (#45289905)

Generate a keypair, uploaded to the keyservers automatically, install mail plug in.

You missed the part where you need to get the key signed, or no one can verify it's actually yours. That's the sticking point.

Re:Dump SSL / Certificate-based Security (1)

BorelHendrake (1496471) | about a year ago | (#45290075)

Perhaps I am missing something here...

PGP is a public key system. If you are going to be doing a mail system based on this, it seems to me that the receiving email client would check to see if the public key associated with the email address is on file. If not, request the public key from the email address. If the key is on file it could even check and verify that it is the same. If it is different, throw a warning.

I don't see that there is a need for central key distribution.

Re:Dump SSL / Certificate-based Security (1)

jbolden (176878) | about a year ago | (#45290727)

Replay you scenario and assume that there was a man in the middle attack.

Re:Dump SSL / Certificate-based Security (0)

Anonymous Coward | about a year ago | (#45290113)

PGP/GPG is boneheaded easy to use these days. Generate a keypair, uploaded to the keyservers automatically, install mail plug in.

You know what my 65-yr old mother's face would look like if I tried explaining this to her? Or even a non-techie my own age. Keypair? Yes, I have a pair of keys to my house. What about them? Mail plugin? I have to plug in my mail now? Is that what you call putting it in the box outside my door?

This will never happen among the common users in the world, no matter how simple you think it is.

Re:Dump SSL / Certificate-based Security (0)

Anonymous Coward | about a year ago | (#45290835)

Congratz, you have discovered why only geeks ever use computers... right?

Just do the setup for your 65-yr old mother, and while you're at it also install an adblocking plugin on her browser.

Re:Dump SSL / Certificate-based Security (2)

mlts (1038732) | about a year ago | (#45290225)

This varies on platform:

On Windows, the port of gpg isn't that great. The best solution is Symantec's PGP, but for a registered version is $250 or so.

The gpg port on OS X is pretty good and constantly updated.

Linux is decent as well.

I do wish Symantec would lower their price on their "Symantec Encryption Desktop", which they renamed PGP Desktop. I'd be pretty sure they would make money hand over fist on volume because a lot of people are security-conscious now.

Re:Dump SSL / Certificate-based Security (3, Insightful)

landoltjp (676315) | about a year ago | (#45289875)

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

Re:Dump SSL / Certificate-based Security (1)

BitZtream (692029) | about a year ago | (#45290613)

If the envelope isn't in the clear, the message can't be routed. There are certain bits that have to be visible in order for things to work. If my mail server can't read the envelop, it can't direct the mail to anyone.

Re:Dump SSL / Certificate-based Security (2)

jbolden (176878) | about a year ago | (#45290769)

I replied above. You can avoid this. Here is how.

A routes to B with an envelope that C can read.
B sends to C who reads the envelope and forwards to D.

B doesn't know where the message was going.
C doesn't know where the message came from.

Re:Dump SSL / Certificate-based Security (0)

Anonymous Coward | about a year ago | (#45291033)

Then pull the mail in stead of pushing it?

When I was travelling around the world in the 20th century, I went to the GPO after arriving and before leaving a major city to check if there was any mail for me. My friends and family knew that in January I would check mail in Delhi, in February in Bombay, in June in Bangkok and in November in Jakarta.

Now replace the GPOs with a set of servers. I publish a list with which servers I check along with my public key. You send a message for me to one of those, I pull it from there using my private key*. Millions of people share the same servers, there is no unencrypted sender or receiver.

* I'm no expert at all on private/public keys, but somebody who is might fill in the gaps I've left open.

Re:Dump SSL / Certificate-based Security (1)

jbolden (176878) | about a year ago | (#45290753)

To avoid envelope in the clear that you need to do something like Tor where you have intermediaries and those intermediaries need to be trusted. They also have to be willing to do 2x the current volume of email traffic. Who plays that role?

Re:Dump SSL / Certificate-based Security (3, Informative)

davecb (6526) | about a year ago | (#45289929)

PGP's author is somewhat aware of that (;-)) He's a principal at Silent Circle

Re:Dump SSL / Certificate-based Security (1)

ZaphDingbat (451843) | about a year ago | (#45289983)

Unless companies who want their corporate information to remain secret adopt it first and force some progress.

Re:Dump SSL / Certificate-based Security (0)

Anonymous Coward | about a year ago | (#45290389)

PGP web of trust doesn't scale, and they have more points that they can compromise.

An other trust model is needed, but PGP is not the answer.

Re:Dump SSL / Certificate-based Security (2)

DrXym (126579) | about a year ago | (#45290059)

It's too bad http doesn't dump CAs as well, or rather the rigid model that is adopted now. It's basically a tax on security and clearly many sites choose to have no encryption at all rather than pay this tax. So any site should be able to present an unsigned key to a browser and and instantly benefit from encryption. The browser shouldn't object to this either (unless the site used to present a signed cert) since it is still better than plain text even if it permits man in the middle attacks.

And if a site wants something more then they should be able to have their key signed by their buddies, business partners, trade associations, governments, and yes even CAs to build a web of trust. So a bank might well pay a CA for a signature, but it might also get a signature from its banking federation, it's rival / partner banks, the government, and a business bureau. If the cert suddenly changes, or if any of the signatures mysteriously change then the browser has the knowledge necessary to warn a user. That makes it far harder to compromise the security. It also means that no site has to pay a CA for the privilege of security. It might be advantageous to do it for a bank or suchlike, but smaller operations would build out a more organic trust model.

How a browser presents this information falls outside of this. I don't see it being especially different from how browsers present this information now except it would be more important to users to know when the information changes, rather than when it doesn't.

Re:Dump SSL / Certificate-based Security (3, Informative)

heypete (60671) | about a year ago | (#45290303)

StartSSL [startssl.com] 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.

Re:Dump SSL / Certificate-based Security (1)

BitZtream (692029) | about a year ago | (#45290629)

You're perfectly free to setup your own 0 cost CA. Of course, running a CA does in fact cost money, so you'd have to be throwing money away to do so, but hey, its certainly possible.

Re:Dump SSL / Certificate-based Security (0)

Anonymous Coward | about a year ago | (#45290361)

Actually, SSL and certificates are perfectly fine for decentralized, peer-to-peer trust networks, trust-noone-by-default, transitive trust and transitive trust that decays over distance. Or whatever you'd like to establish trust.

Really the only thing that is badly designed about it that there is something like root CAs that are trusted by everyone by default. Screw that, replace it by something closer to reality, and SSL works again. No need to reinvent all wheels when only one is broken.

Re:Dump SSL / Certificate-based Security (2)

Bob9113 (14996) | about a year ago | (#45290589)

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.

Bear in mind that the CAs do not have copies of the private keys. When you have a CA sign your cert, you do not send them the private key that you generate. So the CAs cannot give your private key to the NSA to facilitate an MITM attack.

It is possible for them to generate a phoney cert to which they do have the private key, and they could give that private key to the NSA. But that would be detectable by programs like The Eff's Observatory [eff.org] , which monitors for key changes. If they tried a MITM attack with a monitored site on any significant scale, it would be detected (and you can run your own plugin if you want).

The problem with both Silent Circle and Lavabit is not SSL itself, but that they are a central organization that held the private key to many people's comm -- people who wanted strong security on their comm. That is a huge bank of high-value cleartext; an irresistable resource node to a group like the NSA. The root problem is not Root CAs, but centralized "secure" storage (and a government that has betrayed its nation -- though even without the NSA, those irresistable resource nodes would still be a threat, attracting abuse from the likes of China and Facebook).

But I digress. My point is that SSL can actually allow true end-to-end security, as long as we use a "trust but verify" model, like the Observatory allows, not just blind trust. If we want to eliminate the high risk behavior that enabled the NSA's attack, we have to eliminate centralized "secure" stores -- no more unencrypted cloud storage, and no more password recovery from cloud services. Everyone has to manage their own private key (whether SSL, GPG, or other), and losing it means it's gone forever. To me, that's the big hurdle.

Alternately, we could restore the 4th amendment, which does a pretty damned good job of protecting your house, even though locksmiths may have copies of many private keys and anyone with a little training could break into most houses in a matter of seconds. Since keys and locks existed when the intent of the 4th was still well known and agreed, they have the level of government protection that encryption should have. Well, that and it would be hard for the NSA to break into every house; it's easy to break into everyone's email. Even if we all had our own private keys, it would still be easier to break into all our systems than doing houses. Now I'm really off on a tangent, though, so I'm just going to stop here.

Re:Dump SSL / Certificate-based Security (1)

BitZtream (692029) | about a year ago | (#45290597)

The root certs do nothing to fuck up SMIME, having own the root CA still won't help you get into my mail if I use SMIME

Metadata (1)

Meneth (872868) | about a year ago | (#45289755)

Looks SCIMP does not prevent an attacker from seeing when, to/from whom, and how much is beeing sent. I2P-Bote seems a lot better.

right from the white paper (5, Insightful)

imatter (2749965) | about a year ago | (#45289885)

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 [epic.org]

Re:right from the white paper (0)

Anonymous Coward | about a year ago | (#45290245)

Also, to me it sounds like the recipient needs to be online or you can't send them an "email", making it a instant messaging protocol rather than email.

Re:right from the white paper (0)

Anonymous Coward | about a year ago | (#45290643)

If that's the case, then it's no better than running your own private email server.

Re:right from the white paper (2)

inject_hotmail.com (843637) | about a year ago | (#45290465)

I do. 99% of all people have a seriously misguided concept of trust. Companies and citizens alike cannot maintain an allegiance to any person because they must bend to the will of law enforcement (notice I did not say 'law') and judicial commands (yes, it actually says "commands" in a subpoena).

If law enforcement officers successfully beg a judge, they can order any person or company to do anything they want (like spying on you, becoming an agent of the state). It's as simple as that. Do -not- trust anyone. If they have been subverted, you will not know until it is too late...Ladar Levison wanted nothing but to maintain Lavabit -- his own business predicated on security/secrecy (when it came out that he handed over SSL keys to authorities, no matter the reason, his business would crumble). The (federal) state compelled its demise under threat of -perpetual- imprisonment and fine, and so it fell.

Having said all that, even a non-NIST entity cannot be trusted. If a non-NIST crypto protocol contains any weaknesses, whether intentional or not, assuredly the NSA will obtain or discover it.

Re:right from the white paper (1)

imatter (2749965) | about a year ago | (#45290551)

agreed!

Re:right from the white paper (1)

onyxruby (118189) | about a year ago | (#45290837)

Remember that NIST standards and protocols are typically the same one the US requires for it's own use. What your proposing is either that the US would use known bad protocols for it's own use or would be making an epic scale security through obscurity blunder. You can't have a back door that only works for you, if it's in there any given foreign agency could discover it and use it. That simply doesn't pass the sniff test or Occam's razor.

What does concern me with the proposed standard is that they want to use certificates signed by a third party. You can't do that without having a dependency on someone that can be forced by a court order to work against you. This isn't a US specific issue either as other countries can and do use court orders to compel certificate authorities to cooperate.

Remember the only thing trust does with SSL and a certificate is verify a chain of identify. When your chain of identity is subject to a MITM attack or a warrant you have a standard that is for all intents and purposes next to worthless.

Maybe they should change the name (2)

Jakosa (667951) | about a year ago | (#45289913)

Why call it Dark-Mail? Grandma should be able to use... Dark Mail? Like she was a Sith-lord. What about PBP Pretty Better Privacy?

Lovely - now, if they'd only tackle spam ... (2)

eer (526805) | about a year ago | (#45290013)

In other news, open source community takes another swing at Privacy Enhanced Mail, but this time with no trust anchor ...

I'm still not convinced that anonymity and accountability can coexist. At the very least, they need their servers to be accountable for the anonymity assurances given to their users.

What problem are they solving? (0)

Anonymous Coward | about a year ago | (#45290037)

That can't be solved by using PGP?

I'm sure I'm missing something, but what? ;)

Re:What problem are they solving? (1)

jotaeleemeese (303437) | about a year ago | (#45290185)

Ease of use.
Consistent protocol for exchange of encrypted mail (which could be based on PGP).
Key decentralization and anonymitation ....

Using PGP is a PITA in most stand alone systems (Windows, OSX, Linux) relies in way too much trust as well (how do you know that PGP key is legit?), and it isn't implemented at all in big emailers (Gmail, Yahoo Mail, Microsoft's whatever it is called this week, etc).

Re:What problem are they solving? (1)

mlts (1038732) | about a year ago | (#45290343)

PGP has one advantage -- it is completely separate and standalone from whatever messaging system is in use. Yes, metadata can be compromised, but the actual messages would be protected no matter how hosed the underlying protocol is.

In the past, I've used a lot of protocols to send PGP/gpg encrypted messages, be it AIM, UNIX ntalk, mail or write.

However, you are right. It is a separate step, and likely to a different app. However, it is good in a way that PGP is separate from the message medium.

Re:What problem are they solving? (1)

wiredlogic (135348) | about a year ago | (#45290461)

Even with PGP, the SMPT headers are unencrypted. This allows an attacker to build a graph of who talks to who. The central weakness of traditional email is that messages are passed around through multiple untrusted servers before they reach their destination.

This system depends on creating an encrypted link (presumably with tor-like indirection) and only passing messages direct from sender to receiver. The downside is that both parties have to be online to effect the transfer. The instant messaging aspect is used to notify a sender's server when a receiver is available to accept new (possibly cached) messages.

Re:What problem are they solving? (1)

tlhIngan (30335) | about a year ago | (#45290641)

Even with PGP, the SMPT headers are unencrypted. This allows an attacker to build a graph of who talks to who. The central weakness of traditional email is that messages are passed around through multiple untrusted servers before they reach their destination.

It's a central problem if you want two arbitrary people to talk to each other. Or if you just want to do a "blind broadcast".

Which makes those hacks to AIS and ADS-B really uninteresting because encrypting and authenticating the transfers is impossible - if everyone needs the key to decrypt the message, well that's pointless to the extreme since none of the parties has a way to fetch additional keys (so you can't verify the transmission anyhow - by the time you can do it, it's useless information). Sure, you could mandate PKI, but then everyone needs the same encrypting key so everyone else can decrypt it, and a hacker can easily get at the key. If you sign it, again, how do you verify it without the key? In this case, you might as well send it in the clear because encrypting it just means you'll have to get at a well known key and adds an unnecessary step.

And yes, as long as two random parties have to communicate, it's always vulnerable to metadata analysis.

This system depends on creating an encrypted link (presumably with tor-like indirection) and only passing messages direct from sender to receiver. The downside is that both parties have to be online to effect the transfer. The instant messaging aspect is used to notify a sender's server when a receiver is available to accept new (possibly cached) messages.

This cannot work because there are times when you'll be online and the recipient not, so you'll end up playing very fancy games of phone tag.

And even if encrypted, most protocols have sufficient "leakiness" that one can guess at what's going on.

And direct connections are subject to metadata analysis as well.

You're far better off encrypting the message and doing something like Tor to move it between machines - not only does this spread out the connections, but each node can only see the next node in line, and cannot be sure if the next node is the destination or relay.

Of course, the problem with that is it requires knowing the entire routing table in advance, and for reliability you probably want to send the same message through different paths and you need a way to identify when duplicates arrive.

Dark Mail - Confidential Mail (0)

Anonymous Coward | about a year ago | (#45290093)

Call it CONFIDENTIAL Mail, not "Dark Mail"!

Elliptical carousel of non-news (0)

ElitistWhiner (79961) | about a year ago | (#45290117)

/. please update, iteratively over time. Thank you.

Why DarkMail? (4, Insightful)

jotaeleemeese (303437) | about a year ago | (#45290295)

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.

Passing Keys (1)

XLT_Frank (2759563) | about a year ago | (#45290317)

When I thought about this problem, if you really want to hide the from/to, you need a third party intermediary. If you want to handle encryption of the subject and message, then a design that leverages P2P would be pretty adequate and acts like a plugin for your favorite mail client. It operates on a two part design, but it is easier to describe from the recipients point of view. When you receive an encrypted message it comes with a key. When you enter the passphrase for that key, it tells you how to retrieve the actual decryption key from the P2P network. The reason is that the key was broken into randomly sized packets, reordered, and dispersed. That key tells you how to retrieve those pieces and how to reorder them. There should be certain amount of overlap in the packets so that if one or two of the packets are missing, the message can still be recovered (this feature would be selectable option per the key that it came with).
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?