Official Keybase extension for Chrome

We've been experimenting with a bunch of different ideas and features—most of them you can enable/disable in the extension's "options". We launched a Reddit-focused extension last month but this release embraces all of the social networks that we support.

I'll be writing up a blog post soon, particularly about how we use the WebExtension NativeMessaging API to communicate securely with the Keybase service.

c.f.: https://keybase.io/docs/kbfs

  Soon, you'll be able to throw data into /keybase/private/yourname,pal@twitter,
  even if that Twitter user hasn't joined Keybase yet.
  Your app will encrypt just for you and then awake and
  rekey in the background when that Twitter user joins
  and announces a key.

We give a little bit of detail here: https://keybase.io/docs/kbfs#frictionless-sharing

But the basic model is that when you share or chat with someone@twitter, that content is only encrypted to your devices. When that Twitter account posts a proof, and announces that proof on a Keybase account, Keybase's servers will notify your devices including a link to the tweet. Your device will independently verify that the cryptographic proof is validated by the keys of the Keybase account claiming it, after which it'll re-encrypt the keys to that data for the newly verified Keybase account.

This all happens seamlessly in the background.

(1) if there's no one on keybase who matches your "assertion", say a certain twitter account or HN account or whatever,

(2) the keybase app encrypts it just for yourself, but signs a message (for yourself) declaring the assertion

(3) when someone proves that assertion publicly, by joining keybase and connecting an account, they are announcing and proving ownership of key(s), and proving publicly they have control of that account and keys

(4) the keybase server wakes up your app and tells it to verify your assertion is now satisfied, and

(5) your app checks the announcement by actually visiting Twitter and then, if the crypto is good, rekeys the data - there's nothing for you to do other than to have the app running, since the human steps were already done back when you made the assertion by writing the message.

Depending on how loosely you use the term, this is a type of TOFU (trust on first use): you're trusting that the assertion provider, say, Twitter, doesn't steal an account out from underneath one of its users, or the user doesn't lose control of her/his account. Note that this would be publicly discoverable because all announcements are written publicly to Keybase's merkle tree.

This is just about the best imaginable key establishment we can think of without meeting in person. It's certainly better better than, say, trusting a key service to map a phone number to a public key. And it's safer than posting PGP fingerprints or public keys on Twitter - in that case there's no way to tell if everyone else is getting the same answer as you.

edit: formatting