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

← Back to Stories (view on slashdot.org)

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

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

angry tapir writes "Two privacy-focused email providers have launched the Dark Mail Alliance, a project to engineer an email system with robust defenses against spying. Silent Circle and Lavabit abruptly halted their encrypted email services in August, saying they could no longer guarantee email would remain private after court actions against Lavabit, reportedly an email provider for NSA leaker Edward Snowden."

136 of 195 comments (clear)

Min score:

Reason:

Sort:

Right now ... by Anonymous Coward · 2013-10-31 01:04 · Score: 1

The /. Page says, "There are no comments." Well, duh, they're encrypted so the browser doesn't recognize them.
1. Re:Right now ... by Cryacin · 2013-10-31 01:32 · Score: 1
  
  So secure, you can start emailing passwords again.
  
  --
  Science advances one funeral at a time- Max Planck
2. Re:Right now ... by Runaway1956 · 2013-10-31 03:38 · Score: 1
  
  Well, the NSA has already cracked it. I can see your posts now . . . .
  
  --
  "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Did the NSA just kill SMTP? by Defenestrar · 2013-10-31 01:06 · Score: 5, Interesting

It's been around for what, 40 years? Working, (relatively) anonymous, and totally insecure mail transfer with tons of inertia. Never thought I'd see the day where there might be a small sliver of opportunity for another protocol to actually happen. Ars has a nice article about it too.
1. Re:Did the NSA just kill SMTP? by Anonymous Coward · 2013-10-31 01:23 · Score: 1
  
  Just posting anonymously (as to not undo mods) to say, I wish there was a +1 Hopefully mod.
2. Re:Did the NSA just kill SMTP? by Vanderhoth · 2013-10-31 01:53 · Score: 5, Insightful
  
  There is the added advantage that if everything is encrypted, and snoopers had to decrypt everything to find something of value, it would be a serious drain on their resources. On the flip side, if everything, except that which absolutely required encryption, was sent in and easily accessible format then encrypted messages are a big red flag that says "Look at me I'm important!!", which allows snoopers to be selective about where they spend their resources. But that's just my take on it.
3. Re:Did the NSA just kill SMTP? by wmac1 · 2013-10-31 01:55 · Score: 1
  
  I wish they would also do something fundamental about spam problem. But that would possibly means unique id for senders which would ruin anonymity.
4. Re:Did the NSA just kill SMTP? by jones_supa · 2013-10-31 02:12 · Score: 4, Informative
  
  No. SMTP was never meant to be secure and was never advertised to be secure. It's "secure enough" for casual and most business emails. I'd venture a guess that 99.999% (and that may even be low) of email sent would have zero benefit of being encrypted because no one cares what the content is.
  It'd be like encrypting every conversation at a football game. Yeah all the conversations would be private, but aside from the two parties talking, no one cares.
  Many protocols used over Internet were not designed with encryption because it didn't seem that important at the time. Internet was built with the intention that everyone plays nice and the networks are trusted. With NSA, times have changed, as they can set up a MiTM attack anywhere and the wire cannot be trusted anymore. It's not that they would only get a criminal warrant for the ISP to reveal your mailbox contents, but instead they are actively snooping in random places where they shouldn't be.
5. Re:Did the NSA just kill SMTP? by mlts · 2013-10-31 02:12 · Score: 1
  
  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.
6. Re:Did the NSA just kill SMTP? by mlts · 2013-10-31 02:40 · Score: 3, Interesting
  
  What might be a decent replacement for SMTP, but for small messages only (under 1-5 megs) would be a NNTP-like structure.
  User "A" at site foo.com wants to send a message to user "B" at bar.com. The message is encrypted with OpenPGP to b@bar.com. Then, the server at foo.com drops it into a store and forward pool similar to a newsgroup. bar.com eventually receives the latest messages, notices a message addressed to one of its users, copies it out of the "newsgroup", and into the user's mailbox.
  Of course, a blinding factor can be attached so no other machines with the NNTP-like pool can tell that the message is addressed to someone at bar.com, they can tell it is injected from foo.com and expires in a few hours, but that is that.
  Of course, the disadvantage is that a whole lot of irrelevant info goes between company servers. The advantage is that communications are protected, as one might see a server drop a message into the stream, but there is no way to detect a server fishing one out.
