Doomsday scenarios and their effect on keybase?

[haasn]

Again, apologies if this is a duplicate issue but a quick search picked up nothing obviously relevant.

I'm wondering whether you could clarify, perhaps in https://keybase.io/docs/server_security and the related documents (e.g. a list such as https://en.bitcoin.it/wiki/Weaknesses) about what exactly would happen to keybase under a certain number of possible future scenarios ranging from benign to “doomsday” in nature.

For example, here are some questions I'm concerned with and how them occurring would affect keybase as a software, a service and a concept (respectively):

• The bitcoin block chain breaks down (bitcoin loses its value, blockchain easy to fork). I imagine in this scenario, keybase could simply “migrate” to publishing its authenticity proofs in a different relevant blockchain instead, if possible.
• The keybase server becomes defunct. Is it possible for the community to host a replacement? Is it possible for the keybase software to work with alternative hosts? Is the server software open source? Is it possible to move towards a decentralized server system? (Perhaps relying on a blockchain for synchronization)
• The crypto behind keybase breaks down, e.g. RSA broken. We'd potentially need to mass-migrate GPG keys. How well would that work? What kind of effects could an attacker capable of breaking RSA wreak on keybase? What about an attacker with only read-only access? (Keeping in mind RSA almost surely will be broken within our lifetimes due to the advent of quantum computers alone)
• keybase.io website goes missing. Is it possible to host my own version of the keybase.io front-end website? Is all the code publicly available?

And probably more that I'm not thinking of right now. I can see from https://keybase.io/docs/server_security that keybase is applying a strong design of distrusting the central server, and I think this is a very healthy design choice. But I'm still wondering about what the real-world ramifications of a dead server would be, since as I understand it keybase still relies on a central API and reference point.

[haasn]

Another scenario I'm interested in:

Suppose somebody roots the keybase.io server. As I understand it, there is a special key stored on the keybase.io server itself which can be decrypted using my passphrase.

Now as I understand it, to login on keybase.io I have to provide my passphrase via HTTPS to the server, right? So if keybase.io intercepts my passphrase and then gets my encrypted key from the database, an attacker could use that key to revoke all of my devices and then perform a complete takeover of my account.

What security measures does keybase have against this? Two I can think of:

1. Make is so the user can disable the central key on keybase.io completely. (This would be my preferred choice. I can rely on my devices and paper keys, and I can use the client program locally - so why should I need to use the web service at all?)
2. Pick a strong passphrase and then simply never log in to the keybase.io client. (This seems reasonably secure, but I still don't have any guarantees that keybase.io never intercepted my passphrase in the traffic - plus, some features e.g. invites are simply not available except via the web interface)
3. Handle all crypto client-side (e.g. JavaScript). This better approximates the device-based model of the CLI: Every key is kept away from the central point of failure. (I don't think this is being done already, or is it?)

Either way, keybase needs to be designed to permit failure or malicious takeover of keybase.io.