[messaging] Looking up public keys on public sites (was Re: Keybase Chat)

[Jack O'Connor]

>   (1) Keybase runs a server, so I ask the server to point me at
> Alice's latest tweet

Yes. That saves clients from having to do discovery work, and also
gives us some options if e.g. Twitter changes something about their
URLs. The downside here is that Keybase can pretend that Alice's proof
is missing, though there's a long list of other ways for Keybase to
DOS Alice's account, so we haven't worried about this one in
particular.

>   (2) I'm less clear on this, isn't there some public log where I can
> check that I'm seeing the latest info?

The complete state of Alice's account (keys plus identities) is given
by her signature chain, hosted on Keybase's servers. When you check
Twitter, you're only asking whether the Twitter statement from Alice's
sigchain is still live, rather than learning anything new about Alice
from Twitter. Keybase in turn tries to guarantee that it's hosting the
latest version of everyone's signature chains, by putting them in a
global Merkle tree, and then publishing the root of that tree in the
bitcoin blockchain. Our clients don't currently talk to the blockchain
to verify that, but they might in the future (using simplified payment
verification?).

More detailed docs about signature chains and our Merkle tree:
- https://keybase.io/docs/server_security
- https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain

>   (3) The published statement includes a signature by Alice's key over
> the relevant username

Yes, what gets published is the same signed statement that gets added
to Alice's signature chain, or a hash of that statement when we don't
have space like on Twitter. The statement includes her Keybase
username, her claimed username on the 3rd party site (which has to
match the account posting it), the sequence number and hash of the
previous statement in her sigchain, and the root of the global Merkle
tree that Alice was seeing when she made the signature. (For example,
my signature asserting my Facebook account:
https://keybase.io/oconnor663/sigchain#0e695faa99f64f54a6bbb91c0f2a009cfb5d46ddecf7f9e9e63a892b8f7bfe8c0f)

By asserting her entire sigchain in each identity proof, rather than
just one of her public keys, Alice can have many different keys on her
account without needing 3rd party proofs for each of them. She can
also completely rotate her set of keys, without updating any of her
public proofs. Each new key or revocation is another signature in the
chain, and clients replay the entire chain to check that each new
signature was valid at the time it was made.

>   (4) If this published statement is too large, it can be stored at
> Keybase, and Alice just tweets a hash plus URL.

Yes, clients verifying Alice's Twitter proof will already have loaded
her entire signature chain from Keybase, and so all they need from
Twitter is the hash of the relevant signature. We're pretty strict
right now about how that hash gets presented ("Verifying myself: I
am..."), to make it a little bit harder to trick someone into tweeting
a proof.

The main benefit of all this machinery is the flexibility Alice has to
add and remove keys, that I mentioned above. The "identity misbinding"
attack is nice to prevent, though I agree that looking someone up by
their key fingerprint is pretty rare and not super compelling. I might
be more worried about an attack where Bob steals Alice's private key
somehow, and then he claims that Alice's Facebook account belongs to
him, based on her old proof that only asserts the key that Bob has
stolen.

>From Natanael:

> Without reliable binding using signatures this means that somebody can spoof
> another keybase user from their 3rd party site accounts

Yes, if I understand you right, the two-way assertions in our identity
proofs are important for that reason. Adding a new key to your account
is also a two-way signature, with one of your previously valid keys
and the new key both signing over each other in your sigchain, so for
example you can safely address someone by their PGP fingerprint.

Currently our cryptocurrency assertions are one-way, though. There are
too many different Bitcoin clients for us to support making the
reverse signatures for you (or even to provide decent instructions for
making them).