7. Re:Did the NSA just kill SMTP? by Gerzel · 2013-10-31 02:50 · Score: 1
  
  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.
8. Re:Did the NSA just kill SMTP? by jbolden · 2013-10-31 03:14 · Score: 1
  
  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.
9. Re:Did the NSA just kill SMTP? by V+for+Vendetta · 2013-10-31 03:15 · Score: 3, Informative
  
  They want to build it upon XMPP, according to the Ars article I read earlier this day.
10. Re:Did the NSA just kill SMTP? by UnderCoverPenguin · 2013-10-31 03:43 · Score: 4, Informative
  
  Many protocols used over Internet were not designed with encryption because it didn't seem that important at the time.
  
  Contrary to popular belief, "designing in security" does not mean every protocol has encryption built-in. It does mean that when designing an implementation of a protocol, security is properly factored in. And, in a system, that encryption is used in the appropriate places.
  Most protocols on the Internet are application level protocols. Some applications would benefit from application level encryption because this reduces (not eliminates) risk of exposing unencrypted data. For most applications it's more efficient to implement a common encryption service then have the applications use that. That also has the advantage of enabling including encrypting the (final) endpoint identification (and other application identification) by implementing the encryption between the Transport and Network layers. Applications with their own encryption would also benefit from this.
  Even with application level encryption, many (maybe most) of the existing protocols are useful. Example: A subset of SMTP could be used in delivering email. The email client application would establish a secure connection to the destination email server then send the actual message(s) using SMTP. Both the client-server connection and the messages would be encrypted. The server needs some meta data to deliver the messages to the mailboxes, but the meta data would otherwise be encrypted on-the-net. The messages would be decrypted by the email client to display to the user. (Even if you used direct IM, the Transport layer meta data would still exist, so you only get a little extra protection from direct IM - but IM is only possible when both parties are online.)
  There is also value in implementing encryption just below the Network layer as this will encrypt the routing information as well. Still end-to-end at either the Transport layer or in the application (or, both) is vitally important.
  (For those not familiar, the Network layer is responsible for moving data packets around the network, ultimately delivering data to the destination host. The Transport layer is responsible for end-to-end communications and represents the host. The host is the collection of applications running in a machine (physical or virtual) that use the Transport layer to communicate with applications running in other hosts. The "final" endpoint is what TCP, UDP and several other transport protocols call the "port" (example: port 80 for HTTP/HTTPS servers))
  
  --
  Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
11. Re:Did the NSA just kill SMTP? by Nerdfest · 2013-10-31 04:03 · Score: 1
  
  That's what Apple did with iMessage. Extending XMPP doesn't mean it needs to be open.
12. Re:Did the NSA just kill SMTP? by Tokolosh · 2013-10-31 04:49 · Score: 1
  
  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.
  
  --
  Prove anything by multiplying Huge Number times Tiny Number
13. Re:Did the NSA just kill SMTP? by dpilot · 2013-10-31 05:24 · Score: 1
  
  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.
  
  --
  The living have better things to do than to continue hating the dead.
14. Re:Did the NSA just kill SMTP? by dpilot · 2013-10-31 05:39 · Score: 3, Interesting
  
  RTFA - their intent is to make an Open Source solution. Given that these people shut down their businesses rather than compromise their principles, I'd find it hard to believe they were about to release patent-encumbered source code on the world.
  
  --
  The living have better things to do than to continue hating the dead.
15. Re:Did the NSA just kill SMTP? by Sabriel · 2013-10-31 14:40 · Score: 1
  
  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.
