Personally, I think, the user is best served with the "darknet" [0] 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 [1] 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.
He likely means that email encryption (the good) is incrementally achievable, while RetroShare and Darknet (the perfect) requires a much more disruptive change.
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.)
Email encryption is going to be effective against 99% of relevant attacks, and if the NSA wants to know what you're doing, they'll put a bug in your laptop and, no, you won't notice.
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.
I know, I know, I don't even consider myself a target, at all. I don't really do this to just protect myself.
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.
For those of us who have never heard of this software, it would be great if somewhere prominent on the webpage it said what GPGMail actually is. Instead the most prominent thing is how many bug fixes and sleepless nights this mystery software required.
The last version of GPGTools I looked at had the irritating habit of always installing its own copy of GPG into /usr/local and not letting me use my own version (e.g., from Homebrew). Is this still the case in version 2?
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.
Thanks guys — I was afraid it was something like that. I absolutely hate it when Mac software litters stuff outside of its bundle without even asking the user. Plenty of people figured it out correctly — GitHub.app, for example, installs a copy of the git command-line tools into its ./Content/Resources/git, and remains self-contained and clean.
GPGTools guys — if you're reading this thread, please please stop installing stuff outside your plugin's bundles.
It's "self-contained" in /usr/local/MacGPG2.
Only creates symlinks into /usr/local/bin but will avoid that if it recognizes another gpg already being linked there.
Also, linking warnings when using homebrew's GPG are resolved.
I see. This isn't clean enough for my tastes. I run Homebrew from a custom directory, not /usr/local, and I want to make GPGMail refer to the gpg binary there. No Mac app installer should ever write anything to /usr/local.
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.
I tried installing GPGMail stand-alone with a previous version, and it caused Mail.app to crash on start, presumably because /usr/local/bin/gpg was not available.
* 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.)
SHA Hash and signature will be added tomorrow. In all the excitement we forgot about that.
Please file the bug report for GPGPreferences on https://support.gpgtools.org
Thanks!
I had some experience with GnuPG and Symantec PGP and Outlook a few years back. All non-public information like CAD files were supposed to be PGP encrypted. Yet, even the engineers would send most files in plain text. I remember many times having to logmein to a clients machine to try to figure out why they couldn't read our emails. This is why PGP never took off.
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.
I'd say ("first time") setup is pretty easy (and has been for a while). The tricky part (as always) is managing the keys (the private key, and the (optional) revocation key) -- and managing trust.
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.
>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.
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.
My company's internal mail goes through gmail so I decided after recent news to setup GPGmail and s/mime.
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[1], 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:
s/mime pros
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[1]
s/mime cons
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[2],
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)
--
GPGmail/tools pros
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
Optional Anonymity
Strong cryptography
Use the same keys for non email encryption
Free
GPGmail/tools cons
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.
[1] With s/mime you can sign email documents even if your friends don't have s/mime that can still see your signature is validate.
Just two nitpicks: You can sign email with GPG even if others aren’t using it (of course it will be of little value to them until they, possibly at a later date, verified your key), and it is supported on Android by K-9, I believe.
Worth noting here that K-9 for Android does not support the more modern and useful PGP/MIME. It only supports inline PGP. They've been promising it for years, but I'm not expecting to ever see it.
Hopefully somebody makes a good go at getting PGP onto Firefox OS so I can ditch Android.
Yes you can, but my point was that this is of no utility with GPG. Whereas with s/mime anyone can confirm that your email was signed (with many email clients), so there is value to using s/mime prior to all your contacts also using it.
> anyone can confirm that your email was signed (with many email clients), so there is value to using s/mime prior to all your contacts also using it.
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?
Right now if I send my Grandmother a signed email with s/mime she will see a little notice in her email client that says the message is signed and valid. If I send her an email with a PGP signature it will not.
This is because just like her browser the CA is trusted by her OS.
Any recommended CAs for S/MIME for personal users? And is it possibly to transparently use both, e.g. sign all outgoing mail with S/MIME by default, but also encrypt with, say, GPG if you happen to have that contact's public key?
No. You absolutely must confirm the key of people you correspond with. An internal CA in your organisation could achieve this, but the "trust a random list of CAs" model of security is fragile, and must be considered compromised in the face of an adversary like the NSA (or any government in a country where a CA on your trusted list is located).
Well either you trust the CA system or you don't. If you do then receiving a s/mime signature, that your OS thinks is valid because of the root certificates that it accepts, then you can trust it "transparently".
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.
No. Degrees of trust are allowed, and you can choose to do different things in different contexts (browsing vs email) depending on the likelihood and likely damage of betrayal.
Since you seem to server your site (parley.co) over https, you might want to accept signups over https as well -- it's a little disconcerting to get a warning message of information being posted in the clear from a page that is all about making it easier to communicate securely online:
Other than that it'll be interesting to see your implementation -- I've been considering the idea of key storage for a while, and I also think so long smart cards aren't ubiquitous (and usable with all clients, such as phones as well as PCs) -- pass-phrases is unfortunately as good as it gets.
It's unfortunate, because anything based on shared secretes (directly) makes key revocation tricky.
you can revoke your S/MIME key from a CA (you just need to remember the revocation password you gave them)
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).
How does this work? I assume all encrypted emails require both parties use the software, right? So, all my friends, associates, coworkers have to have GPGMail to read my encrypted emails?
GPGMail uses a very well known and white spread technology OpenPGP as its base.
Everyone you want to use it with has to have a mail client which supports OpenPGP in one form or another, but there are many plugins out there, who add support for your favorite mail clients on windows and linux.
It's a typical crypto add-on for a mail client, yes: you can only exchange encrypted mail with other folks who can use PGP. That's pretty much how crypto works.
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.
GPG uses asymmetric keypairs for encryption. You generate (at the same time), two different keys: a private key and a public key. The private key is your identity, which you can use to sign outgoing messages, and decrypt incoming messages. The public key, you share to your associates can be used to verify your signature, or encrypt messages only meant for you.
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.
Not (initially) in the online domain, but I know of significantly sized, well established U.S. institution that was using "Gmail" (yes, exactly that term) publicly and in promotional materials including particularly mailings... oh, probably a good decade before Google.
That was far and away the easiest and fastest walk through from download -> sending an encrypted and signed email that I've ever seen. Obviously, it only covers one platform, but it's a great start.
Mavericks is not yet supported it seems - "Incompatible Plug-ins Disabled [..] Contact the makers of these plug-ins for versions that are compatible with Mail 7.0 and Message 7.0."
They just shipped support for Mountain Lion, which was released one year ago. I hope there is not as big a delay for Mavericks. I understand that it's a volunteer project, but a kickstarter could surely help them muster the $100 for a Mac developer subscription and access to the developer previews of 10.9.
10.9 is being actively tested internally and we've already released two hacked together preview versions for it. Doing everything we can to be on time this time for real.
You're underestimating the level of effort here. It's not about lacking the $100 (they've received more than that in donations), it's that Apple makes significant changes to the way their applications are built and run and they don't communicate the changes very well, if at all.
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+.
signature process is almost the same, but this thing uses different approach to "trust" to the signatures.
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)
This is just MacOS nonsense. It plays in the Valley and at the mall, and nowhere else. The only reason it is on the front page of Hacker News is that we can't see outside our own event horizon.
Poke me when a popular web email service implements GPG.
Hushmail implements GPG, though perhaps it does not pass your definition of 'popular'.
Any current implementation of GPG by _web email_ is probably insecure as it would rely on JavaScript cryptography. Perhaps when the W3C passes the browser cryptography draft, and browsers start adding that in, we might see this. But the economics aren't aligned, because popular web email services want to see what you read and write, so they're not particularly motivated to give you strong encryption.
> It plays in the Valley and at the mall, and nowhere else.
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.
Pardon us for being interested in something that a lot of us can benefit in? I didn't see a sign when coming in that said everything on the front page needs to be world-changing news.
Personally, I think, the user is best served with the "darknet" [0] 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:
[0] http://en.wikipedia.org/wiki/Darknet_%28file_sharing%29
RetroShare [1] 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.
[1] http://en.wikipedia.org/wiki/Retroshare
EDIT: Direct link - http://retroshare.sourceforge.net/