Could someone explain how the underlying keys are managed for Keybase mobile? I'm guessing as part of sign up you generate a unique key just for your mobile device, and if your mobile device is lost, you'll need to generate a new key? How does this dovetail with your desktop key? Does resetting any active key trigger a re-proof of each your identity services (i.e. Twitter, GitHub, etc.)
They have a blog post of their key model. [0] If you lose your device you shouldn't have to re-prove your identity on all services just any that you proved using that particular key.
First part: if you lose or wipe a phone and want to reprovision, the lost device's private key is GONE. It will not exist in some icloud backup. When you provision your new device, the Keybase app will make fresh keys. To make that device yours, you'll need to either (a) bring together another keybase device, or (b) enter a paper key. When you do that, the old key will sign your newly generated key, and the new key will countersign. The old key will also be used to decrypt and reencrypt access keys for your data, so you can get to your old messages and files. Your data will live on. So even in an extreme example: if you write data in KBFS or send a chat message, provision a new device, and then revoke all your old devices, you'll still have the data on the new device. Assuming at some point you always held at least one of your private keys.
The general rule of thumb here is as long as you don't lose all your devices (and in this sense you can think of a paper key as a device), you won't lose your files in kbfs/chat.
The reason the answer above wasn't 100% correct: the revocation of a device (by another) does not trigger an identity re-proof, even for proofs made by the revoked device. Why? well, the original identity announcement is in a well-ordered signature chain of your announcements, and at the same time you remove it, you also have the power to remove your twitter or other proofs. By choosing not to do that AND leaving up your twitter announcement, it's pretty clear you're still you. This isn't like PGP where revocations and statements are floating around and could be ordered in any-which-way.
1. key X adds key Y
2. key X adds twitter
3. key Y revokes X (leaving twitter proof)
the twitter proof is considered still valid in Keybase's logic. Because 1,2,3 exist in a signed chain and Y had the power to remove twitter but chose not to.
One final point we've made in multiple places: your PGP key is part of your identity on Keybase (like your Twitter account or HN account), but it isn't used as a key in Keybase chat or the filesystem for a variety of reasons. So really, your Keybase-data is protected by your devices+paper keys. Just don't run out of them!
Re the final point: Was it like this from the beginning? I still have some identities signed by my original PGP key with which I signed up to Keybase https://keybase.io/azag0/graph
yes, but to be clear: an identity proven by your PGP key is still considered "you" for chat/KBFS, as your device keys have transitively said that PGP key is you. So (1) PGP proved twitter (or whatever), then (2) PGP signed in a device key (which counter-signed), and therefore (3) device key can read KBFS/chat that is sent to you by your Twitter name.
Can I confirm my understanding? In my graph https://keybase.io/nickrw/graph if I lost the key "panya" I would still be able to use either of my other two device keys to add another device, even though they are child nodes?
Looks very cool overall!