16. Re:Did the NSA just kill SMTP? by Anonymous Coward · 2013-10-31 15:16 · Score: 1
  
  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.
17. Re: Did the NSA just kill SMTP? by Sigg3.net · 2013-10-31 23:49 · Score: 1
  
  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.
  
  --
  Defining Statistics and Social Research
18. Re:Did the NSA just kill SMTP? by BiggoronSword · 2013-11-01 03:24 · Score: 1
  
  Since we're talking about XMPP, can I suggest Google Wave be brought to the table again?
  
  --
  interactive hologram, or it didn't happen.
Called it by slashmydots · 2013-10-31 01:09 · Score: 1, Informative

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.
1. Re:Called it by Anonymous Coward · 2013-10-31 01:19 · Score: 1
  
  Congrats, you could see the same thing everyone else could. You are quite the Nostradamus.
2. Re:Called it by Alain+Williams · 2013-10-31 01:51 · Score: 5, Insightful
  
  Registrant Country:US
  I'd just feel a bit happier if the new effort was based somewhere other than the USA; somewhere a bit harder for the NSA to get its sticky paws into. I have in mind how the NSA screwed with IPSec. Mind you: discussion would have to be international, I am not sure how much harder it would make things for them if this was based in, say, Bolivia.
3. Re:Called it by Alain+Williams · 2013-10-31 01:54 · Score: 1
  
  Before I get flamed: the above was not intended as a slur against the guys at Lavabit and Silent Circle.
4. Re:Called it by slashmydots · 2013-10-31 02:10 · Score: 5, Funny
  
  I knew you were going to post that.
5. Re:Called it by BitZtream · 2013-10-31 03:02 · Score: 2
  
  IPSec was an international effort ...
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
6. Re:Called it by ArbitraryName · 2013-10-31 03:53 · Score: 1
  
  The Turks & Caicos are British.
7. Re:Called it by fnj · 2013-10-31 05:10 · Score: 1
  
  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.
Another mail protocol by gmuslera · 2013-10-31 01:12 · Score: 4, Interesting

This one with security/encryption built in from the ground up this time. Would be more interesting that instead of the comments of Microsoft (with deep ties with the NSA), yahoo and google (both may not be very happy with the NSA, but still must give them their users accounts info by law) the article focused on comments from people from i.e. the IETF for implementing it as an standard in a more worldwide (even personal) way.
1. Re:Another mail protocol by auric_dude · 2013-10-31 01:29 · Score: 1
  
  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.
2. Re:Another mail protocol by gmuslera · 2013-10-31 02:36 · Score: 1
  
  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.
3. Re:Another mail protocol by BitZtream · 2013-10-31 03:04 · Score: 1
  
  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.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
4. Re:Another mail protocol by fnj · 2013-10-31 05:41 · Score: 1
  
  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.
5. Re:Another mail protocol by HiThere · 2013-10-31 06:49 · Score: 1
  
  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).
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
6. Re:Another mail protocol by gmuslera · 2013-10-31 08:15 · Score: 1
  
  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.
Bitcoin by Anonymous Coward · 2013-10-31 01:16 · Score: 1

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 by Anonymous Coward · 2013-10-31 01:17 · Score: 5, Insightful

The whole paradigm of certificate trust, and the fact that you just have to trust Root CAs, is a farcical model of security.
We should all be aware by now that the Root CAs we all know and trust are compromised by NSA and that they can MITM any SSL connection they want at any time.
Until we can move beyond this whole third party certificate trust issue, there will never, EVER be truly secure email.
1. Re:Dump SSL / Certificate-based Security by Anonymous Coward · 2013-10-31 01:28 · Score: 1
  
  We already did. Use PGP.
2. Re:Dump SSL / Certificate-based Security by CimmerianX · 2013-10-31 01:29 · Score: 4, Insightful
  
  Problem with PGP/GPG is that the tech concept is beyond many end users. If a solution is not easily adopted by the noobish masses, it will never gain a foothold.
