Making PGP Key Management Invisible So Johnny Can Encrypt

Question. Do you plan on gossiping with or mirroring the SKS pools? I would love to be able to just search keybase for a public key rather than both:

https://diafygi.github.io/publickeyjs/

Can you give us the txId of a bitcoin transaction used to represent the entire state?

He wasn't kidding about a bunch, I've only burned through about a tenth of them. :) Still have more available.

This is a good question: generally if all you know about someone is their twitter name, and that's it, then a compromise of their twitter account could lead to a compromise of their key announcement.

Even this case is mitigated because of the timestamping: a compromise would have to be a public compromise on an ongoing basis, and everyone in the world would have to see the same compromise, including the alleged twitter holder. Tracker statements add to the timestamping: when someone runs the Keybase client and tracks them, they sign a statement saying on date X twitter user Y had that public key and they checked it.

The second advantage is that a person is typically a sum of many identities. Consider a known developer who signs code using their Keybase announced key. (Let's say Jeremy Ashkenas does (does he?) - anyway, he's on Keybase as https://keybase.io/jashkenas). His public key is announced on his Github and Twitter accounts, both of which are known. He signs those statements with the matching private key. If you ask Keybase for his key, you get 3 things: Keybase telling you what it is, Twitter agreeing with you, Github agreeing with you, and bitcoin telling you everyone in the world has gotten the same answer for those 3 accounts for the last few months. And CLI tracker statements timestamping, too.

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.

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...

If you want to avoid being in a dragnet, just requiring TLS using policies on your SMTP server is enough. That's what many organizations do already.

If you just want "encryption" as a checkbox, then just use Gmail with everyone and your data isn't going anywhere outside Google anyways.

I'm wondering who the users are that have threat models that make them concerned about attackers able to compromise, say, Google, but not capable enough of getting fake keys out.

This article in particular says fake keys aren't important because the attacker needs access to the mailbox. Well if they don't have access, you don't need encryption in the first place!

Sure, there's a marginal improvement (ignoring all the downsides of encryption, like forgetting your passphrase means losing all data) but it doesn't seem to be useful for actual targeted users.

1. From reading their post, it seems like they made their own REST API for the key server. So it would be nice if they open sourced the service behind it, to alleviate fears of lock in.

2. You're right, it probably should be SRV.

TXT is much more available in DNS management interfaces than SRV, so there's a higher chance that you can install such a server on those shared hosting instances.

vCard (to my knowledge) doesn't have anyway of validating the integrity of the card data so can be altered without knowledge. You would at least need to add some kind of wrapper so that you could add a signed checksum.

Nice!

They're looking at key security features that mitigate attacks and saying "That's a corner case, ignore it".

From a UX perspective, that's great. It lets you simplify and remove a lot of complexity. The catch is that every attack scenario is a corner case. As a result, users get exposed to many of the same vulnerabilities that the technology is supposed to be enabling them to guard against.

There's nothing novel - or, I submit, interesting - about the idea of trading off security to make things slicker for the user.

When the attitude is to dismiss every "corner case" that arises, suddenly you find yourself not doing any security work. After all, every attack is a corner case. 99% of users will never be attacked. Why spend all this energy on things most users will never need?

Then just require TLS on SMTP. Bam, no more dragnet, zero inconvenience to users. And, no problems with spam filtering or data recovery either.

Great to hear! Thanks! Do you know if you are using the SKS keyserver gossip implementation or did you roll your own?