Docs > Server security >

Understanding following (previously called "tracking")

We get some big questions about Keybase following:

  • When should I follow?
  • What does it get me?
  • Is it a "web of trust?"

Hopefully this page can clarify and answer your q's.

But first, the goal of Keybase

Keybase aims to provide public keys that can be trusted without any backchannel communication. If you need someone's public key, you should be able to get it, and know it's the right one, without talking to them in person.

This is a daunting proposition: servers can be hacked or coerced into lying about a key. So when you run a Keybase client - whether it's our reference client or someone else's - that client needs to be highly skeptical about what the server says.

When the Keybase server replies "this is twitter user @maria2929's public key", there has to be a protocol for verification.

Therefore, any cryptographic action on Maria follows 3 basic steps:

  1. The server provides maria's info
  2. Your client verifies her identity proofs on its own
  3. You perform a human review of her usernames

Let's go over these three steps.

Step 1: the request

When you wish to encrypt a message for your friend Maria, you might execute a command like this:

keybase encrypt maria -m "grab a beer tonight?"

So, first, your client asks the Keybase server who this mysterious maria is.

Keybase, the server, provides a response that explains its view of "maria". Technically speaking, it's a JSON object and there's a little more data in there, but the meat is something like this:

  "keybase_username": "maria",
  "public_key":       "---- BEGIN PGP PUBLIC KEY...",
  "twitter_username": "@maria2929",
  "twitter_proof":    ""

Keybase has done its own server-side verification of maria, and it won't pass back identities that it hasn't checked.

Step 2: the computer review

The keybase client does not trust the Keybase server. The server has just claimed that keybase:maria and @maria2929 are the same person. But are they? In step 2, the client checks on its own.

Fortunately, the server included a link to maria's tweet. The Keybase client scrapes it.

To satisfy the client, the tweet must be special. It must link to a signed statement which claims to be from maria on Keybase.

In simplest terms, the Keybase client guarantees that "maria" has access to three things: (1) the Keybase account, (2) the twitter account, and (3) the private key referenced back in step 1.

All this happens really fast in the client with no inconvenience to you. And it happens for all of maria's identities: her twitter account, her personal website, her github account, etc.

Step 3: the human review

Recall, in Step 2 your client proved "maria" has a number of identities, and it cryptographically verified all of them. Now you can review the usernames it verified, to determine if it's the maria you wanted.

maria2929 on twitter:
✔ pasc4l_programmer on github:
✔ admin of via HTTPS: https://mariah20/keybase.tx...

Is this the maria you wanted? [y/N]

If it is, the Keybase client encrypts and you're done.

Finally: following

Steps 2 and 3 were easy enough, but it would stink to keep repeating them, every time you switched computers. Especially the human review. Ideally, once you're satisfied with maria, you can just do this from any computer:

# this should work with no interactivity
keybase encrypt maria -m "another beer?"

But we have a problem: recall, you don't trust the Keybase server. So how can you get maria's info when you switch machines, without doing that username review thing again? The answer is following.

"Following" (which we used to call "tracking") is taking a signed snapshot.

Using your own private key, you can sign a snapshot of her identity. Specifically, you're signing the data from step 1, with some extra info about your own review.

When you switch computers, the Keybase server can provide you with your own definition of maria, which is signed by you, so it can't be tampered with.

Your client can continue to perform the computer review as often as it wants. If the tweet disappears, your client will want to know.

The advantages of public following

When Maria is followed by 100 people, and they've all signed identical snapshots to yours, this is helpful.

If some of these statements are months old, but your own is only 1 day old, you can get some peace of mind that her identity was not compromised today, the day you decided to follow her.

This is not a web of trust. You can prove maria's identity, even if there are no other followers. But more followers means more confidence in the age of her account.

Why follow now?

As hinted above, an older follower statement is superior to a new one. It's hard for a hacker to maintain a public compromise of all of maria's accounts over a span of many months. Maria or maria's friends would surely notice.

By comparison, if you started following Maria right now, today could've been the day all her accounts were broken into, simultaneously.

Therefore, an older follower statement is a better one.

A gentle conclusion: if you find someone interesting on Keybase - say you know them, or you like to read things they write, or they're a software developer who might sign code - following them now makes sense. This will begin a long and auditable history of following their identity.

We hope this doc helps. We'll revise it as questions/suggestions arrive in our github issue #100 (I don't understand tracking).

footnote 1: the PGP web of trust

In the web of trust model, you know you have Maria's key because you trust John, and John signed a statement saying that another key belongs to his friend "Carla", and then Carla in turn signed a statement saying that Maria is someone whose drivers license and key fingerprint she reviewed at a party. Your trust of Maria's key is a function of these such connections.

you → john → carla → maria
you → herkimer → carla → maria

The PGP web of trust has existed for over 20 years. However it is very difficult to use, it requires in-person verifications, and it's hard to know what trust level to assign transitively. (Herkimer reports that Carla was drunk; John can't remember, but he was drunk too, and who's Carla again???)