3. Re:Dump SSL / Certificate-based Security by grub · 2013-10-31 01:34 · Score: 3, Informative
  
  PGP/GPG is boneheaded easy to use these days. Generate a keypair, uploaded to the keyservers automatically, install mail plug in.
  From there it's virtually automatic.
  
  --
  Trolling is a art,
4. Re:Dump SSL / Certificate-based Security by landoltjp · 2013-10-31 01:43 · Score: 3, Insightful
  
  Is it fair to say that another shortcoming of PGP/GPG is that it encrypts the message body only, leaving the envelope in the clear?
  If this is indeed the case then we're right back to the metadata situation where the [who | when | where] I communicate it known, but not necessarily the _what_ (I'm sure the NSA will make up their own justification for _why_ I'm communicating).
5. Re:Dump SSL / Certificate-based Security by silas_moeckel · 2013-10-31 01:45 · Score: 2, Insightful
  
  As soon as you trust key servers you have the same issue as the root CA's they can be manipulated.
  PGP/GPG potentially works rather well, it's weakness is having to move around and validate public keys. The secondary issue is halving to store them on a PC. An opensource smartcard device would seem to deal with the second part. But centralized key stores just beg to be abused.
  
  --
  No sir I dont like it.
6. Re:Dump SSL / Certificate-based Security by SirGarlon · 2013-10-31 01:47 · Score: 2
  
  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.
  
  --
  [Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
7. Re:Dump SSL / Certificate-based Security by davecb · 2013-10-31 01:49 · Score: 3, Informative
  
  PGP's author is somewhat aware of that (;-)) He's a principal at Silent Circle
  
  --
  davecb@spamcop.net
8. Re:Dump SSL / Certificate-based Security by ZaphDingbat · 2013-10-31 01:56 · Score: 1
  
  Unless companies who want their corporate information to remain secret adopt it first and force some progress.
9. Re:Dump SSL / Certificate-based Security by DrXym · 2013-10-31 02:04 · Score: 2
  
  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.
10. Re:Dump SSL / Certificate-based Security by mlts · 2013-10-31 02:04 · Score: 3, Informative
  
  PGP/gpg's weakness is noticeable, but in this case, the perfect is the enemy of the good, and a WoT is the security solution that sucks the least.
  Yes, it takes some time to get keys signed, but the advantage of a WoT over SSL is that you can take a couple people whom you never met, but whom your friends trusted, add up their semi-trust, and be pretty sure that an unknown key is genuine.
11. Re:Dump SSL / Certificate-based Security by BorelHendrake · 2013-10-31 02:05 · Score: 1
  
  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.
12. Re:Dump SSL / Certificate-based Security by mlts · 2013-10-31 02:20 · Score: 2
  
  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.
13. Re:Dump SSL / Certificate-based Security by mlts · 2013-10-31 02:23 · Score: 2
  
  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.
14. Re:Dump SSL / Certificate-based Security by heypete · 2013-10-31 02:25 · Score: 1
  
  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.
15. Re:Dump SSL / Certificate-based Security by CreatureComfort · 2013-10-31 02:31 · Score: 4, Insightful
  
  Bonehead easier would be better.
  
  1. Generate key pairs behind the scenes. There is no value added to my (any user) choosing to manually generate a key pair and manage it. The software should be perfectly capable of generating my personal key pair(s).
  2. EVERY email sent should have the sender's public key in the Header, placed there automatically by the email client. No reason any typical user should ever have to see the key block. Public key blocks at the end of your signature are just geek peen waving.
  3. Email clients should be able to invisibly read the public key in the header, and add that to the local managed keyring, with no user intervention.
  4. Email clients should automatically encrypt emails sent to an address for which it has a public key in the keyring, and automatically decrypt incoming messages.
  5. If an email is being sent to an address with no key in the ring, then an initial email should automatically be generated sending a request for that address' public key (of course the sender's public key would be in the sent header). A specially formatted subject line or header value could be implemented so the the receiving email client would automatically respond with the public key, encrypted by the key it received in the header, and the request email need never even show up in the user's inbox. The body of the request message could simply be a request for the receiving user to implement a compliant email client, since the recipient would only see it if they were using a non-compliant client.
  6. Upon receiving the response email, the original sender's client could compare the encrypted key it receives against the public key in the header, add the public key for that address to the key ring, and then send the email (encrypted) that the original user wanted to send.
  
  The initial exchange of keys could happen very quickly and entirely automated in the background, so the users never even need to realize it is happening.
  
  Implement these six steps in every email client, and the problem would be mostly solved. Of course, there is the rub. Anything that isn't put seamlessly into Outlook, Gmail, iOS Mail, Yahoo, etc. will never get enough widespread use to be anything but blazing sign that this person has something they want to hide, and are willing to annoy all of their email contacts enough to keep sending requests for public keys. with every message.
  
  --
  "Unheard of means only it's undreamed of yet,
  Impossible means not yet done." ~~ Julia Ecklar
16. Re:Dump SSL / Certificate-based Security by heypete · 2013-10-31 02:31 · Score: 3, Informative
  
  StartSSL offers free-of-charge domain-validated certificates that are widely trusted. Other CAs like GoDaddy and Comodo offer (often through resellers) domain-validated certs that cost less than $20/year. Thawte DV certs from resellers cost about $30/year. The cost (or lack thereof) for such certs is probably the least important reason why people aren't using HTTPS more.
  EV certs are well within the budget for even small businesses, and usually cost around $150/year. Again, hardly unreasonable.
  It'd be nice to see more hosting companies implement Server Name Indication (SNI) so that clients can implement SSL/TLS without needing to waste a dedicated IP address. This really should be the default.
17. Re:Dump SSL / Certificate-based Security by silas_moeckel · 2013-10-31 02:57 · Score: 1
  
  You can go even further with requiring the user to approve the key signing even potentially displaying info about whats its doing.
  
  --
  No sir I dont like it.
18. Re:Dump SSL / Certificate-based Security by mlts · 2013-10-31 02:57 · Score: 1
  
  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.
19. Re:Dump SSL / Certificate-based Security by silas_moeckel · 2013-10-31 03:00 · Score: 1
  
  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.
  
  --
  No sir I dont like it.
20. Re:Dump SSL / Certificate-based Security by Bob9113 · 2013-10-31 03:05 · Score: 2
  
  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.
  
  --
  Stop-Prism.org: Opt Out of Surveillance
21. Re:Dump SSL / Certificate-based Security by BitZtream · 2013-10-31 03:05 · Score: 1
  
  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
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
22. Re:Dump SSL / Certificate-based Security by BitZtream · 2013-10-31 03:07 · Score: 1
  
  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.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
23. Re:Dump SSL / Certificate-based Security by BitZtream · 2013-10-31 03:08 · Score: 1
  
  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.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
24. Re:Dump SSL / Certificate-based Security by silas_moeckel · 2013-10-31 03:13 · Score: 1
  
  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.
  
  --
  No sir I dont like it.
25. Re:Dump SSL / Certificate-based Security by jbolden · 2013-10-31 03:18 · Score: 3, Insightful
  
  The problem with PGP is it makes the end user responsible for key management. End users don't understand encryption. Their needs to be a key management services around PGP to make it viable for mass usage.
26. Re:Dump SSL / Certificate-based Security by jbolden · 2013-10-31 03:18 · Score: 1
  
  Replay you scenario and assume that there was a man in the middle attack.
27. Re:Dump SSL / Certificate-based Security by jbolden · 2013-10-31 03:20 · Score: 1
  
  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?
28. Re:Dump SSL / Certificate-based Security by jbolden · 2013-10-31 03:21 · Score: 2
  
  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.
29. Re:Dump SSL / Certificate-based Security by UnderCoverPenguin · 2013-10-31 04:00 · Score: 1
  
  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.
  
  --
  Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
