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

Right now ...

[Anonymous Coward]

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

Re:Right now ...

[Cryacin]

So secure, you can start emailing passwords again.

Re:Right now ...

[Runaway1956]

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

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?

[Anonymous Coward]

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

Re:Did the NSA just kill SMTP?

[cdrudge]

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?

[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?

[wmac1]

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?

[Anonymous Coward]

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?

[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?

[mlts]

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?

[mlts]

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?

[Gerzel]

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?

[Anonymous Coward]

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.

Re:Did the NSA just kill SMTP?

[Anonymous Coward]

Or use proof-of-work such as HashCash.

Re:Did the NSA just kill SMTP?

[jbolden]

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?

[V for Vendetta]

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

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

Re:Did the NSA just kill SMTP?

[Nerdfest]

That's what Apple did with iMessage. Extending XMPP doesn't mean it needs to be open.

Re:Did the NSA just kill SMTP?

[Tokolosh]

So when this has all played out, what will the NSA have achieved? Nothing, except a parasitic drain on everyone's resources and a layer of molasses over the whole system.

Re:Did the NSA just kill SMTP?

[Anonymous Coward]

Yea, probably something like their name, or first-initial + lastname for the unique id for larger companies. Then have a company identifier. You'd probably want to distinguish between different types of organizations though, so there'd be a higher level indicating that, like 'corp' or 'govt' or something. Different countries may also want to have a unique identifier as well. String it all together for something like:

jdoe.somecompany.corp
 
...crap...that looks too much like a regular FQDN. Oh! I know! Let's tie it into DNS, so you can use some sort of SRV record to figure out which server is handling the communication for that company. And we'd probably want to separate the user part from the organization part somehow with a character that's not valid in DNS then and also doesn't screw with regex too much.

I got it!

jdoe@somecompany.com
...

Re:Did the NSA just kill SMTP?

[dpilot]

Wrong.

They will have made us all less safe. While villanizing the NSA may be fun, and while they clearly have gone way beyond their mission, and while they are acting like real-life versions of Colonel Sam Flagg from MASH, one little fact remains.

There really are people out there who want to hurt us and cause widespread mayhem and destruction. I get the general impression that those same people want a return to the Caliphate, and would just as soon see technology worldwide return to that of the old Caliphate days. Though not in the US, not even in the Western world, every day someone is dying from this kind of thinking and action.

The threat may never have been as real or frequent as the NSA would like to present, but nevertheless the threat is there. But now they've stepped up, placed themselves as front-and-center villains, and taken our eyes off of people who really want to do harm.

As others have said, even if the NSA's motivations are pure as the driven snow, they're putting in place the machinery of a police state, simply waiting for someone "less pure" to take the helm.

It's your layer of molasses over the whole system, but it's necessary to remember it's optical properties, obscuring everything it covers.

Re:Did the NSA just kill SMTP?

[Anonymous Coward]

So when this has all played out, what will the NSA have achieved? Nothing, except a parasitic drain on everyone's resources and a layer of molasses over the whole system.

You mean, the NSA, the GCHQ, Russian & Chinese Intelligence agencies, etc. Not just NSA. Try to avoid the political rhetoric and pay attention to what is actually happening, please- this is far larger than just the NSA, they were simply the ones to get publicly caught with their hands in the cookie jar.

Re:Did the NSA just kill SMTP?

[dpilot]

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.

Re: Did the NSA just kill SMTP?

[Anonymous Coward]

I'd argue that villianizing the nsa makes us more safe (unless you believe that neutral actors have nothing to hide and therefore no one should have privacy) This whole mess has sparked a conversation with a large audience (rather than just the infosec community), which is a great thing in itself. Further, as others have expressed, this will hopefully encourage the development of more secure communications and security in general.

Re:Did the NSA just kill SMTP?

[Anonymous Coward]

With NSA, times have changed, as they can set up a MiTM attack anywhere and the wire cannot be trusted anymore.

I don't disagree with your overall argument, but this in particular is troubling. Encryption didn't spring into being in the last year or two when everyone started freaking out about the NSA. The times haven't changed in a long while. We're just slightly more aware of where they changed to all those years ago.

Re:Did the NSA just kill SMTP?

[Anonymous Coward]

Snowden did, with a little help from the NSA.

Re:Did the NSA just kill SMTP?

[Sabriel]

It occurs to me wonder if they've also scored a mission kill on the Fourth Amendment.

Consider these two paragraphs from https://en.wikipedia.org/wiki/NSA_warrantless_surveillance_(2001%E2%80%9307)#Fourth_Amendment_issues

The Supreme Court held in Katz v. United States (1967), that the monitoring and recording of private conversations within the United States constitutes a "search" for Fourth Amendment purposes, and therefore the government must generally obtain a warrant before undertaking such domestic recordings.

The protection of "private conversations" has been held to apply only to conversations where the participants have not only manifested a desire but also a reasonable expectation that their conversation is indeed private and that no other party is listening in. In the absence of such a reasonable expectation, the Fourth Amendment does not apply, and surveillance without warrant does not violate it. Privacy is clearly not a reasonable expectation in communications to persons in the many countries whose governments openly intercept electronic communications, and is of dubious reasonability in countries against which the United States is waging war. (emphasis mine)

So... thanks to the abject failure of the TLAs to keep their attempt at a global panopticon under wraps, such that it is becoming a reasonable expectation that the United States government is spying on everyone, including its own citizens within its own borders, does that mean the Fourth Amendment no longer applies to anything US citizens do on the phone/internet?

DA: "Your Honor, our surveillance showed the defendant read the Slashdot article about our surveillance, therefore he could not have had a reasonable expectation of privacy when our surveillance recorded the Skype conversation he had the following week with his partner in which he admitted to speaking in a free speech zone without a permit."

P.S. Sorry if I just ruined your reasonable expectation of privacy by posting this where you could read it.

Re:Did the NSA just kill SMTP?

[Anonymous Coward]

About 5,000 Americans die EVERY WEEK from heart disease, cancer and road accidents.

Perhaps, dpilot, you think the US Gov should spend a few trillion tax dollars waging a "War on Bees"?
After all, more Americans die every year from bee stings and peanut allergies than at the hands of people who "want a return to the Caliphate".

Oh, and people who really want to hide from the authorities already encrypt their communications.

Re: Did the NSA just kill SMTP?

[Anonymous Coward]

Looks like the new INET will be built inside the hollowing husk of the old one using different models and protocols inside the same old tubes. It's an arms race! Nothing to see for someone who isn't looking. Just another tick in an endless series of revolutions.

Dark Mail Alliance
http://feedly.com/k/16Lutbr

My favorite Dune quote fits well here =]

Explosions are also compressions of time. Observable changes in the natural universe all are explosive to some degree and from some point of view; otherwise you would not notice them. Smooth Continuity of change, if slowed sufficiently, goes without notice by observers whose time/attention span is too short.
Thus, I tell you, I have seen changes you would never have marked.
-Leto II

Re: Did the NSA just kill SMTP?

[Sigg3.net]

I agree that the threat is real. But we also must agree that there are real political issues that extreme groups are parasitic to; poverty, inequality, corruption and state (foreign or domestic) extortion.

The problem of terrorism isn't that they are "outside" the international community, but that they have reasons to, that are rational.

People are just people. They need proper incentive and motivation for letting themselves become extreme. We take away these incentives, extremists will become leaders of groups of one.

Re:Did the NSA just kill SMTP?

[BiggoronSword]

Since we're talking about XMPP, can I suggest Google Wave be brought to the table again?

Called it

[slashmydots]

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

[Anonymous Coward]

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

Re:Called it

[Anonymous Coward]

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

Jon Callas: NSA Exploit Isn't Crypto, It's SMTP: 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

[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

[Alain Williams]

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

Re:Called it

[Anonymous Coward]

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

Re:Called it

[slashmydots]

I knew you were going to post that.

Re:Called it

[Anonymous Coward]

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

[Anonymous Coward]

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

[BitZtream]

IPSec was an international effort ...

Re:Called it

[Anonymous Coward]

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

[ArbitraryName]

The Turks & Caicos are British.

Re:Called it

[fnj]

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 know the feeling. But let's explore this just a bit. Do you have any siggestions? I'm serious.

If the place is too small, it is open to bullying, all the way up to invasion.

If the place is so powerful the US cannot bully them, do you have any confidence at all that this other place will not itself constitute a serious potential threat to liberty and anonymity?

I would be attracted to the idea of Switzerland, except I am afraid they are too vulnerable in the area of commercial relations. Look what happened to invulnerable numbered Swiss bank accounts.

There is something like that.

[Anonymous Coward]

i2p mail.

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.

Re:Another mail protocol

[auric_dude]

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

[gmuslera]

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

[BitZtream]

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

[Anonymous Coward]

SMIME is dead because the NSA will tamper the certs.

Re:Another mail protocol

[Anonymous Coward]

And PGP is dead because unlike S/MIME, it's resistant to that attack, by requiring multi-party conspiracies. Can't have people using secure tech!

Re:Another mail protocol

[fnj]

But S/MIME suffers from the hopeless reliance on Certificate Authorities. The NSA preys on the Certificate Authorities and any pretense that your privacy exists is shattered.

Re:Another mail protocol

[HiThere]

Sorry, but that doesn't always happen. One may hope that with this group sponsoring it, it would, but PGP hasn't gotten much simpler to use in the last decade. And the only e-mail client I've notices encouraging it is KMail (which barfs on large mailboxes).

Re:Another mail protocol

[gmuslera]

For starters, SMIME don't hide metadata, with SMIME you encrypt the content, not headers. And if well there is TLS for securing the communication between servers, afaik is not very strong as protection or avoiding MITM attacks. But using SMIME and TLS is a start that should be used while no better solution is implemented.

Re: Another mail protocol

[Anonymous Coward]

Scrap old protocols all together and go straight point like SaluSafe did!

Bitcoin

[Anonymous Coward]

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

[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

[Anonymous Coward]

We already did. Use PGP.

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

[grub]

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

[landoltjp]

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

[silas_moeckel]

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

[SirGarlon]

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

[davecb]

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

Re:Dump SSL / Certificate-based Security

[ZaphDingbat]

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

Re:Dump SSL / Certificate-based Security

[DrXym]

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

[mlts]

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

[BorelHendrake]

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

[Anonymous Coward]

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

[mlts]

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

[mlts]

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

[heypete]

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

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

Re:Dump SSL / Certificate-based Security

[heypete]

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.

Re:Dump SSL / Certificate-based Security

[Anonymous Coward]

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

[Anonymous Coward]

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

[silas_moeckel]

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

[mlts]

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

[silas_moeckel]

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

[Bob9113]

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

[BitZtream]

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

Re:Dump SSL / Certificate-based Security

[BitZtream]

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

[Anonymous Coward]

Mod parent up

Re:Dump SSL / Certificate-based Security

[BitZtream]

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

[silas_moeckel]

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

[jbolden]

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

[jbolden]

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

Re:Dump SSL / Certificate-based Security

[jbolden]

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

[jbolden]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:Dump SSL / Certificate-based Security

[Anonymous Coward]

You've (re)invented onion routing.

Re:Dump SSL / Certificate-based Security

[UnderCoverPenguin]

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?

That is actually a short coming of the network itself. In theory, every smart phone or tablet could run its own email server to receive incoming email, so elide the need for the envelope. Still, the network will know which device connected to which other device. Even wireless mesh networks have to exchange routing information between nodes. Even if manufacturers did not include logging source/destination addresses in their devices, it would only take a few "compromised" devices to gather and forward the meta data.

Re:Dump SSL / Certificate-based Security

[DuckDodgers]

But if I download your public key, and instead of getting your real public key I get a dupe, when I send you the message you won't be able to decrypt it. You'll contact me through some other channel and explain that I sent you something with the wrong key, and we'll know instantly that the key server has been compromised.

The system works. The real problem is that what grub in the grandparent post calls "virtually automatic" and "boneheaded easy" is still past the skill, understanding, and especially interest level of 99% of the population. Something even more automatic and easy is required if we expect the general public to have truly private email.

This is the same fundamental problem that makes the Diaspora distributed social-network project a non-starter. It requires too much technical knowledge and equipment for the average person to run their own node out of their house, which means that even if the general public had heard of the project and wanted to use it, they would be running it off publicly hosted servers run by businesses they don't know. Of course that totally negates the security and privacy advantages of a distributed social network. Something even easier, far easier, is required - like an application you install on your iPhone or Android phone with two taps of the finger that hooks up your private, distributed, encrypted, backed-up node on the NoAdvertisingNoNSABook network, and you don't do a damn thing to maintain it.

Re:Dump SSL / Certificate-based Security

[Cajun Hell]

As soon as you trust key servers you have the same issue as the root CA's they can be manipulated.

PGP doesn't trust keyservers; it uses keyservers.

Saying PGP trusts keyservers is like saying HTTPS trusts webservers.

Re:Dump SSL / Certificate-based Security

[DrXym]

I don't give a damn that you someone jump through hoops to get a cert for free or even a fee. Why the fuck should I have to ask somebody else for a cert at all?

It's a tax on security. I should be able to roll my own cert and at least benefit from crypto. If the nature of my business demands I sign the key I should be able to decide if I want to pay a notary / CA for a signature, or just get all my business contacts to sign it for me.

What I shouldn't have to do is what the current model requires. It's onerous, and it means insecurity by default.

Re:Dump SSL / Certificate-based Security

[DuckDodgers]

You don't have to trust all of the intermediaries, you only need one to be trustworthy for metadata privacy to remain intact. Otherwise, the worst they can do is block delivery of the message.

Consider that I have a message to send to my brother, and I route it through Tor nodes A, B, and C. I encrypt the message with my brother's public key and recipient address, then encrypt that with node C's public key and recipient address, then node B's public key and recipient address, then node A's public key (but not address). I upload the encrypted message directly to A. They know it came from me, but not the ultimate recipient or the contents. They decrypt their layer, and see it gets forwarded to B. They forward it to B. B knows it was routed through node A, but not that it came from me or the ultimate recipient or the contents. B decrypts their layer, and see it gets forwarded to C. They forward it to C. C knows it was routed through node AB, but not that it came from me or the contents. C decrypts their layer, and knows it goes to my brother. They send it to him, and he decrypts it with his personal key and reads the message.

If the NSA or hackers or whoever compromises node A, they know I sent something. If they compromise node C, they know my brother received something. If they compromise node B, they know a message from someone to someone was routed through. But they only know I sent something to my brother if they compromised all three nodes.

Your point about email volume still stands - on the other hand, if we encrypt everything by default and reject automatically anything sent by unrecognized public keys, spam should go down so much that mail servers will have extra capacity!

Re:Dump SSL / Certificate-based Security

[AmiMoJo]

I actually opened a bug/feature request for Thunderbird to implement creating GPG keys automatically and including them with every outgoing mail by default, but that was sever or eight years ago and it hasn't been acted on. I looked at the source myself to see what was involved, but gave up just trying to compile it for some reason (I forget now...)

Re:Dump SSL / Certificate-based Security

[DrXym]

The point I'm making is there should be no need for a CA.

I can roll a PGP key myself and it works of whether I have zero signatures, or multiple signatures. It's up to the recipient to determine if they trust me based on my signatures. The more signatures I have, the harder it is to fake or do a man in the middle, but even zero signatures means protection from casual eavesdropping.

That's how it should be for web certs. Roll your own. At a bare minimum you get encrypted communication. If someone wants more they can get their partner sites to sign their key. If they want more again, then then can pay for a CA and jump through the hoops it expects for this service.

But a CA signed cert should not be necessary just to get crypto in a browser. It should also be abundantly clear from recent events how illusory this security is. If someone has a compliant root CA they can do a man in the middle attack. It's far more difficult to do if the cert is signed by multiple signatories (since each would have to be compromised) and if the browser is capable of comparing the cert between sessions and alerting the user to major differences.

Re:Dump SSL / Certificate-based Security

[Nerdfest]

There's a Twitter/RSS replacement coming up via a Kickstarter (already funded) called Trsst. End to end public/private encryption, and it looks like a good design.

Re:Dump SSL / Certificate-based Security

[BorelHendrake]

If you are sending an email to somebody encrypted with their public key a MITM will not be able to decrypt the message because they don't have the private key.

Re:Dump SSL / Certificate-based Security

[AmiMoJo]

You could encrypt the headers when transferring mail between servers on the open internet, but ultimately the server itself needs to know the recipient email address. Most use other headers for spam detection too. In any case, the recipient email address is the minimum that must be sent, and some other headers are just implied so don't need to be intercepted to be recreated (timestamp, sending server address).

Re:Dump SSL / Certificate-based Security

[DuckDodgers]

I like the concepts used by LastPass and SpiderOak (assuming they're not lying their asses off...) for cloud storage. You choose your password. It gets hashed once, and that hash becomes your encryption key for AES or Triple-DES or some other symmetric encryption of your data. The encrypted data is uploaded to their servers, but never the encryption key. That encryption key gets concatenated with your password again, and hashed again, and that second hash becomes your authentication token for their respective cloud services.

So they hold your encrypted data, and they themselves don't have the original password or encryption key derived from it, so they can't decrypt it. SpiderOak has a web portal for emergency access to your data from any location, but they warn you in strong terms that using a web-only interface means they get access to your password and encryption key, and they advise against it.

Unfortunately, this doesn't work for hosted email because SMTP itself is a plain text protocol and of course your recipient won't have the same password (and thus, encryption key) as you. But I wrote this post because I think the very concept itself is cool and clever.

Re:Dump SSL / Certificate-based Security

[Anonymous Coward]

Bitmessage does this - not only are the messages encrypted like GPG, but it also uses a P2P network to hide metadata. Since everyone needs to download a lot of messages to avoid correlation, but doesn't have the bandwidth to download ALL messages, it uses several Bitcoin-like block chains.

Re:Dump SSL / Certificate-based Security

[jbolden]

You request the public key from the email address, the MiTM responds with his key...

Re:Dump SSL / Certificate-based Security

[BradMajors]

Thunderbird provides no way to search PGP emails. Until this long requested featured is added, PGP is not usable when using a Thunderbird client.

Re:Dump SSL / Certificate-based Security

[Anonymous Coward]

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.

The biggest problem with this system is spammers. With your system they get an easy way to ack the existence of an email address and no server-side spam filtering or ability for spam reporting from one user to apply to another. With end-to-end encryption, you can really only foolproof against spam with whitelists, which are tedious.

The COGS also goes up significantly. If you send an email to 50 users, there are now 50 unique copies that need to be stored instead of one.

Also, GMail will never sign onto a plan like this because they won't be able to deliver targeted ads by snooping through your mail. Ironic, no?

Re:Dump SSL / Certificate-based Security

[jbolden]

I agree with what you wrote. You'll see something similar one layer below. I don't even think you need A, B and C; A and B are fine as long as you trust A and B. You are right about spam though. The intermediaries could easily block spam at the same time.

My point is the companies with volume capable of handling huge volumes of email are likely susceptible to pressure to hand over keys.

Re:Dump SSL / Certificate-based Security

[BradMajors]

The solution is to send the email directly from the sender's PC to the receiver's PC without going through any mail servers.

Re:Dump SSL / Certificate-based Security

[Kjella]

The whole idea of keyservers is a big hack anyway due to SMTP having no support for encryption, mixing two entirely different issues. Are you john.doe@gmail.com or are you *that* John Doe that you're looking to mail to. It's gmail.com (verified through domain keys) that should be authoritative as to what your public key is (which you've preferably generated locally and uploaded, but depends on how much you trust the server) while authenticated and that you're talking to the real gmail.com should be verified through whatever anti-domain spoofing methods already exists. And finally you should have test clients query the server to check that it's really serving up the right public key. Once you've resolved that sending mail to john.doe@gmail.com will be encrypted to whoever is in control of that account and nobody else, maybe or maybe not it should be tied to a real person.

Re:Dump SSL / Certificate-based Security

[BorelHendrake]

This being a vulnerability only upon establishing the initial key. What you are really describing is not a MITM attack. Rather you are describing a situation where somebody is attempting to impersonate somebody else.

Re:Dump SSL / Certificate-based Security

[eth1]

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.

And how long before the NSA just gets court+gag orders that force the members of a target's web of trust to sign their bogus cert? Obviously the more people they do that to, the more likely it is the target will be notified, but I wouldn't put it past them any more.

Re:Dump SSL / Certificate-based Security

[Anonymous Coward]

If the end users aren't managing the keys, then what's the point of encrypting in the first place? If you want someone else to manage the keys you might as well just mandate the use of TLS between mail servers. The whole point of encrypting mail is to make it secure _from the servers_.

Re:Dump SSL / Certificate-based Security

[jbolden]

That sort of MiTM is fairly common in web transactions. It is often how people's bank accounts get stolen for example. Person goes to the wrong website, has what looks to them like a normal session with their bank and now their account information is stolen. A few days later....

So I think it is a realistic issue.

Re:Dump SSL / Certificate-based Security

[silas_moeckel]

If they are going to mitm one way they will do the same on the opposite way, so no you will not know everybody gets messages sources from the key they expected to the key they are using. If you want to get very crafty using a key that is a collision fingerprint would not be impossible, a huge rainbow table would be needed less if you can compromise the rng source.

Re:Dump SSL / Certificate-based Security

[mlts]

Yes, but that is the rub. It is a lot harder for $ADVERSARY [1] to compromise/coerce every endpoint in a transaction than it is to compromise core servers and CAs.

Nothing is 100% secure, and the XKCD cartoon about the $5 wrench does hold true... but good encryption and key management changes things from passive spying to active compromise, which is a lot harder, more expensive, and potentially more detectable.

Moving to a WoT raises the bar, just as using CAs raised the bar to protect against MITM attacks with a D-H exchange.

[1]: It could be the NSA, ISI, PLA, the Illuminati, or other group in this case.

Re:Dump SSL / Certificate-based Security

[jbolden]

You can have a different set of servers handling the keys and the mail. For example a bank could run a server doing doing key verification and management and then Google handle the mail.

Re:Dump SSL / Certificate-based Security

[silas_moeckel]

It trusts that they are giving accurate responses, your communication could be tampered with. They can hold incorrect data. They can be altered by legal means. A whole host of issues. They are more convenient than passing out keys everywhere, but are not going to stand up against state level tampering. HKP spreads the love around a bit, mitm a few thousand key servers is one thing potentially billions is another all together.

Re:Dump SSL / Certificate-based Security

[Anonymous Coward]

The problem with PGP is it makes the end user responsible for key management. End users don't understand encryption.

End users don't need encryption either. PGP was written for a small sophisticated group who had reason to keep their communications private from the government.
If you're part of the small group whose data the NSA would actually be interested in, you can certainly learn enough to manage your own crypto keys.

Re:Dump SSL / Certificate-based Security

[Agent0013]

If the email client accepts a public key automatically and adds it to the keyring, wouldn't that allow for MITM attacks and spoofing. All the NSA has to do is send a fake email to you with a new public key that is supposedly from someone you communicate with. Then you email client adds that fake key to the keyring and will encrypt any mail sent to that address with this NSA build fake key. They can read all the mail you send and if desired forward it on with the real public key to the proper user.

Re:Dump SSL / Certificate-based Security

[Anonymous Coward]

That's what XMPP can do...

Re:Dump SSL / Certificate-based Security

[heypete]

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.

The OpenPGP smartcard was developed by the primary developer of GnuPG. Pretty much any smartcard reader will work without issues -- I have an SCR355 reader for my desktop (it was plug-and-play on Windows and Linux) and the built-in reader in my Lenovo laptop and both work fine.

There's also the GPF Crypto Stick, which is the same smartcard in a USB token form factor. I also have one, and it works well (though I prefer the card form factor as cards fit in my wallet better).

Re:Dump SSL / Certificate-based Security

[DuckDodgers]

Good point about the two nodes instead of three. I don't know why I had it stuck in my head that three were required.

With the multi-step, encrypted transmission process it would make sense to use Google, Yahoo, Microsoft, etc... as nodes in the process, but if you want real privacy you and your recipient should host your own mail or use some other mechanism to keep your unencrypted message bodies from being in the control of the hosting company at any step in the process.

Re:Dump SSL / Certificate-based Security

[hodet]

This is wrong. Everyday users can benefit from PGP. I would venture to say that most people are not as worried about NSA snooping as they are from keeping their personal data stolen by criminals. They may not ask for PGP specifically or understand the details of encryption, but I think your average user would understand the benefit of using email to send sensitive info to the bank, or using electronic methods to discuss sensitive personal medical information with their doctor. Most people instinctively know not to use email for this without even realizing there are ways to do it securely. It's the implementation of it that leaves them cold. Small business are another segment that could benefit from it but just can't wrap their heads around it. An easy to use implementation that provided secure communication would see some uptake among people you wouldn't consider actually needing it today.

Re:Dump SSL / Certificate-based Security

[Anonymous Coward]

This is 100% true BUT it would require the attacker to actively (and pre-emptively) attack everyone all the time (which, as you probably know, requires much more resources than simply passive eavesdropping). Also, compared to simple passive eavesdropping, active MITMing is much more conspicuous, as it can be detected by someone with minimal technical expertise (e.g. confirm a random subset of the key's bits via telephone conversation). Passive dragnet surveillance is not on the same league as actively attacking every single key-exchange that occurs online.

As long as you can guarantee that the initial key exchange is untainted, everything would be secure from there on: meaning... they have to MITM your _first_ exchange; if they fail to do that, they are SOL.

Of course, the optimal solution would require OOB communications for that initial key-exchange (preferably AFK and using some method that requires low technical expertise).

Remember... unless you actually have something really secret/bad to hide and/or are ultra-paranoid, it's probably good enough to use a method that would make dragnet surveillance prohibitively expensive (money and/or computationally-wise).

Again, remember they can't MITM you after the fact. Compare that with the current situation where they can dig up crap on you retroactively, once/if you are classified as a "person of interest".

captcha: retard

Re:Dump SSL / Certificate-based Security

[jbolden]

You can't have any semi-private relationship with A or B or you break the whole point of not encrypting the envelope. Google, Yahoo... can't necessarily be trusted.

X sends message M to A (say google).
A records a message ID and forwards to B (say Yahoo)
Yahoo records google's message ID and forwards to Y

Google and Yahoo pass the message plus ID to NSA. Or to make it easier both Yahoo and Google share their private key for these transmissions and the NSA just reads the envelope.

Re:Dump SSL / Certificate-based Security

[Common Joe]

I wish. The last time I tried this with a friend of mine about 6 months ago, it failed. 6 months before that, it failed. Call me boneheaded if you want, but if I can't get it to work 100% of the time every time, then Joe User certainly won't either.

For the curious, I was trying to use Thunderbird with Enigmail. My friend just simply couldn't decrypt what I sent him... but I could decrypt his stuff just fine. No clue why it was rejecting my stuff for him.

Re:Dump SSL / Certificate-based Security

[david_thornley]

I don't think that will happen. The NSA seems concerned with the legality of its actions. This does mean pushing the limits on badly written legislation, and assuming favorable judicial interpretations, but I'm not sure they'd do anything flatly illegal. The courts won't.

There is legislation about communication hubs, and a lot of decisions that our data isn't ours once somebody else knows it. There is nothing about forcing anything like signing a certificate in the law, and I don't think the courts are going to allow it.

Re:Dump SSL / Certificate-based Security

[Cajun Hell]

It trusts that they are giving accurate responses

No. Please learn more about PGP.

No OpenPGP implementation assumes that any public keys, no matter where they came from, are accurate. The whole point of signing and the WoT is to not trust any key's accuracy unless you have reason to.

Keyservers can lie to you all day long. You can even manually import totally fraudulent keys, with the intent of deceiving the system. And it still won't matter. None of the keys in question will be trusted one iota, until you look at a fingerprint and sign, essentially saying "Yes, I know for sure that fingerprint came from that person."

PGP does not trust keyservers to be accurate, to be working right, to be working in good faith, to not be owned by your adversary, or anything else. Keyservers are a convenience, and nothing more. All this kind of stuff was figured out and dealt with, decades ago.

Re:Dump SSL / Certificate-based Security

[Cajun Hell]

All of that is okay to happen. Yes, it's trivial to MitM whenever you use an untrusted key, but it's also trivial to MitM plaintext, so you might as well use untrusted keys, until you get around to making them trustable. You lose nothing, except some CPU cycles.

What he is describing, is a baseline protocol for getting a bunch of untrusted keys deployed out there, and into ubiquitous use. You can still do things right, later, and have keysigning parties, check fingerprints etc, and start signing and trusting these keys, getting back up to the 1990s crypto-ideal.

Just don't have people signing these unverified keys without getting fingerprints out of band, don't have the email client showing bullshit "this is secure" icons, etc.

Really, the main problem with email clients automatically generating keys without any interaction at all, is that people move around, change machines, change clients on the same machine, log in as different users with different home directory, etc. I don't want my new machine generating a new key; I want it to stop and tell me "hey, I don't have your key yet." If I have to send an email in a hurry, from a new install, I don't want that email telling other people a silly keyid. If someone uses that one, and then I restore my home dir from a backup and now I have my "real" keys and the temporary one is gone, then someone is going to send me an undecryptable email, or mistakenly think we had a MitM when they see my temporary (bogus) on-demand-made one, etc. These are the kinds of flies in the ointment, that we really have to worry about, with the proposed approach.

The trust issue is trivial: don't trust an unverified key. That's was the rule for PGP twenty years ago and it hasn't changed.

Re:Dump SSL / Certificate-based Security

[Cajun Hell]

You know what my 65-yr old mother's face would look like if I tried explaining this to her?

It should look the same as her face looks, whenever she buys things on Amazon using https. When she clicks the little icon to see how she knows she's really talking to Amazon (that is, when she examines the cert) does she understand all that stuff? Does she know what Verisign is, and can she explain why she trusts Verisign, and what Verisign is saying about the cert?

If yes, then she can handle PGP.

If no ("what's a cert?"), then she can't handle https. Yet the world gets by with https anyway.

Re:Dump SSL / Certificate-based Security

[mlts]

Thank you. I just looked it up, and although they are out of stock, it is definitely something to consider, assuming the PKCS/11 driver is findable for it (this allows keyfiles to be stored with TrueCrypt, and though not as secure as using a keypair, it minimizes the time the file is exposed to a potentially compromised machine.

If it is a USB device, so much the better.

Re:Dump SSL / Certificate-based Security

[silas_moeckel]

You know that I know that, the unwashed masses do not nor do they care to. Oh the key server has one.let me click accept it's hard to get them to even compare the fingerprint with the footer. Key parties can be tainted just as easily. Sure calling a contact and exchanging fingerprints seems like loads of fun but it's impractical at scale. Tying key servers to domains via dnssec secured domains does not stop whatever country that domain is in from messing with things but makes it a lot harder.

90's crypto ideal works for those that will use it but it does not scale.

Re:Dump SSL / Certificate-based Security

[Anonymous Coward]

Assume for the moment that we are dealing with the low value information that we currently send encrypted. Given this assumption, the small loss of privacy for a potential MitM attack would not be worth the risk of discovery for the attacker, asuming that there was a way to validate the public key you received.

Man in the Middle depends on being "in the middle" of every communication. For example if the attacker misses the initial key exchange they cannot reasonably pretend to be Bob to Alice. Alice already knows Bob's key. If Alice and Bob have a way to verify key fingerprints, say with a text, or over the phone, or through a trusted third party then MitM fails, but more importantly exposes Eve to everyone else she is spying on.

It is not necessary for most people to even go this far. If only the security geeks consistently checked fingerprints, they would provide herd immunity to everyone against untargeted mass surveillance. Catching the NSA playing the man in the middle would cause large news stories and prompt everyone to start checking fingerprints for a while.

What this scheme would not do is protect high value communication. On the other hand, if one assumes there is sufficient economic value in the data, then there is also sufficient incentive to take the extra steps necessary to detect or even avoid the MITM.

Re:Dump SSL / Certificate-based Security

[Anonymous Coward]

It could be built into software including webmail with the new W3C spec that allows the generation of private keys in the browser.

Re:Dump SSL / Certificate-based Security

[Cajun Hell]

Sure calling a contact and exchanging fingerprints seems like loads of fun but it's impractical at scale.

Doing that is unnecessary at massive scale. What's cool about PGP is that you can do it, if you want MitM-proof protection, and that doing this seamlessly fits in with doing things the easy/unsafe way. If you don't care about MitM, then you don't have to do a lot of signing, and you can just fall back to the unverified key use that today's e-commerce uses. A system which "doesn't scale" is working just fine for amazon and your bank, except that some people say it's not "just fine" at all, because in the rare event that you actually care about security, the system doesn't let you create a second and better trust path than the one you have through Verisign. They say, "Huh, I don't remember meeting Verisign and getting their fingerprint and signing their keyid and also determining that I trust them a little bit. So how did this file get into my /etc/ssl/certs?" But that's the people who care. Let's get back to the unwashed masses...

People at the edge of the "unwashed masses" can move up and down across the threshold, go through phases of giving a damn about things, or sometimes simply by being pushed. PGP works great in an environment like that, where some people are apathetic and some people try. Want to have a keysigning party during a moment of enthusiasm and then go for a few years of not doing it? That's totally cool, and yet in the years after the keysigning party you get to benefit from it.

But you don't even have to do that. Consider this. Suppose your workplace (I'm assuming you work somewhere, where employees don't currently encrypt messages to each other, or else they use an obsolete system such as S/MIME) switched to something like what CreatureComfort suggests. Don't you agree that at least some employees (two? you and one other?) might make the effort to verify each others' keys? Or that some IT admin might go around to everyone (even the apathetic ones) and sign them and insist they at least sign him (sort of like what corporate S/MIME users do)? You'd get pretty much the same intranet security as S/MIME, except that the different social and business connections of each of the employees, would all be waiting to expand and make this local web start tying other webs together.

Then add something as simple as spousal signing (surely you'd agree that "sign your wife's key" scales! How many wives do you have?!), families (sign your brother, mother, etc) and suddenly you have inter-company MitM protection and other six-degrees-from-kevin-bacon-ness phenomena that I can't even being to describe or even imagine. I think you just might have it exactly backwards, in terms of such a thing not "scaling." All it takes is for people to sign a few people close to them, and things get very strong (compared to plaintext), very fast. It might not be foolproof, but it'd be better than the status quo that billions of dollars per year of commerce already uses. And everywhere you need to make it foolproof (i.e. you really care, so we're talking about a not-unwashed-masses situations) you use the same damn keys, but blow off the rest of the WoT (since you don't trust it enough) and directly cert someone/something.

And then probably share that signature on the WoT, for the next guy, if he doesn't have the time or quite enough passion to do that direct certification himself.

Re:Dump SSL / Certificate-based Security

[DuckDodgers]

I'm not sure I understand the problem. In your example, if Y has a public key, X encrypts the message with Y's public key, and Y's private key never gets to Google or Yahoo, then the NSA knows who sent the message and who received the message but not what it contained.

Again, that works in the real world. The problem isn't that the technology fails, the problem is that it's extra work. I can use public key encryption to secure my email. My wife, my parents, and my friends won't bother. If we that understand PGP band together and suddenly 0.03% of the SMTP traffic on the internet has encrypted message bodies, the volume is so low the NSA could designate resources to track the few people savvy enough to use encryption. Instead of getting more privacy, we get more surveillance on ourselves and no net benefit for the average citizen.

Re:Dump SSL / Certificate-based Security

[jbolden]

I'm not sure I understand the problem. In your example, if Y has a public key, X encrypts the message with Y's public key, and Y's private key never gets to Google or Yahoo, then the NSA knows who sent the message and who received the message but not what it contained.

You understand the issue. Knowing who sent what to whom, the envelope, is the metadata that people are objecting to. Encrypting messages if one doesn't care about metadata is a much easier problem.

_________

As for PGP . I agree this sort of thing needs to be part of email clients. But it is a hard problem to solve.

Re:LOL

[lxs]

It's a good thing that they already have a theme song.

Metadata

[Meneth]

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.

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!

Re:Thanks Snowden

[Anonymous Coward]

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

[Anonymous Coward]

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:Thanks Snowden

[Anonymous Coward]

Actually Snowden didn't do anything other than blow the whistle earlier than anticipated and expose the schemes in their entirety at the same time. It's the latter that has done the most damage. The extent of the virtual spying would have come to light piece by piece over time as evidence betrayed the existence of each method. The ramifications of this scandal have only now just begun to become apparent, with the potential rethinking of SMTP being the newest. It's the powers that be that assumed theirs was the right above all others for data across the internet. I guess my biggest issue is that with the potential international political clusterfuck that it turned out to be, why was it allowed to grow to the size it was to begin with?

Re:Thanks Snowden

[Anonymous Coward]

Let's hope it will be spam resistant too. Privacy and spam protection are hard to combine. Almost all spam fighting methods rely on metadata or text analysis, which should not be available in DarkMail (that's a bad name, BTW, from a marketing/business appeal POV). Instant messaging networks fight spam by centralization and XMPP open federation has been shown to be vulnerable to spam.

  The only way I can imagine a distributed, encrypted communication system to be spam resistant is to use some form of e-cash where each unbalanced sender (subscription list) must face increased scrutiny and manual authorization from the recipient. Regular email to a new contact should cost a Proof-Of-Work token (think of it like a Bitcoin), which you get back if you are contacted by a new person.

I would also like to see some form of anonymous mail-drop, where the encrypted emails are disseminated openly and the intended recipient is unknown. Also, anonymous mixmaster-style routing: layered encryption where the sender uses multiple intermediaries to hide it's insertion point into and identity to the recipient. Each step will require a POW token.

Re:Thanks Snowden

[cffrost]

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.

That's why one of the goals of the anti-surveillance movement is to increase Tor participation — the bigger it is, the better the protection (probabilistically-speaking) afforded to each participant. I use Tor (plus DNSCrypt) for everything I can, except for BitTorrent payload data... (For that, I use forced-RC4-160; unlike "plain" BT encryption, encrypts the payload in addition to the header. Yes, RC4 is very weak (even "broken"), but it's still a hassle for Eve compared to plaintext). It's worth mentioning that in a GCHQ slide provided by Snowden, they admitted "Tor stinks" because they "can't identify all users all the time, but can identify some users some of the time." — GCHQ/NSA really appreciates docile/ignorant users who stick with plain ol' HTTP so they can be identified all of the time.

I transfer several GB/day via Tor, and an order-of-magnitude more of encrypted BT traffic daily; I like to think that as an individual, I'm providing a substantial level of cover for people whose lives/freedom depend on the integrity of their encrypted connections: Journalists, dissidents, whistle-blowers, people in fear of being attacked by the corrupt DEA/BATFE/FBI/etc., gangs of thugs-in-uniform with their "parallel construction," planted evidence, personal vendettas, etc., a danger to which everyone within their reach is vulnerable to, provided they're not among (or sufficiently connected to) the "ruling class:" political elites, the very rich, etc., plus LEOs themselves. No one in this vast under-class is immune to false accusations, wrongful conviction, and having their lives destroyed by the violently aggressive US injustice system.

I'm also hoping to help protect other people who, like myself, simply don't enjoy having our human right to privacy, or our Fourth Amendment rights against unwarranted collection/examination of our private data being violated by criminal voyeurs in government, nor commercial entities that I paid to deliver data, not to examine/profile/monetize it (then turn around and sell it to the government).

Re:Thanks Snowden

[Anonymous Coward]

I have to say, William Hague has disappointed me greatly in government. One of the things we greatly lack in the UK is politicians who, once in government, are both willing and able to stand up to the civil servants who are intent on telling everyone (politicians included) what to think. For a while I thought Hague might be one of the few who could. Sadly, a string of recent events - including the Syria debacle (how did we ever get so close to taking military action without a clear military objective?) and the government's handling of the Snowden revelations most prominently - have made me change my view on that. As a firm believer in as small a government as possible with maximal rights for individual people, I've never felt like any of the major UK parties particularly matched my beliefs 100% but there always seemed to be a larger group of Conservative politicians - people like Peter Lilley, Alan Duncan, and David Davis for example - who aligned to my views compared with other parties (although there are some Lib Dems who I also admire) so I have historically voted for (and at one point I was a member of) that party. Now I don't know who to vote for next time I get the chance. I may not even bother voting.

But mostly I wonder what happened to my country to make it so that politics no longer seems to attract politicians who want to lead. People like Margaret Thatcher, Winston Churchill, or Lloyd George - who knew what they thought and more importantly knew that the civil service and the government worked for them, not the other way around.

Re:Thanks Snowden

[RivenAleem]

And now this! Not only has he shaken the political world-society, he has also [b]aroused[/b] the tech-world and made it possible to make some major changes.

The mental image this prompted has me disturbed.

Re:LOL Flamebait?

[Havokmon]

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 and see he bought it on himself), and I'm damn tired of 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:right from the white paper

[Anonymous Coward]

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

[inject_hotmail.com]

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

[imatter]

agreed!

Re:right from the white paper

[Anonymous Coward]

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

Re:right from the white paper

[onyxruby]

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.

Re:right from the white paper

[Anonymous Coward]

Shows how much you know about choosing the parameters of an elliptic curve... You CAN have a backdoor that is exceeedingly difficult to make use, if you're not the right person.

http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html

Maybe they should change the name

[Jakosa]

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?

Re:Maybe they should change the name

[c0d3g33k]

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

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

[eer]

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.

Re:Lovely - now, if they'd only tackle spam ...

[Anonymous Coward]

I'm still not convinced that anonymity and accountability can coexist.

You could just charge a "delivery fee". It requires that the public accepts a weird new form of money, but that seems to be happening anyways.

What problem are they solving?

[Anonymous Coward]

That can't be solved by using PGP?

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

Re:What problem are they solving?

[jotaeleemeese]

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?

[mlts]

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?

[wiredlogic]

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?

[tlhIngan]

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.

Re:What problem are they solving?

[Anonymous Coward]

How do you know if the key is legit? You send a test message: "Hello this me, how are you, yadda, yadda...". Same as talking on an encrypted phone - be careful what you say at first.

Dark Mail - Confidential Mail

[Anonymous Coward]

Call it CONFIDENTIAL Mail, not "Dark Mail"!

Elliptical carousel of non-news

[ElitistWhiner]

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

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.

Re:Why DarkMail?

[Teckla]

Maybe the DarkMail folks will create some cool icons, mascots, advertisements, etc. and label them all "Made in the GIMP."

Re:Why DarkMail?

[Anonymous Coward]

Or maybe they can create some terrible icons, mascots, advertisements, etc. and label them all "Made in the Dark".

Re:Why DarkMail?

[Anonymous Coward]

"If one is going to try to occupy the moral high ground the choice of language really matters:"

For debate's sake, let me throw this angle at you: Perhaps this is where the geek community starts to own the pejoratives, in a vein similar to black people calling each other 'nigga' or gay people calling each other 'queer/fag/etc'. One can see that there could not be a more receptive time than now/today amidst Snowden*****, to make the ignorant take a look at us and realize it was they and their ignorance that screwed all of us. I mean, today is the day the FAA device ban went (though as a geek, I think it would be saner to phase that in over a year or two and watch the statistics closely, but whatever...).

This is an information war, and what happens today is going to have an epochal effect on what cryptography is about for the next couple decades. Will cryptography be like the automatic machine gun, only allowed to the police because it is so genuinely dangerous? Or will it be allowed to everyone, because it is so genuinely useful. And I mean real crypto, real security. Something that even the koolaid drinking Googler's amongst their "shock" and "outrage" over NSA tactics. I mean Jesus F**cking Christ, what kind of doublethink has been going on with all those silicon valley geniuses that it took Snowden to get them to wake the hell up when it comes to fracking obvious security issues.

After we get done boiling alive all the f-ing traitors from the NSA and CIA that we can root out, we really need to start working on real security. And if the world can't get over calling it 'Darkmail' instead of 'Lightmail' or 'Lucifermail', then it's time to just give up.

Re:Why DarkMail?

[Monoman]

You are spot on. However, are we really surprised that folks who previously used names like Lavabit & SilentCircle understand marketing?

Re:Why DarkMail?

[G00F]

I agree, darkmail makes it sound bad at the start.

But I would go a step further, call it SMTPv2 (if changes to SMTP) or Mail 2.0, or webmail 2.0. A name that has no scariness in it. (other than playing off of web 2.0 crap) It will just sound like the logical next step and doesn't imply anything that the media can take as bad.

Re:Why DarkMail?

[Anonymous Coward]

> I really think that name ought to go.

Fascist.

Re:Why DarkMail?

[Anonymous Coward]

No. We are equally non-surprised that armchair experts such as yourself do absolutely nothing to help. But you're damn good at sitting at your computer criticizing those who do try to do something, though. I guess that's your talent.

Re:Why DarkMail?

[Anonymous Coward]

Nobody on the far right or far left gives a shit about what the average centerist Joe in the population thinks of him or her.
Which is perfect because having a significant number of passionate supporters is superior to having a larger number of lukewarm users when it comes to politics.

Passing Keys

[XLT_Frank]

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

Re:LOL

[Anonymous Coward]

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

I read the documents.

[jotaeleemeese]

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.

[Havokmon]

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?

It already exits and is free

[shellster_dude]

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/

MitM is a tolerable default

[Cajun Hell]

When I run that sim, as you suggest, the outcome I see is that you have the wrong key for someone's email address. You get MitMed.

(And in spite of the fact that you're being MitM, passive parties who are not involved in the attack, are still locked out. e.g. If the NSA MitMs your email to your wife, other observers are still seeing ciphertext, not plaintext.)

You're no worse off than if you hadn't ever encrypted; i.e. better than the status quo for 99% of users.

Furthermore, if you ever meet the person you emailed, or ever meet someone they met, and start to actually check and sign fingerprints, thereby creating WoT links, then the original attack eventually gets discovered ("Hey, I had a bogus wrong key on file for you. What happened?").

It looks like a decent situation, and an unambiguous upgrade from what people currently do. Can you find any downsides?

Re:MitM is a tolerable default

[jbolden]

MiTM responds with his key when you request the key.

The downside is you can't do this over and over again. You want to think through carefully key management and verification so that the system doesn't have to change again once people shift they shift for decades.

Re:MitM is a tolerable default

[Rich0]

MiTM responds with his key when you request the key.

Sure, but only if they're MITM when you request the key, and they're MITM every time you communicate.

If they're not MITM when you request the key, then the attacker has missed his only opportunity to swap out the key - further communications are secure and authenticated against the original key and cannot be intercepted.

If they do swap out the key and they aren't MITM for a subsequent communication then a message will get to its destination which is encrypted/signed with the wrong keys. The destination email client will toss up a warning that somebody is messing with their mail, and give instructions for how to do a proper key exchange with out-of-band fingerprint checking.

Think about the threat profile. Somebody monitoring your email probably doesn't want you to know that they're doing it. Any attack that involves extra hops is going to be difficult to pull off if you don't want to alert somebody, even without encryption. If you are actively swapping out keys via MITM this is much more detectable than a more passive attack. You're not going to do this for every single email sent on the internet. That means that when you discover a target of interest that you do want to MITM your opportunity for doing so will have largely past, unless they start communicating with somebody new. It also means that you need to follow at least one side of every conversation around perfectly if they send data wirelessly, via mobile, whatever. If one endpoint of every conversation involves a server whose ISP you control then that isn't too hard to pull off. If your point of interception is a cell tower, then good luck!

I think that anytime we have an unencrypted communication replacing it with an unauthenticated, encrypted communication with key history tracking is a significant step up. That isn't as secure as authenticated communication using TRUSTWORTHY certificates, but it is always better than unencrypted communication.

Oh, and 99% of what passes for authenticated communications on the internet is worthless. My browser must have 50 root CAs configured, and I have zero ability to audit any of them, and zero trust in the ability of anybody who does audit them to actually detect problems before they affect me. I don't trust them to keep me secure against non-governmental attackers, let alone the NSA.

What's different?

[Anonymous Coward]

So what makes this situation any different than the previous products they offered? What keeps the NSA from threatening them over this issue?

The only way to prevent the NSA or any other overeaching government agency or corporation from getting teir hands on the data is for an Anonymous client to be established, that way the NSA won't know who to go after.

Mailpile already did it?

[Anonymous Coward]

How is this different than what Mailpile is trying to do?

Crimonelly!

[ThatsNotPudding]

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.

Congrats: your sentence is thoroughly encrypted!

PGP WoT _does_ scale

[Anonymous Coward]

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

You are mistaken. PGP has more is better thing going on. It does scale (more participants = stronger), and that's why governments don't want you to use it.

Do the math on the probabilities.

And if someone encourages you to move away from looking at probabilities? Good: you've just spotted the fed.

need partners

[Tom]

It's a good concept, but it is based in the US, which means that a) it'll run into the same issues again and b) nobody outside and few inside the US will trust it.

What they need are partners in other jurisdictions. At least one in Europe and one in Asia. A carefully designed corporate structure can delay any legal attacks for long enough for at least one of the nodes to inform its users and shift them towards a node not under attack.

Why do we geeks always think the solution must be technical? Social and legal protocols are equally important, and can solve many problems that are much more difficult to solve by technology.

Take a page out of the book of megacorporations. Set up a mother company in a country with all the laws you need and make the operation the legal property of that, so that you can deflect any legal attacks by claiming your local subsidary doesn't have the legal authority nor the passwords required to do what you want them to do, but you will be happy to forward it to the mother company - which is in a jurisdiction where the gag order doesn't apply.

Get a lawyer on board who can figure these things out. There are plenty of lawyers interested in this kind of stuff. And if you need contacts in Europe, send me a mail. I kind of miss the good feeling I had back when I was running an anonymous remailer.

Lavabit Prosecuted?

[Anonymous Coward]

Are they doing this to avoid being prosecuted by the US government?

hmm okay they just reinvented the wheel

[BigLonn]

Someone check me on this, this sounds just like gpg/pgp that is available already and holds the keys in the same place. Did I miss something here, comments: