5 ms·

In my experience, key distribution is the easiest thing about PGP / GPG. EnigMail and most other clients can already query key servers easily. Enigmail routinel

by x1798DE 12y ago

In my experience, key distribution is the easiest thing about PGP / GPG. EnigMail and most other clients can already query key servers easily. Enigmail routinely asks me to "download missing keys", and if my recipient's key is on a keyserver, it downloads them. In fact, the PGP global directory (https://keyserver.pgp.com/vkd/GetWelcomeScreen.event https://keyserver.pgp.com/vkd/GetWelcomeScreen.event) already seems to have all the features that are missing from the whiteout server (SSL, scalability, e-mail validation, etc). The biggest adoption problem around key management that I see is getting people to generate them securely, then integrating the keys across multiple devices and multiple clients. Maybe this whiteout mail app thing is supposed to be the part of this that makes key management "invisible", but I don't see why they can't use the existing key distribution infrastructure.

michaelt 12y ago
key distribution is the easiest thing about PGP The problem is if you look at the key server and find there are two keys - one legitimate, one posted by an adversary (who has read access to the recipient's e-mail) - both have a few signatures, but the signatories are several degrees away from you in the web of trust.
- schoen 12y ago
  Someone made a fake key for each of the participants in a particular keysigning party in October 2013 (including me) and uploaded the fake keys to keyservers. Because the creation date of the fake key for me is newer than the creation date of my real key, apparently Enigmail is suggesting it to people and they're choosing to use it, despite the lack of signatures. More than a dozen different people have now sent me encrypted mail that I couldn't read because they selected the fake key on the keyservers instead of my real key. That makes me think that the web of trust model isn't working out very well under active attack -- at least, over a dozen people failed to actually use the web of trust to avoid falling victim to this attack. There are also seven keys for Erinn Clark (who signs Tor Browser Bundle releases for the Tor Project) on the keyservers; if I remember correctly, three are real and four are fake.
  - malgorithms 12y ago
    This is important: since PGP is also used for signing software, and in that world, this kind of compromise can be even more dangerous. The Tor example is great. Also, check out how many keys are on MIT's PGP keyserver for Gavin Andresen of the bitcoin foundation. Back in 2013 I downloaded bitcoind and spent like an hour just trying to figure out if it was legit or not.
  - TheLoneWolfling 12y ago
    This sounds like an implementation as opposed to design flaw. Enigmail should be throwing up red flags all over the place when duplicates exist. That being said, this is perilously close to the "No True Scotsman" fallacy.
    - dredmorbius 12y ago
      I'd be really, really cautious about throwing "No True Scotsman" at Seth David Schoen and Erinn Clark. https://en.wikipedia.org/wiki/Seth_Schoen https://en.wikipedia.org/wiki/Seth_Schoen His hopelessly out-of-date homepage: http://www.loyalty.org/~schoen/ http://www.loyalty.org/~schoen/ That said, yes, PGP has a notable failing in that there's no reliable method for repudiating a key, particularly one generated by a hostile party. If you've hung on to your key revocation certificate you can revoke a key you have generated. But that's only a small part of the battle.
      - schoen 12y ago
        I'm sorry my homepage is out of date; thanks for the reminder. It seems like it's been a decade or so since I updated it. I normally check signatures when downloading a new key, particularly as a way of distinguishing between multiple keys available on a keyserver. But I don't have a way to force other people who are writing to me to do that, and apparently at least the Enigmail users often don't. Edit: Erinn is a more cautious PGP user than I am (with an extraordinarily important key!), but I expect she also has no way of forcing people to check that they have the right key when e-mailing her.
- e12e 12y ago
  Agree with both you and GP. According to this blog post, they're not solving the trust issue, they're just working around the issue of a webmail app not being able to query keyservers: > We couldn’t make cross origin requests to HKP > servers from the web version of our app. It's not entirely clear if the REST proxy for hkp they've created is open source -- if not it's almost useless as far as I can see. If I were to trust my secret key to the browser/a browser "app", I'd have to download the app from a web-server I trust and control (ie: my own server). And I'd certainly not want to load anything from any other server. I might trust a sanitizing REST proxy under my control to go and get gpg-keys. Either way, while Trust-on-first-use is certainly pragmatic -- if that's all you're going to do, then there's nothing wrong with most email clients that have gpg-support -- most will do that gladly! One might argue that in addition to downloading keys, they should be signed as "marginally trusted" on first use (or maybe there should be another trust-level in gpg/pgp: "TOFU" -- to avoid anyone else mistakenly trusting the key). I think semi-structured "CAs" for gpg would be a much better solution: allow banks/post offices/DMV to sign and upload a gpg-key -- demanding that such keys had an attached photo, and that the institution verified the ID/name at the time of signing (with the same level of trust that is usually demanded by institution that make valid IDs: a valid passport etc). If I could go to the bank, and get a copy of their key, and sign that (and have them sign mine) -- and so have a good pathway to "everyone's" key -- that'd be great. And unlike with browser CAs - I could chose who to trust to delegate IDs. As I've mentioned elsewhere I think cacert.org should also sign GPG-keys (just as a convenience -- you could of course sign your gpg-key with your CA-cert -- but that would require manual intervention to verify the chain of trust, unlike a signature by a trusted gpg-key). As for the "Snowden" use-case -- TOFU is fine. Someone sends you signed and encrypted data, you can assume you're talking to whoever has the key. Maybe you can't be sure it's not the FBI/CIA/NSA/GCHQ setting you up -- but does it really matter? You've already started a dialogue, and that's probably enough to put you away for life...
kevinr 12y ago
They are using the existing key distribution infrastructure -- the whole point is that they'll go fetch keys for you from a selection of HKP servers if they don't have one on theirs with a verified e-mail address.

by x1798DE 12y ago

michaelt 12y ago

key distribution is the easiest thing about PGP The problem is if you look at the key server and find there are two keys - one legitimate, one posted by an adversary (who has read access to the recipient's e-mail) - both have a few signatures, but the signatories are several degrees away from you in the web of trust.

schoen 12y ago
Someone made a fake key for each of the participants in a particular keysigning party in October 2013 (including me) and uploaded the fake keys to keyservers. Because the creation date of the fake key for me is newer than the creation date of my real key, apparently Enigmail is suggesting it to people and they're choosing to use it, despite the lack of signatures. More than a dozen different people have now sent me encrypted mail that I couldn't read because they selected the fake key on the keyservers instead of my real key. That makes me think that the web of trust model isn't working out very well under active attack -- at least, over a dozen people failed to actually use the web of trust to avoid falling victim to this attack. There are also seven keys for Erinn Clark (who signs Tor Browser Bundle releases for the Tor Project) on the keyservers; if I remember correctly, three are real and four are fake.
- malgorithms 12y ago
  This is important: since PGP is also used for signing software, and in that world, this kind of compromise can be even more dangerous. The Tor example is great. Also, check out how many keys are on MIT's PGP keyserver for Gavin Andresen of the bitcoin foundation. Back in 2013 I downloaded bitcoind and spent like an hour just trying to figure out if it was legit or not.
- TheLoneWolfling 12y ago
  This sounds like an implementation as opposed to design flaw. Enigmail should be throwing up red flags all over the place when duplicates exist. That being said, this is perilously close to the "No True Scotsman" fallacy.
  - dredmorbius 12y ago
    I'd be really, really cautious about throwing "No True Scotsman" at Seth David Schoen and Erinn Clark. https://en.wikipedia.org/wiki/Seth_Schoen https://en.wikipedia.org/wiki/Seth_Schoen His hopelessly out-of-date homepage: http://www.loyalty.org/~schoen/ http://www.loyalty.org/~schoen/ That said, yes, PGP has a notable failing in that there's no reliable method for repudiating a key, particularly one generated by a hostile party. If you've hung on to your key revocation certificate you can revoke a key you have generated. But that's only a small part of the battle.
    - schoen 12y ago
      I'm sorry my homepage is out of date; thanks for the reminder. It seems like it's been a decade or so since I updated it. I normally check signatures when downloading a new key, particularly as a way of distinguishing between multiple keys available on a keyserver. But I don't have a way to force other people who are writing to me to do that, and apparently at least the Enigmail users often don't. Edit: Erinn is a more cautious PGP user than I am (with an extraordinarily important key!), but I expect she also has no way of forcing people to check that they have the right key when e-mailing her.
e12e 12y ago
Agree with both you and GP. According to this blog post, they're not solving the trust issue, they're just working around the issue of a webmail app not being able to query keyservers: > We couldn’t make cross origin requests to HKP > servers from the web version of our app. It's not entirely clear if the REST proxy for hkp they've created is open source -- if not it's almost useless as far as I can see. If I were to trust my secret key to the browser/a browser "app", I'd have to download the app from a web-server I trust and control (ie: my own server). And I'd certainly not want to load anything from any other server. I might trust a sanitizing REST proxy under my control to go and get gpg-keys. Either way, while Trust-on-first-use is certainly pragmatic -- if that's all you're going to do, then there's nothing wrong with most email clients that have gpg-support -- most will do that gladly! One might argue that in addition to downloading keys, they should be signed as "marginally trusted" on first use (or maybe there should be another trust-level in gpg/pgp: "TOFU" -- to avoid anyone else mistakenly trusting the key). I think semi-structured "CAs" for gpg would be a much better solution: allow banks/post offices/DMV to sign and upload a gpg-key -- demanding that such keys had an attached photo, and that the institution verified the ID/name at the time of signing (with the same level of trust that is usually demanded by institution that make valid IDs: a valid passport etc). If I could go to the bank, and get a copy of their key, and sign that (and have them sign mine) -- and so have a good pathway to "everyone's" key -- that'd be great. And unlike with browser CAs - I could chose who to trust to delegate IDs. As I've mentioned elsewhere I think cacert.org should also sign GPG-keys (just as a convenience -- you could of course sign your gpg-key with your CA-cert -- but that would require manual intervention to verify the chain of trust, unlike a signature by a trusted gpg-key). As for the "Snowden" use-case -- TOFU is fine. Someone sends you signed and encrypted data, you can assume you're talking to whoever has the key. Maybe you can't be sure it's not the FBI/CIA/NSA/GCHQ setting you up -- but does it really matter? You've already started a dialogue, and that's probably enough to put you away for life...

kevinr 12y ago

They are using the existing key distribution infrastructure -- the whole point is that they'll go fetch keys for you from a selection of HKP servers if they don't have one on theirs with a verified e-mail address.