30. Re:Dump SSL / Certificate-based Security by DuckDodgers · 2013-10-31 04:03 · Score: 1
  
  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.
31. Re:Dump SSL / Certificate-based Security by Cajun+Hell · 2013-10-31 04:05 · Score: 1
  
  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.
  
  --
  "Believe me!" -- Donald Trump
32. Re:Dump SSL / Certificate-based Security by DrXym · 2013-10-31 04:12 · Score: 1
  
  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.
33. Re:Dump SSL / Certificate-based Security by DuckDodgers · 2013-10-31 04:14 · Score: 1
  
  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!
34. Re:Dump SSL / Certificate-based Security by AmiMoJo · 2013-10-31 04:16 · Score: 1
  
  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...)
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
35. Re:Dump SSL / Certificate-based Security by DrXym · 2013-10-31 04:18 · Score: 1
  
  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.
36. Re:Dump SSL / Certificate-based Security by Nerdfest · 2013-10-31 04:18 · Score: 1
  
  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.
37. Re:Dump SSL / Certificate-based Security by BorelHendrake · 2013-10-31 04:20 · Score: 1
  
  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.
38. Re:Dump SSL / Certificate-based Security by AmiMoJo · 2013-10-31 04:20 · Score: 1
  
  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).
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
39. Re:Dump SSL / Certificate-based Security by DuckDodgers · 2013-10-31 04:22 · Score: 1
  
  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.
40. Re:Dump SSL / Certificate-based Security by jbolden · 2013-10-31 04:31 · Score: 1
  
  You request the public key from the email address, the MiTM responds with his key...
41. Re:Dump SSL / Certificate-based Security by BradMajors · 2013-10-31 04:35 · Score: 1
  
  Thunderbird provides no way to search PGP emails. Until this long requested featured is added, PGP is not usable when using a Thunderbird client.
42. Re:Dump SSL / Certificate-based Security by jbolden · 2013-10-31 04:36 · Score: 1
  
  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.
43. Re:Dump SSL / Certificate-based Security by BradMajors · 2013-10-31 04:40 · Score: 1
  
  The solution is to send the email directly from the sender's PC to the receiver's PC without going through any mail servers.
44. Re:Dump SSL / Certificate-based Security by Kjella · 2013-10-31 04:41 · Score: 1
  
  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.
  
  --
  Live today, because you never know what tomorrow brings
45. Re:Dump SSL / Certificate-based Security by BorelHendrake · 2013-10-31 04:59 · Score: 1
  
  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.
46. Re:Dump SSL / Certificate-based Security by eth1 · 2013-10-31 05:08 · Score: 1
  
  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.
47. Re:Dump SSL / Certificate-based Security by jbolden · 2013-10-31 05:12 · Score: 1
  
  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.
48. Re:Dump SSL / Certificate-based Security by silas_moeckel · 2013-10-31 05:24 · Score: 1
  
  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.
  
  --
  No sir I dont like it.
49. Re:Dump SSL / Certificate-based Security by mlts · 2013-10-31 05:26 · Score: 1
  
  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.
50. Re:Dump SSL / Certificate-based Security by jbolden · 2013-10-31 05:33 · Score: 1
  
  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.
51. Re:Dump SSL / Certificate-based Security by silas_moeckel · 2013-10-31 05:44 · Score: 1
  
  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.
  
  --
  No sir I dont like it.
52. Re:Dump SSL / Certificate-based Security by Agent0013 · 2013-10-31 05:54 · Score: 1
  
  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.
  
  --
  
  -- ssoorrrryy,, dduupplleexx sswwiittcchh oonn.. -Quote found on actual fortune cookie.
53. Re:Dump SSL / Certificate-based Security by heypete · 2013-10-31 07:06 · Score: 1
  
  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).
54. Re:Dump SSL / Certificate-based Security by DuckDodgers · 2013-10-31 07:07 · Score: 1
  
  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.
