4 ms·

I have to ask: how are the PGP keys verified?

by chaz72 12y ago

dredmorbius 12y ago
Through the Web of Trust: https://en.wikipedia.org/wiki/Web_of_trust https://en.wikipedia.org/wiki/Web_of_trust http://www.pgpi.org/doc/pgpintro/ http://www.pgpi.org/doc/pgpintro/ http://www.rubin.ch/pgp/weboftrust.en.html http://www.rubin.ch/pgp/weboftrust.en.html Essentially: with cryptography, you aren't concerned about the transport, you're concerned about the crypto. Signatures of the source or binaries will tell you if they've been changed. Signatures on keys will tell you who trusts those keys. If someone you trust trusts a key, then you have a transitive trust of a key. This does mean, though, trusting people not to sign bogus keys. In TLS/SSL, you have a hierarchical trust. Your session (and its contents) are encrypted and authenticated by the host key, which is signed by the CA's key. The theory is that we can trust CAs. Practice shows otherwise. It's not cryptographically viable to fake a signature (of a key or data), though if someone manages to lose control of their private key, that's possible. PGP/GPG doesn't handle expired keys well. But the upshot is that HTTP transport of PuTTY is fine from an integrity standpoint, so long as you verify the binary and signatures. And if you don't mind others being able to see what you're fetching as you're fetching it (the only real benefit to HTTPS in this case). Even an MITM rewrite of data isn't a critical issue since you can catch that in PGP validation.
- chaz72 12y ago
  That's very thorough, thank you! I understand all those things in general, but I don't know the specific mechanism by which my local PGP install recognizes who else trusts this PGP key. I grant you that if the key is protected from MITM then all is well. I just still don't know this part: What mechanism do I use, I who have no prior encounter with that key and no existing PGP setup or connection to any web, to validate that key? I'm sure this is just a lack of familiarity with PGPs web of trust implementation, but lacking this info, I too just opted to trust the plain HTTP download (until I switched to Cygwin/OpenSSH to make it a moot point anyway).
  - chaz72 12y ago
    Never mind, I see a higher ranked comment got an answer to this. I see the concept of keys signing keys and gpg --list-sigs. (Still no idea who might be at the end of that chain that I could actually verify though.)
  - dredmorbius 12y ago
    Generally, you'd need to have a match (or chain) between keys you do trust and those signing a given key. In general, I fetch signatures of keys and may add some of these as partially trusted if they're very well known keys. A bit of bash scripting that helps with this: gpg --list-sigs <key ID> | grep 'not found' | cut -c 13-22 | sort -u | xargs --max-args 10 gpg --recv-keys xargs speeds the process by requesting multiple keys at a time. I think keeping that below 20 keys helps keep the keyservers happy. Sort + uniq eliminates duplicate requests of the same key. You cannot run parallel processes as your local gpg instance cannot do concurrent updates to the keyring.
    - chaz72 12y ago
      For those already using PGP, that sounds great. For me, who is not using PGP, my set of trusted keys is currently empty. So it is unverified. Which, arguably, might be safer than being overly trusting of my "trusted CAs", which is verified by a flawed system. I guess I'm still not thrilled wih my options overall, but thank you for your time explaining how to use PGP.
      - dredmorbius 12y ago
        The WoT is both PGP's strength and weakness. Lacking anything else, key security staff for various Linux distributions and key EFF members isn't a bad starting point for this. Assigning those "marginal" trust means that you'd have to have three of those signing a given key to trust it.
        chaz72 12y ago
        Ah, now that is what I was looking for but didn't know how to ask. A few starting points I might trust would go a long way.

I have to ask: how are the PGP keys verified?

by chaz72 12y ago

I have to ask: how are the PGP keys verified?

Through the Web of Trust: https://en.wikipedia.org/wiki/Web_of_trust https://en.wikipedia.org/wiki/Web_of_trust http://www.pgpi.org/doc/pgpintro/ http://www.pgpi.org/doc/pgpintro/ http://www.rubin.ch/pgp/weboftrust.en.html http://www.rubin.ch/pgp/weboftrust.en.html Essentially: with cryptography, you aren't concerned about the transport, you're concerned about the crypto. Signatures of the source or binaries will tell you if they've been changed. Signatures on keys will tell you who trusts those keys. If someone you trust trusts a key, then you have a transitive trust of a key. This does mean, though, trusting people not to sign bogus keys. In TLS/SSL, you have a hierarchical trust. Your session (and its contents) are encrypted and authenticated by the host key, which is signed by the CA's key. The theory is that we can trust CAs. Practice shows otherwise. It's not cryptographically viable to fake a signature (of a key or data), though if someone manages to lose control of their private key, that's possible. PGP/GPG doesn't handle expired keys well. But the upshot is that HTTP transport of PuTTY is fine from an integrity standpoint, so long as you verify the binary and signatures. And if you don't mind others being able to see what you're fetching as you're fetching it (the only real benefit to HTTPS in this case). Even an MITM rewrite of data isn't a critical issue since you can catch that in PGP validation.

chaz72 12y ago
That's very thorough, thank you! I understand all those things in general, but I don't know the specific mechanism by which my local PGP install recognizes who else trusts this PGP key. I grant you that if the key is protected from MITM then all is well. I just still don't know this part: What mechanism do I use, I who have no prior encounter with that key and no existing PGP setup or connection to any web, to validate that key? I'm sure this is just a lack of familiarity with PGPs web of trust implementation, but lacking this info, I too just opted to trust the plain HTTP download (until I switched to Cygwin/OpenSSH to make it a moot point anyway).
- chaz72 12y ago
  Never mind, I see a higher ranked comment got an answer to this. I see the concept of keys signing keys and gpg --list-sigs. (Still no idea who might be at the end of that chain that I could actually verify though.)
- dredmorbius 12y ago
  Generally, you'd need to have a match (or chain) between keys you do trust and those signing a given key. In general, I fetch signatures of keys and may add some of these as partially trusted if they're very well known keys. A bit of bash scripting that helps with this: gpg --list-sigs <key ID> | grep 'not found' | cut -c 13-22 | sort -u | xargs --max-args 10 gpg --recv-keys xargs speeds the process by requesting multiple keys at a time. I think keeping that below 20 keys helps keep the keyservers happy. Sort + uniq eliminates duplicate requests of the same key. You cannot run parallel processes as your local gpg instance cannot do concurrent updates to the keyring.
  - chaz72 12y ago
    For those already using PGP, that sounds great. For me, who is not using PGP, my set of trusted keys is currently empty. So it is unverified. Which, arguably, might be safer than being overly trusting of my "trusted CAs", which is verified by a flawed system. I guess I'm still not thrilled wih my options overall, but thank you for your time explaining how to use PGP.
    - dredmorbius 12y ago
      The WoT is both PGP's strength and weakness. Lacking anything else, key security staff for various Linux distributions and key EFF members isn't a bad starting point for this. Assigning those "marginal" trust means that you'd have to have three of those signing a given key to trust it.
      - chaz72 12y ago
        Ah, now that is what I was looking for but didn't know how to ask. A few starting points I might trust would go a long way.