GPGMail 2 is finally here | Hacker News Reader

GPGMail 2 is finally here

gpgtools.org

201 pointslukele73 comments

Email encryption is a good start!

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/

The perfect is the enemy of the good.

Now I'm curious about how you're applying this to the current context... Care to explain?

He likely means that email encryption (the good) is incrementally achievable, while RetroShare and Darknet (the perfect) requires a much more disruptive change.

Ok.

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

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.

Yup.

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.

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.

You got a point. Added that!

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.

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.

It seems to still do that, however I have not had any problems installing gpg2 via homebrew and overwriting the destination binary, e.g.,

    brew link gpg2 --overwrite

(use the above with `--dry-run` first; I only have one symlink that gets overwritten, but you may have more.)

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.

There is a "Customize" option in the installer that seems to provide an option to not install MacGPG, but I haven't tried that to make sure.

Yes, you can choose to install GPGMail, GPGPreferences, etc., without MacGPG, and use your own gpg binaries such as from homebrew.

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.

Observations after installing on 10.6.8:

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

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

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.

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.

[2] See the answer by Adam Liss (not the accepted answer) for the security issues http://stackoverflow.com/questions/13512026/how-to-check-if-...

[Edit: formatting]

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

No, you cannot revoke your s/mime cert. Your CA can. That is a big difference.

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.

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.

Relevant xkcd: http://xkcd.com/1181/

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.

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?

GPGMail is nicely integrated into Mail.app. It plays well with s/mime, so you can have both installed, and use either one that is appropriate.

For easy steps on how to do this see here:

http://arstechnica.com/apple/2011/10/secure-your-e-mail-unde....

You can get a free cert from COMODO:

http://www.comodo.com/home/email-security/free-email-certifi....

I use StartCom https://cert.startcom.org/

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.

That's exactly the reason, why "DANE" approach is developed now, to replace CAs use for HTTPS

https://tools.ietf.org/wg/dane/ http://www.internetsociety.org/articles/dane-taking-tls-auth...

GPGMail is not quite Grandmother ready

My little company is working on an encrypted email solution that is--http://parley.co will be entering pre-beta next week :)

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:

    <form action="http://parley.us6.list-manage.com/subscribe/post?u=NN&amp;id=NN" method="post"

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.

Thanks for the heads up! We just set up SSL for the main site, and obviously missed a few things--I'll fix that right now.

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?

No, they just have to use GPG or PGP. GPGMail is just a front-end for those tools.

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.

Enigmail for Thunderbird: http://www.enigmail.net/home/index.php

GPG4Win provide plugins for Outlook: http://gpg4win.org

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.

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.

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.

Huh, has Google said anything about the naming similarity between GPGMail and Gmail?

Edit: Sorry HN for not knowing something that you know and asking a question about it.

GPGMail predates Gmail by three years.

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.

Nobody sane would think GPGMail is infringing on Gmail in any shape or form.

It's good that legal teams never do anything that looks insane then ;-)

Google wasn't really first to use 'gmail' anywhere -

http://www.guardian.co.uk/media/pda/2010/may/04/digital-medi...

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

There's a special hack version out for Mavericks:

https://s3.amazonaws.com/gpgtools/GPGMail-Mavericks-P2-hack....

And you need this fix for the latest DP 4: http://support.gpgtools.org/discussions/everything/9888-mave...

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.

Great!

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

I currently use Mail.app's built-in signing and encrypting capability with a free StartCom S/MIME cert. Does this offer something more/different?

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)

http://security.stackexchange.com/questions/7874/how-does-pg...

I am a bit surprised by the use of the modified Apple Mail.app icon. Are they connected to Apple somehow?

edit: just curious, sorry :/

Not connected to Apple, just a very old icon which was never really updated. Might happen in the future though, to avoid legal issues

I thought they just announced a new version recently? Is this a new version again, or just a new website?

All versions before this were beta. This is the stable version of GPGMail 2 with 77 bugs fixed from the last beta, so you should update.

Thanks -- it turns out the the update checker on my version wasn't working (for whatever reason), so I mistakenly thought I had the latest version.

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.

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.

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.

I wouldn't really recommend Hushmail:

http://www.cybercrimereview.com/2012/11/hushmail-provides-un...

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

https://github.com/seancolyer/gmail-crypt http://www.curetheitch.com/projects/webpg-chrome/ http://www.mailvelope.com/ https://github.com/crised/SafeGmail

That was ten minutes of looking. (Of course, you still have to trust your webmail provider completely... but that's the price of webmail.)

Reply on news.ycombinator.com