55. Re:Dump SSL / Certificate-based Security by hodet · 2013-10-31 07:08 · Score: 2
  
  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.
56. Re:Dump SSL / Certificate-based Security by jbolden · 2013-10-31 07:30 · Score: 1
  
  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.
57. Re:Dump SSL / Certificate-based Security by Common+Joe · 2013-10-31 07:54 · Score: 1
  
  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.
58. Re:Dump SSL / Certificate-based Security by david_thornley · 2013-10-31 08:22 · Score: 1
  
  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.
  
  --
  "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
59. Re:Dump SSL / Certificate-based Security by Cajun+Hell · 2013-10-31 10:38 · Score: 2
  
  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.
  
  --
  "Believe me!" -- Donald Trump
60. Re:Dump SSL / Certificate-based Security by Cajun+Hell · 2013-10-31 11:03 · Score: 1
  
  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.
  
  --
  "Believe me!" -- Donald Trump
61. Re:Dump SSL / Certificate-based Security by Cajun+Hell · 2013-10-31 11:15 · Score: 1
  
  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.
  
  --
  "Believe me!" -- Donald Trump
62. Re:Dump SSL / Certificate-based Security by mlts · 2013-10-31 12:41 · Score: 1
  
  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.
63. Re:Dump SSL / Certificate-based Security by silas_moeckel · 2013-10-31 13:27 · Score: 1
  
  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.
  
  --
  No sir I dont like it.
64. Re:Dump SSL / Certificate-based Security by Cajun+Hell · 2013-11-01 03:58 · Score: 1
  
  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.
  
  --
  "Believe me!" -- Donald Trump
65. Re:Dump SSL / Certificate-based Security by DuckDodgers · 2013-11-04 08:42 · Score: 1
  
  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.
66. Re:Dump SSL / Certificate-based Security by jbolden · 2013-11-04 14:42 · Score: 1
  
  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 by lxs · 2013-10-31 01:21 · Score: 2

It's a good thing that they already have a theme song.
Metadata by Meneth · 2013-10-31 01:22 · Score: 1

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 by Jakosa · 2013-10-31 01:31 · Score: 5, Interesting

When I first saw the Snowden-film from Hong Kong I thought: "damn! he has forfeited his life and nobody will care. And now this! Not only has he shaken the political world-society, he has also aroused the tech-world and made it possible to make some major changes. Hope I will be running this new protocol by next year and be able to send super-secret Christmas-cards to the select few who is also using it!
1. Re:Thanks Snowden by cffrost · 2013-10-31 11:08 · Score: 2
  
  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).
  
  --
  Thank you, Edward Snowden.
  
  "Arguments from authority are worthless." —Carl Sagan
2. Re:Thanks Snowden by RivenAleem · 2013-10-31 20:35 · Score: 1
  
  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? by Havokmon · 2013-10-31 01:42 · Score: 1

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.

--
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
right from the white paper by imatter · 2013-10-31 01:45 · Score: 5, Insightful
SCIMP provides strong encryption, perfect forward secrecy and message authentication.Further, we have incorporated many NIST-approved methods and protocols into its design including:
- Elliptic Curve Diffie–Hellman (ECDH), NIST 800-56A
- Counter with CBC-MAC (CCM), NIST 800-38C
- Key Derivation, NIST 800-108
- Secure Hash Standard, FIPS 180-4
- Advanced Encryption Standard (AES), FIPS 197
Does anyone else see a problem with with the wording "NIST-approved methods and protocols?" NIST/NSA
1. Re:right from the white paper by inject_hotmail.com · 2013-10-31 02:50 · Score: 2
  
  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.
2. Re:right from the white paper by imatter · 2013-10-31 03:01 · Score: 1
  
  agreed!
