Documentation request: a precise outline of what we trust keybase with

[copumpkin]

I think it'd be valuable to explain precisely what users are trusting keybase to do and not to do, and what a malicious/compromised keybase could leak.

Things like:

• "We could be associating IP addresses with valid signatures from your keys; you'll have to take our word that we don't." [or perhaps you do? in which case it's good to know]
• "We could be serving up malicious code that harvests your client-side passcode and decrypts our server-side private key. Our server could be compromised and do that without us even wanting to. Here are the security measures we have in place to avoid that"

I think being forthcoming about things like that will help gain traction in a security-minded community, and might also help highlight holes that you haven't thought of.

[maxtaco]

You are of course entirely correct. We have been slammed though and haven't found time to do so yet.

In a nutshell:

• We don't log IP addresses to our db but have standard http access logs which could be used to associate the first lines of http requests with IPs; these logs are useful for debugging but we plan to instate a data retention policy to delete these logs after a day or so; but users will always have to take our word on this, or a 3rd party auditing firm.
• We store scrypt hash output of user passwords on the server for all users and triplesec'ed secret keys (secured with the user's password) for those who choose to host their secret keys on the server;
  • These users trust our servers to only show encrypted private keys to their owners
• users trust the server to carry out password changes on resets:
  • A password change is only possible if the user can prove he/she knows the previous password
  • A password reset is possible by clicking on a certified link sent to the user's email address, but deletes the user's private key from the servers; users need to trust us that we've implemented this properly.
• At present, we develop and maintain the JavaScript web client and the NodeJs command line client, and are therefore trusted to not divulge secret data, like raw passwords, password hashes, encrypted secret keys, and secret keys.
• We plan to allow third parties to write their own clients; the protocol to the server can be backwards-engineered as is, but it's also documented in rough form and we plan to improve the documentation.
• Our current command-line client reads and modifies the user's primary PGP keyring.
• Our current command-line client installer reads and modifies a secondary PGP keyring stored in the user's home directory.
• Clients rely on the server to store and present public hash chains for each user. Each link of the hash chain is a signature such as "this is my username on twitter" or "I'm tracking Joe". Each link also contains the content hash of the previous link. Clients sign the tail of the chain on behalf of users. Thus, the server can only withhold links at the end of the chain without being caught; clients who cache hash links (such as our Node client) can catch the server withholding tail links.
• Clients rely on the server to store the body of Twitter signatures (and other character-constrained services in the future), but can independently verify that the hash of the tweet matches the value stored on the server, and that the value stored on the server is a valid hash link. A malicious server could refuse to present the body of the signature to the client.
• Our current command-line client only grabs tracking data for users you are interested in; therefore, and adversary who can snoop on a client's TLS connection with the server, or has access to server access logs, can infer which users a given user wants to communicate with.
• The current command-line client communicates with the server at api.keybase.io:443. We have our own certificate authority (that's not verified by the root CAs), and distribute the CA along with the client code. In this sense, the command line client does not trust the root CAs to achieve a TLS connection with the server. But to bootstrap the whole thing, we are trusting the root CAs for the initial install of keybase-installer.
• An adversary who MiTMs the client's connection with the server can act like a malicious server, so can withhold information from the client, infer who the user is interested in communicating with, and suppress writes from the client. He shouldn't be able to fake signatures, decrypt secret data, or get access to the user's unencrypted secret key or plaintext password.
• See this document for more information about the assumptions our command-line client software installer makes.

[tildelowengrimm]

That summary is interesting, but I think that what we really need is a threat model explaining the attacks that keybase does and doesn't protect against. For instance, nothing I've read explains why we need Keybase to run the identity server, or to make accounts.

[This may be offtopic for this issue, but it feels more productive to discuss it here than crate a new issue for it. If I'm mistaken, then I'll make a new issue.]