Live data from Hacker News

How to support PGP encryption in Gmail

conorpp.com

21–30 of 51 posts

Re: How to support PGP encryption in Gmail

#21
post #8

What is so terrible for people about using an email client? I find using the Gmail web interface to be frustrating because they've removed the ability to pop out the compose view into it's own window, so I can't easily reference information in another browser tab while writing an email for instance. Meanwhile, Gmail has excellent IMAP support, which lets me use Thunderbird + Enigmail to get excellent PGP support.

I use the gmail priority inbox and have not seen a single mail client that is able to replicate that. It's incredibly powerful, showing me the emails first that are labeled as important and are unread, then the already read and starred emails, then everything else. This vertical split into three sections is quite important to its power. Combined with some data crunching algorithms that learn what is important to me it's very easy to keep working on only the important things, even though you might get flooded. I'm so dependend on it that Thunderbird simply doesn't cut it. The only reason I use Thunderbird is for these people who really,really want to encrypt mails. Otherwise it doesn't get even a little close to what I want. Do you know if it's possible to get this in Thunderbird?

PS: Not even the Android Gmail client can replicate that. It can show my important labeled mails, but also shows the already read ones and doesn't have that split.

Re: How to support PGP encryption in Gmail

#22
post #9

I tried to use gnupg but can't wrap my head around the web of trust. My main concern of WoT: What my signature of an other guy's public key actually means? My takeaway is that there is an implicit statement that you sign, but I don't really know what it is. According to the gnupg privacy handbook[1] this statement is roughly "I trust that this guy can properly sign other stuff" which is kind of recursive, but I like…

You're correct, and I think this is part of the growing disgruntling about PGP.

The most successful deployment, Debian, is a closed system: while Debian developers' keys and signatures are on the standard public keyservers, for Debian membership and archive authentication purposes, only signatures from existing Debian members count, and only keys explicitly pushed to Debian servers are usable. So it is possible for Debian to demand a specific meaning for signatures (which, possibly surprisingly, is "I have verified that the government associates this name with the holder of this private key": https://lists.debian.org/debian-devel/2009/06/msg00787.html), and it can hope that its members use a compatible definition when signing other members' or prospective members' keys. But Debian does not read trustworthiness, either to sign other keys or to generally be a good person, in PGP signatures. That's set by being / becoming a member of the project, which is no one's individual decision.

Leaving aside trust, keysigning parties have increasingly been sounding to me like an invitation to show up with fake ID and find some people who've never met you before. Possibly while everyone is drinking. They're also sort of a weird habit for a privacy-loving crowd, since they involve publishing non-deniable records of who met who, but hey.

To be fair, none of this means that the PGP protocol is bad, or even the GnuPG software is bad (although GnuPG sometimes seems like it wants to make the web of trust even murkier than it is). It just means that the public web of trust is useless, and you either need direct key exchange with those with whom you want to communicate, or some sort of organization that you trust to verify keys for the purpose at hand. For instance, if you're doing email within a company for company purposes, letting the company track keys is probably totally fine.

Re: How to support PGP encryption in Gmail

#23

FAQ is a bit confusing. They say there's only one keyring, but at https://github.com/google/end-to-end/wiki/Keyring they admit it was not a great idea and that they're splitting the responsibilities. Based on the last planned implementation (External Key Manager (GnuPG bridge, other hardware, network oracle etc..)), I hope it will "just work" with hardware keys.

One of the developers here:

Yes, the Keyring reimplementation is in progress and ends very soon. After the redesign, applications built on top of E2E library will be able to use different sources of both public and private keys (so it's easy to do integrations with GnuPG, hardware keys HKP, or e.g. Facebook).

The API will be similar to what's in https://github.com/google/end-to-end/wiki/Keyring.

Re: How to support PGP encryption in Gmail

#24
post #2

At the moment, end-to-end is NOT production ready, and will likely undergo further hardening in the coming months. Use at your own risk.

I agree that it's not yet ready for general use, but what hardening do you expect to happen in the coming months? I'm one of the original end-to-end authors, but haven't worked on it recently.

I'm an developer on E2E team as well and can confirm that there's no 'hardening' going on. E2E is, to the best of our knowledge and we have expressed what that exactly means in our threat model: https://github.com/google/end-to-end/wiki/Threat-model. E2E is under Google VRP (https://www.google.ch/about/appsecurity/reward-program/), so if you're aware of any vulnerabilities, let us know.

E2E extension is not production ready, but I myself am using the compiled version as it is, in my biased opinion, the most secure of existing PGP-in-the-browser extensions.

Re: How to support PGP encryption in Gmail

#25
post #22
post #9

I tried to use gnupg but can't wrap my head around the web of trust. My main concern of WoT: What my signature of an other guy's public key actually means? My takeaway is that there is an implicit statement that you sign, but I don't really know what it is. According to the gnupg privacy handbook[1] this statement is roughly "I trust that this guy can properly sign other stuff" which is kind of recursive, but I like…

You're correct, and I think this is part of the growing disgruntling about PGP. The most successful deployment, Debian, is a closed system : while Debian developers' keys and signatures are on the standard public keyservers, for Debian membership and archive authentication purposes, only signatures from existing Debian members count, and only keys explicitly pushed to Debian servers are usable. So it is possible for…

Huh, I didn't know about the Debian rules. But Debian keys and signatures are published to public keyservers too, aren't they? So your trust paths that contain a Debian developer may not guarantee the trustworthiness of the endpoint.

I thought that bootstrapping my trust from one of the Debian developers would make sense, since I already have Debian installed (somewhere you have to start). Looks like it's not that a good idea.

Re: How to support PGP encryption in Gmail

#26
post #2

At the moment, end-to-end is NOT production ready, and will likely undergo further hardening in the coming months. Use at your own risk.

> end-to-end is NOT production ready

This sounds wrong, given that "end-to-end encryption" as a concept is very much production ready.

Re: How to support PGP encryption in Gmail

#27
It's worth mentioning Mailvelope ( https://www.mailvelope.com/ )

- Free - Supported in FF / Chrome - Supports Gmail, Yahoo, Outlook and GMX

I've been using it extensively for about 12 months now. It's solid, unobtrustive, and just .. works.

Decryption of attachments would be nice, but it's definitely not a deal breaker.

Re: How to support PGP encryption in Gmail

#28
post #23

FAQ is a bit confusing. They say there's only one keyring, but at https://github.com/google/end-to-end/wiki/Keyring they admit it was not a great idea and that they're splitting the responsibilities. Based on the last planned implementation (External Key Manager (GnuPG bridge, other hardware, network oracle etc..)), I hope it will "just work" with hardware keys.

One of the developers here: Yes, the Keyring reimplementation is in progress and ends very soon. After the redesign, applications built on top of E2E library will be able to use different sources of both public and private keys (so it's easy to do integrations with GnuPG, hardware keys HKP, or e.g. Facebook). The API will be similar to what's in https://github.com/google/end-to-end/wiki/Keyring .

One thing that is currently missing from E2E (as far as I can tell having played with it a little in the last month) is any kind of web of trust. When I import a key, I can't tell if it has been signed by me or someone I trust. Is this on the radar for the UI after the Keyring reimplementation is finished?

At the moment, what we've suggested at our work is that people manage keys in GPG and then only export keys into E2E if they trust them. But it would be nice be able to do those kinds of things in E2E (or at least be able to tell if a key was signed by me).

BTW, thanks for working on this!

Re: How to support PGP encryption in Gmail

#29
post #27

It's worth mentioning Mailvelope ( https://www.mailvelope.com/ ) - Free - Supported in FF / Chrome - Supports Gmail, Yahoo, Outlook and GMX I've been using it extensively for about 12 months now. It's solid, unobtrustive, and just .. works. Decryption of attachments would be nice, but it's definitely not a deal breaker.

Signing of encrypted messages is not supported at the moment. Unfortunately that's a deal breaker for me :-( But it does look very nice.

Re: How to support PGP encryption in Gmail

#30
post #16

Earlier quoted context omitted.

I don't think pgp ever can provide validation that some person owns some email address. You're signing the uid/address on a key which people prove they control. You can ask them to send you a signed message from that address to prove it, but if they owned someone's key, they likely have access to the email too. Even if they don't emails are still very easy to spoof. Regarding changing the uid, your scenario cannot ha…

I really don't mean the email address but the real name. People normally verify real names when they sign someone else's key anyway. Of course there is the problem that real names are often not unique. Email address spoofing is too easy, I don't think that "owning" an email address is reasonably verifiable. I wasn't aware that people sign each others uid. What happens if someone's name legally changes? Does he/she ha…

"Signing a key" really means signing the binding of a uid to a public/private key pair. I had to look at the Open PGP spec to figure that out ;-)

The question is, how to do verify that a particular person is exclusive owner of a uid? Because the uid is just a piece of text, there is no general way that will work every time. It depends on what the uid is. Someone could put their Passport number in the uid and you could check the passport to verify that they own it.

Of course most people use an email address as a uid. There are some key exchange protocols that will give you a pretty good idea that someone controls an email address (although they may not be exclusive owner). Basically you email them with some information and then they email you back with an encrypted version of that information. While they can spoof sending the email, they can't easily receive the original information to encrypt it.

Generally speaking, online, email uids are what is most useful. You need to know that the person who sent the message has access to the email address in the uid. But if you are actually concerned about the identity of the person, passport numbers, etc are better uids.

A key can actually have many uids. You can add new ones at any time. But if you do, you need to get people to sign the new uids (because while they may trust that you control one uid, they still need to verify that you actually control the other uid).

How you decide that the uid is owned by the owner of the key is up to you and you are free to sign or not sign any key. The web of trust comes where someone else has signed the uid on a key. There is a kind of second order level of trust with that signature. If my buddy Fred has signed the uid, and I am absolutely sure that Fred will never sign a uid without making sure that it is owned by the owner of the key, then I will probably trust it. But if my buddy Carl signs it, I might think "Carl is not diligent enough to check it out", so I might not trust it as much. How you assign trust of third parties to sign appropriately is up to you (and you do it for each of the third party keys that may have signed something).

I hope that helps!

Post reply on HN