3. Re:right from the white paper by onyxruby · 2013-10-31 03:27 · Score: 1
  
  Remember that NIST standards and protocols are typically the same one the US requires for it's own use. What your proposing is either that the US would use known bad protocols for it's own use or would be making an epic scale security through obscurity blunder. You can't have a back door that only works for you, if it's in there any given foreign agency could discover it and use it. That simply doesn't pass the sniff test or Occam's razor.
  What does concern me with the proposed standard is that they want to use certificates signed by a third party. You can't do that without having a dependency on someone that can be forced by a court order to work against you. This isn't a US specific issue either as other countries can and do use court orders to compel certificate authorities to cooperate.
  Remember the only thing trust does with SSL and a certificate is verify a chain of identify. When your chain of identity is subject to a MITM attack or a warrant you have a standard that is for all intents and purposes next to worthless.
Maybe they should change the name by Jakosa · 2013-10-31 01:47 · Score: 2

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?
1. Re:Maybe they should change the name by c0d3g33k · 2013-10-31 04:16 · Score: 3, Informative
  
  Why call it Dark-Mail?
  Because it was better than the first name the came up with. From TechDirt:
  
  Levison joked that they went with "Dark Mail" because "Black Mail" might have negative connotations.
  http://www.techdirt.com/articles/20131030/11091025070/dark-mail-alliance-lavabit-silent-circle-team-up-to-try-to-create-surveillance-proof-email.shtml
Lovely - now, if they'd only tackle spam ... by eer · 2013-10-31 01:59 · Score: 2

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:What problem are they solving? by jotaeleemeese · 2013-10-31 02:18 · Score: 1

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

--
IANAL but write like a drunk one.
Why DarkMail? by jotaeleemeese · 2013-10-31 02:31 · Score: 4, Insightful

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

--
IANAL but write like a drunk one.
1. Re:Why DarkMail? by Teckla · 2013-10-31 05:13 · Score: 1
  
  Maybe the DarkMail folks will create some cool icons, mascots, advertisements, etc. and label them all "Made in the GIMP."
2. Re:Why DarkMail? by Anonymous Coward · 2013-10-31 05:32 · Score: 1
  
  "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.
3. Re:Why DarkMail? by Monoman · 2013-10-31 06:27 · Score: 1
  
  You are spot on. However, are we really surprised that folks who previously used names like Lavabit & SilentCircle understand marketing?
  
  --
  Keep the Classic Slashdot.
4. Re:Why DarkMail? by G00F · 2013-10-31 06:49 · Score: 2
  
  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.
  
  --
  The spirit of resistance to government is so valuable on certain occasions that I wish it to be always kept alive
Passing Keys by XLT_Frank · 2013-10-31 02:34 · Score: 1

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:What problem are they solving? by mlts · 2013-10-31 02:35 · Score: 1

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? by wiredlogic · 2013-10-31 02:49 · Score: 1

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.

--
I am becoming gerund, destroyer of verbs.
I read the documents. by jotaeleemeese · 2013-10-31 02:54 · Score: 2

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

--
IANAL but write like a drunk one.
Re:What problem are they solving? by tlhIngan · 2013-10-31 03:09 · Score: 1

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.
It already exits and is free by shellster_dude · 2013-10-31 04:03 · Score: 3, Interesting

Bitmessage: P2P, encrypted, anonymous. The project is pretty new, but other than a couple scalability issues, I think this project has major potential. http://bitmessage.org/
MitM is a tolerable default by Cajun+Hell · 2013-10-31 04:14 · Score: 1

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?

--
"Believe me!" -- Donald Trump
1. Re:MitM is a tolerable default by jbolden · 2013-10-31 04:32 · Score: 1
  
  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.
2. Re:MitM is a tolerable default by Rich0 · 2013-11-01 07:37 · Score: 1
  
  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.
Crimonelly! by ThatsNotPudding · 2013-10-31 05:13 · Score: 2

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!
need partners by Tom · 2013-10-31 06:33 · Score: 1

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.

--
Assorted stuff I do sometimes: Lemuria.org
hmm okay they just reinvented the wheel by BigLonn · 2013-11-01 08:12 · Score: 1

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: