30 ms·

It's very unfortunate PGP/GPG hasn't kept up with the times. Today it has two significant issues: 1. The needed trust model has changed significantly. 2. It's

It's very unfortunate PGP/GPG hasn't kept up with the times. Today it has two significant issues: 1. The needed trust model has changed significantly. 2. It's not reusable enough. 1. The original PGP mostly dealt with direct person-to-person relationships. Alice and Bob needed to safely communicate. Perhaps Bob could vouch for Carol. But that was the intended model: closely related groups, with maybe a person trusted to act as an introducer. Today our needs are different, and we need to securely communicate with people we never met, or to verify their signatures. Any Linux system contains thousands of packages, which were worked on by many thousands of developers, one may need to communicate with securely at some point. Eg, I want to verify the GPG signature on the Tor browser, but I never met anyone on the team, and how do I know who knows the team? My personal network actually extends very far. I did the FOSDEM key signing party several times, so my theoretical reach is enormous. But it can only be achived by hacking around GPG's trust model. I need to figure out by hand a path between me and Tor, download the keys, and manually tell GPG I trust each key's signature. This isn't convenient, user friendly, not as safe as it could be. 2. GPG is unfortunately stuck in the "Unix Philosophy" era, where you're supposed to just invoke the binary and parse its text output. I believe this crippled GPG's adoption, because it's slow. GPG has to do the whole startup, reading its key databases and so on every single time. Back when GPG support was introduced into KMail many years ago this added a very noticeable delay to viewing any signed message. And it's sadly still the case. The world badly needs a GPG library, that allows one to skip those startup costs, and to avoid the whole intended model of ~/.gnupg and just let a program do things like interpret in-memory data for any conceivable purpose. This is still badly lacking.

globular-toast 5y ago
I think you're wrong on point 1. PGP was always very much about communicating with people you don't know. Otherwise you'd just use symmetric encryption. Web of trust is still the best way we have to do that. Newer applications like signal etc are what require each pair of correspondents to exchange keys and "complete the graph". The difference with more "modern" technologies is just that they let you implicitly trust keys more easily. Web browsers just have you trust hundreds of CAs without even making you aware of them. Verifying keys on messaging apps is unknown and not understood by the vast majority of users.
- dale_glass 5y ago
  Give it a try, then. 0. GPG implicitly trusts your key. 1. GPG trusts keys you've signed. 2. GPG can also trust keys signed by people you trust. And that's where it ends, normally. So say you want to verify the signature on the Tor browser. So have you met the key holder directly and signed their key? #1 failed. Do you know anybody who signed the Tor key? #2 failed. You can't properly verify it. Actually, GPG allows the chain to extend for longer. You can verify a You -> Alice -> Bob -> Carol chain. The problem is that standard GPG doesn't have any easy way for you to find about Bob. You know Alice, you can find the content signed by Carol, but you may lack Bob's key. You can find it out by hand, by getting Carol's key, finding who signed it, and downloading all those keys hoping somebody you know signed one of those. That's the easy scenario, if you extend this to another step, that is, You -> Alice -> Bob -> Carol -> Dave, it gets even more annoying. And besides not being user friendly, it turns out that GPG sucks at dealing with large key databases, so mass-downloading keys in hopes of finding a connection tends to noticeably degrade performance.
  - globular-toast 5y ago
    I get that it's hard but it's hard because security is hard. What's the alternative? How else can you verify the signature on Tor browser?
    - dale_glass 5y ago
      By explicitly supporting this model. Recognize that in the modern usage model you often need to find a trust path to some completely random person you've never met, such as the maintainer of some random software program. And that you need to support a "good enough" trust model for those cases. What do I mean by that? GPG has two separate things: signatures, and trust levels. When you sign somebody's key, GPG wants to know how confident you are that this person will only sign the keys of people who deserve it. Eg, you can trust that Philip Zimmermann will check fingerprints, but your grandma maybe won't, so her signature isn't worth much if anything. For the first part, GPG needs a path finding service. That is, when dealing with a "You -> Alice -> Bob -> Carol" path, you can give this service your key ID, Carol's key id, and the service tells you whether any path at all exists between those keys. This should be an automatic API that GPG itself can use, like it uses a keyserver. This used to exist, in the form of some random website run by an university professor that now seems gone. It needs to exist as a proper, official webservice. For the second, in GPG's normal security model, GPG is going to ask you how confident you are in Bob's cryptographic knowledge and signing discipline. And how the heck could you know? You don't know him, he's a friend of Alice's. She should know that. Some way needs to be invented to deal with this, either by having Alice's signature on Bob's key contain a trust level, or by having a mode in which a signature is at least better than nothing, and you can get some confidence rating based on how many paths you can take to reach the destination.

globular-toast 5y ago

I think you're wrong on point 1. PGP was always very much about communicating with people you don't know. Otherwise you'd just use symmetric encryption. Web of trust is still the best way we have to do that. Newer applications like signal etc are what require each pair of correspondents to exchange keys and "complete the graph". The difference with more "modern" technologies is just that they let you implicitly trust keys more easily. Web browsers just have you trust hundreds of CAs without even making you aware of them. Verifying keys on messaging apps is unknown and not understood by the vast majority of users.

dale_glass 5y ago
Give it a try, then. 0. GPG implicitly trusts your key. 1. GPG trusts keys you've signed. 2. GPG can also trust keys signed by people you trust. And that's where it ends, normally. So say you want to verify the signature on the Tor browser. So have you met the key holder directly and signed their key? #1 failed. Do you know anybody who signed the Tor key? #2 failed. You can't properly verify it. Actually, GPG allows the chain to extend for longer. You can verify a You -> Alice -> Bob -> Carol chain. The problem is that standard GPG doesn't have any easy way for you to find about Bob. You know Alice, you can find the content signed by Carol, but you may lack Bob's key. You can find it out by hand, by getting Carol's key, finding who signed it, and downloading all those keys hoping somebody you know signed one of those. That's the easy scenario, if you extend this to another step, that is, You -> Alice -> Bob -> Carol -> Dave, it gets even more annoying. And besides not being user friendly, it turns out that GPG sucks at dealing with large key databases, so mass-downloading keys in hopes of finding a connection tends to noticeably degrade performance.
- globular-toast 5y ago
  I get that it's hard but it's hard because security is hard. What's the alternative? How else can you verify the signature on Tor browser?
  - dale_glass 5y ago
    By explicitly supporting this model. Recognize that in the modern usage model you often need to find a trust path to some completely random person you've never met, such as the maintainer of some random software program. And that you need to support a "good enough" trust model for those cases. What do I mean by that? GPG has two separate things: signatures, and trust levels. When you sign somebody's key, GPG wants to know how confident you are that this person will only sign the keys of people who deserve it. Eg, you can trust that Philip Zimmermann will check fingerprints, but your grandma maybe won't, so her signature isn't worth much if anything. For the first part, GPG needs a path finding service. That is, when dealing with a "You -> Alice -> Bob -> Carol" path, you can give this service your key ID, Carol's key id, and the service tells you whether any path at all exists between those keys. This should be an automatic API that GPG itself can use, like it uses a keyserver. This used to exist, in the form of some random website run by an university professor that now seems gone. It needs to exist as a proper, official webservice. For the second, in GPG's normal security model, GPG is going to ask you how confident you are in Bob's cryptographic knowledge and signing discipline. And how the heck could you know? You don't know him, he's a friend of Alice's. She should know that. Some way needs to be invented to deal with this, either by having Alice's signature on Bob's key contain a trust level, or by having a mode in which a signature is at least better than nothing, and you can get some confidence rating based on how many paths you can take to reach the destination.