3 ms·

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

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.
  - rjzzleep 5y ago
    One thing I've noticed is that package signing has a bit of an issue. It lacks metadata about the package. I'll use archlinux as an example but the same applies to PPA's in Ubuntu: Say you add a public key of a third party because you want to install a certain package or add a certain repo. The keyring then trusts that key. But it doesn't trust the key for a specific package. It just generally trusts the key. From a security aspect your system is not compromised, because the security of your base packages now depends on whether random key for third party is compromised. I.e. you can now install backdoored software because that package you wanted to add is compromised. It's not really limited to linux repos though, imagine you install a driver on windows and it asks you to trust the signing key. That signing key can now be use to put random malicious software on your windows system. Is there any reason why this metadata couldn't be added to something like pgp other than it requiring a lot of changes in the tooling?
    - dale_glass 5y ago
      My view is that it's because GPG sucks, and has been used for things it doesn't want to be used for. GPG's usage model is a commandline tool, used by a person to verify a signature on a file or such. It has a keyring in ~/.gnupg, and importing keys imports them into this keyring. And it really insists on that. This whole idea of having a key that only applies to a specific package or repository was never intended in its design. When something like a package manager uses GPG it calls the commandline tool and gives it a home directory and keyring somewhere. What the world really needs is a GPG library. But not GPGme, which just calls the GPG binary and parses the output. What is needed is one that dispenses with any ideas about how the end-user is supposed to work and just provides primitives to parse keys and messages, verify signatures, etc, and lets the user make decisions about whether to have a global list of keys, or per-repo keys, use a proper database like postgres, or even not store anything at all if all you need is to parse something. But alas, such things are still scarce, and the prevailing model is just hacking GPG into sort of doing a job it doesn't want to do. There's also some weirdness on the package handling side. Apparently the modern way of doing things in Debian is that you don't sign a package, you sign the repository metadata instead. This may be motivated by the fact that GPG sucks and is slow (because you're calling a binary that loads libraries, parses config file and databases every time, etc), and calling GPG a thousand times during installation would be a significant slowdown.
upofadown 5y ago
>Actually, GPG allows the chain to extend for longer. You can verify a You -> Alice -> Bob -> Carol chain. But it certainly doesn't mandate it. It's called the web of trust, not the chain of trust. You would never have such a chain of trust in real life so there is no reason to use PGP to create a model that doesn't make sense. Trust is normally quite shallow. This is a generic rhetorical technique often used against flexible systems. The flexibility is used to create absurd straw men.
- dale_glass 5y ago
  The web can be seen as being made from many chains. https://imgur.com/a/aTDcbtu https://imgur.com/a/aTDcbtu Those connections exist on keyservers already, GPG just doesn't have a comfortable way of finding them. For instance if you want to verify M's key, you have: A -> B -> G -> M A -> C -> H -> M A -> D -> H -> M A -> E -> I -> M Using multiple paths should allow building some confidence into M's key. The issue is that in the current model, A has the keys for B, C, D and E, and also M's key since they're trying to check their signature. But the rest of the web that is present on keyservers isn't easily reachable to the user.

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.
- rjzzleep 5y ago
  One thing I've noticed is that package signing has a bit of an issue. It lacks metadata about the package. I'll use archlinux as an example but the same applies to PPA's in Ubuntu: Say you add a public key of a third party because you want to install a certain package or add a certain repo. The keyring then trusts that key. But it doesn't trust the key for a specific package. It just generally trusts the key. From a security aspect your system is not compromised, because the security of your base packages now depends on whether random key for third party is compromised. I.e. you can now install backdoored software because that package you wanted to add is compromised. It's not really limited to linux repos though, imagine you install a driver on windows and it asks you to trust the signing key. That signing key can now be use to put random malicious software on your windows system. Is there any reason why this metadata couldn't be added to something like pgp other than it requiring a lot of changes in the tooling?
  - dale_glass 5y ago
    My view is that it's because GPG sucks, and has been used for things it doesn't want to be used for. GPG's usage model is a commandline tool, used by a person to verify a signature on a file or such. It has a keyring in ~/.gnupg, and importing keys imports them into this keyring. And it really insists on that. This whole idea of having a key that only applies to a specific package or repository was never intended in its design. When something like a package manager uses GPG it calls the commandline tool and gives it a home directory and keyring somewhere. What the world really needs is a GPG library. But not GPGme, which just calls the GPG binary and parses the output. What is needed is one that dispenses with any ideas about how the end-user is supposed to work and just provides primitives to parse keys and messages, verify signatures, etc, and lets the user make decisions about whether to have a global list of keys, or per-repo keys, use a proper database like postgres, or even not store anything at all if all you need is to parse something. But alas, such things are still scarce, and the prevailing model is just hacking GPG into sort of doing a job it doesn't want to do. There's also some weirdness on the package handling side. Apparently the modern way of doing things in Debian is that you don't sign a package, you sign the repository metadata instead. This may be motivated by the fact that GPG sucks and is slow (because you're calling a binary that loads libraries, parses config file and databases every time, etc), and calling GPG a thousand times during installation would be a significant slowdown.

upofadown 5y ago

>Actually, GPG allows the chain to extend for longer. You can verify a You -> Alice -> Bob -> Carol chain. But it certainly doesn't mandate it. It's called the web of trust, not the chain of trust. You would never have such a chain of trust in real life so there is no reason to use PGP to create a model that doesn't make sense. Trust is normally quite shallow. This is a generic rhetorical technique often used against flexible systems. The flexibility is used to create absurd straw men.

dale_glass 5y ago
The web can be seen as being made from many chains. https://imgur.com/a/aTDcbtu https://imgur.com/a/aTDcbtu Those connections exist on keyservers already, GPG just doesn't have a comfortable way of finding them. For instance if you want to verify M's key, you have: A -> B -> G -> M A -> C -> H -> M A -> D -> H -> M A -> E -> I -> M Using multiple paths should allow building some confidence into M's key. The issue is that in the current model, A has the keys for B, C, D and E, and also M's key since they're trying to check their signature. But the rest of the web that is present on keyservers isn't easily reachable to the user.