Personally, I think, the user is best served with the "darknet"  approach.
It's unfortunate that term "darknet" leads a big chunk of the general public to believe it's something "dirty", "illegal" or otherwise undesirable or even dangerous, which doesn't help its cause. So help the Internet out and spread the word:
RetroShare  is one of them and has the advantage of being the all-in-one encryption solution (VOIP, chat, messages, file sharing), while encrypting everything. It also eliminates the meta data problem which encrypted email has.
EDIT: Direct link - http://retroshare.sourceforge.net/
I'd just like to add to that:
Very serious attacks on democratic principles have been carried out behind our backs, for a very long time, apparently.
That is why I think, in order to counter these threats to society appropriately, disruptive approaches should really be welcomed and preferred as often as possible.
And then, of course, it's not an either/or question. Both should be promoted alongside, as lots of different people have lots of different needs/requirements.
(Personally, I use both RetroShare and encrypted email, and migrate as many people as possible over to total encryption as soon as possible.)
Remember, even with lofty "serious attacks on democratic principles" going on, you're still infinity times more likely to have your bank account information stolen by drive-by script kiddies with a 0-day than be a target of government persecution on the back of illicitly obtained intelligence. Even then, it's highly unlikely that even the NSA has the capacity to decrypt internet traffic at scale.
It's just that we should all do our best in order to erect the collective hurdle that the mass surveillance efforts now require. There's nothing lofty about democracy being attacked, it's very real. And don't forget that you can't really do encryption on your own, you depend on all your contacts doing it, too. Society needs to make that as normal as brushing their teeth.
To be clear: encryption _needs_ to be perfect. But "let's fork the web" is a pipe dream, "let's start encrypting emails" is quite achievable.
It would be far cleaner if it was more self-contained (e.g., included GPG inside its installation bundle), and then let the user pick an alternative OpenPGP installation in the preferences.
GPGTools guys — if you're reading this thread, please please stop installing stuff outside your plugin's bundles.
brew link gpg2 --overwrite
PS: If you are a maintainer, thank you for all the hard work. I'm only criticizing the current installation system because I really want to use GPGMail, and it does not fit into the way I like to set up my machine.
* GPG2 seems to be up and running very nicely, and it was an easy switch to get Enigmail set up to recognize it. (My previous MacGPG installation evidently installed GPG1. That seems to be orphaned now, I guess? Any suggestions for an ideal way to clean out its old stuff? I haven't seen it mentioned on your site.)
* This is the first GPG distribution that I can remember using that didn't provide hashes and a detached signature to verify the integrity of the downloaded file.
* It looks like the provided man pages were not symlinked into /usr/local/share/man/man1 (to match the way that the binaries were symlinked into /usr/local/bin).
* For reasons I've yet to track down, the GPGPreferences preference pane hangs whenever I try to open it. (I'll file a bug and/or ask for help on your forums eventually; just mentioning it here as part of the experience.)
Until the tools take 5 min to setup, and encryption/decryption is automatically handled by the mail client, PGP will never take off. Things like the public key directory have to handled transparently to the user.
It's too bad Mozilla dropped support for Thunderbird. Tight integration with GnuPG plugin could have made mainstream PGP a reality. For OS X at least, it looks like GPGMail is nearly there.
Key management is tricky because if you have a truly secure pass-phrase (that is, one that contains >= 128 bits "worth" of entropy (or even >= 65 bits which might be enough), a pass-phrase that can be considered at least as secure as the symmetric session keys) -- then that is going to be awkward to type in (and remember). And if you don't -- then you need to be (extra) careful about where you store your secret key ring, where it is backed up, etc (you should be careful about this anyway).
And it is still tricky to carefully manage which keys you trust, and bootstrapping trust is hard. The latter can be alleviated somewhat by having a few "designated CAs" in a company -- eg: have the IT department set up GPG, and make sure that they verify and sign people's keys along with setting up accounts etc.
Actually, we're close to that. I have had trouble figuring out how to smoothly encrypt attachments though. (I'm sure it can be done though.)
Five minutes to set up? Yeah pretty much.
Encryption/decryption of emails is handled automatically in enigmail after the first encrypted email is sent. You can set it up so that for certain users it sends them an encrypted message by default. (Though the interface for this is a little confusing, it could use some polish.)
It helps you import a key if a fingerprint is included or a public key attached to the email.
I was actually pretty impressed with what I didn't have to do. It still needs some improvement though.
I identified a couple of usability issues, which where fixed. I'd say all in all its very good.
Regardless if you believe or care about the NSA issues, simply the idea of routing clear text email through mail exchanges, and advertisers should give you enough reason to follow the few steps it requires to generate a key, and start encrypting and/or signing email. Except for post cards we don't do this with our regular mail, so why are you ok with it with you email (and your email is far more machine readable).
GPGMail is not quite Grandmother ready, and unlike s/mime it doesn't really have an incremental value, but it is far more secure, and very easy to use once setup. Plus the other tools in the toolkit are useful for general encryption.
s/mime is another option, here are some pros and cons:
integrated with many mail apps
usually plays nice with mailing lists (adding a footer doesn't invalidate a sig)
works on iOS devices (perhaps others?)
has an incremental value even before all your contacts are using it
based on a certificate authority model
cost money depending on the cert you get
requires a 3rd 'trusted' party
does not seem to be secure in some respects:
(web cert generation, no rules regarding sigh/encrypt/sign,
does not make use of a certificate request so anyone who has
even momentary access to your email can generate a cert to
masquerade as you)
your identity is associate with your email address not you
(you will need certs for each email address)
Based on web of trust instead of CA (web of trust is not required)
You can revoke your key if it is compromised
Based on you not your email, so you can use the same sig with any email address
You can even associate your picture with your key
Use the same keys for non email encryption
Less widely integrated.
Does not work on devices yet.
May break email lists (adding footers may change the sig, I haven't tested though)
Can't help much until your have other people to use it with.
 See the answer by Adam Liss (not the accepted answer) for the security issues http://stackoverflow.com/questions/13512026/how-to-check-if-...
Hopefully somebody makes a good go at getting PGP onto Firefox OS so I can ditch Android.
Provided that they trust the people handing out these certificates – with PGP, they need a chain of trust to your key to verify that it is you, with S/MIME, they have to trust random third parties. Or do I miss something and you mean something else that is possible with S/MIME but not PGP?
This is because just like her browser the CA is trusted by her OS.
For easy steps on how to do this see here:
You can get a free cert from COMODO:
If you don't trust the CA system, well then the web is a very scary place for you because it's all built on that and email is probably the least of your concerns.
The CAs are generally not "a random list", but rather a publicly accepted and accredited CA. Just like your https cert.
My little company is working on an encrypted email solution that is--http://parley.co will be entering pre-beta next week :)
<form action="http://parley.us6.list-manage.com/subscribe/post?u=NN&id=NN" method="post"
It's unfortunate, because anything based on shared secretes (directly) makes key revocation tricky.
S/MIME is also built in to (almost) every thick MUA. it works on iOS out of the box, it works in outlook, thunderbird, mail.app and mutt out of the box.
once you generate a S/MIME cert through a big provider, none of the other big providers will give you an e-mail cert for the email issued by the other big provider (probably, still trusting them to do the right thing).
Enigmail for Thunderbird: http://www.enigmail.net/home/index.php
GPG4Win provide plugins for Outlook:
Evolution on Linux has OpenPGP support built in.
FYI: Another term used for OpenPGP is gnupg or GPG, should you want to google for other solutions on other operating systems.
But to be clear, this is just an interface to the MacGPG backend, so it's not some proprietary format. Your friends, etc. don't need to use GPGMail in particular; any PGP implementation will be fine.
With asymmetricity, the public key is a key which can only encrypt the message, but even the sender cannot decrypt that same message again with that key. Only the single unshared private key can decrypt them.
This ofcourse means that all parties must have their own key pair, and the public keys have been shared between them. Also they must use a GPG compliant program to encrypt/decrypt or sign and verify the messages.
Edit: Sorry HN for not knowing something that you know and asking a question about it.
And you need this fix for the latest DP 4:
In addition, as the apps are linked and compiled with different settings (clang, no ppc, no 32-bit, etc.) then plugins that are dependent on these APIs have to find their own way.
ML was a huge change from Lion in many ways. Mavericks has some issues that an individual can resolve on their own (mostly) but it's a moving target as it is not released yet.
But I do encourage you to donate. Integration with your native mail app should be worth $50-100+.
In case of S/MIME email client will tell you that signature is good if it the key, which was used for creating it was issued by a known CA (Certificate Authority).
In case of OpenPGP(GPG,GnuPG,…) you explicitly decide if signature is good either by verifying the key (once) directly with the sender or by using web-of-trust (you trust keys of your friends, who trust keys of their friends, who trusts your correspondent)
edit: just curious, sorry :/
Poke me when a popular web email service implements GPG.
From where I sit I watch the Amish ride by in their horse-drawn buggies several times a day. I'm about as far away from the Valley as you can get (technology-wise) and it "plays" quite well here also.
That was ten minutes of looking. (Of course, you still have to trust your webmail provider completely... but that's the price of webmail.)