General Keybase question:
How is it possible to (1) send a message to someone before they've signed up and (2) prevent Keybase from being able to decrypt the message? This is a surprising capability. Didn't realize it was possible. I'm curious how.
How is it possible to (1) send a message to someone before they've signed up and (2) prevent Keybase from being able to decrypt the message? This is a surprising capability. Didn't realize it was possible. I'm curious how.
(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
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.
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.