2 ms·
From the beginning of Keybase, we considered this specific user flow very important. (1) if there's no one on keybase who matches your "assertion", say a certa
by malgorithms 9y ago
From the beginning of Keybase, we considered this specific user flow very important.
(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