They don't have access to your unencrypted private key, it's just a backup of your private key which is encrypted by (hopefully) a very strong password.
Well, you still have to trust them not to ship a website update where the client side scripts would leak your decrypted private key :)
To be fair, you also have to trust native apps and browser extensions the same way. But with websites, the risk of a sudden and targeted (not noticed by the general public) update is much greater!
Which is why they push you towards not using the website, and also explain how they (through some steps) put their application version's hashes into the bitcoin blockchain.
And the client is open source, which iirc includes being built by distribution's maintainers/build servers instead of Keybase.io.
I believe the argument is that a private key encrypted with a password is not cryptographically different from a plaintext private key. The password is more of a "keeping honest people honest" kind of thing, than true security. If it was truly secure, then you'd be using a new private key to encrypt your real private key, and then you're back to where you started. Cryptography is hard, which is why I was such a big fan of Keybase trying to fix it for real people :)
Edit: This has a received a few downvotes. If I'm wrong here, I'd really like to know why! I thought this explanation was correct and clear.
> I believe the argument is that a private key encrypted with a password is not cryptographically different from a plaintext private key.
You have it backwards. On principle an encrypted anything (key in this case) is of zero value to anyone. It does’t matter if you tweet encrypted messages every 30 seconds to millions of followers or not: they're encrypted.
When you use a password to encrypt, and you (or your client/agent) selects an appropriately sophisticated suite, you end up seeding a KDF with your password and then using the resulting data as the actual “private key” (its just a symmetric key, no public/private). If your password has enough entropy, then the resulting key is perfectly secure.
In practice people are paranoid. “If the key is on Keybase’s servers, someone could get it and brute force decrypt it.” It’s almost pop culture fallacious, though, because if you believe someone can do that, then they can just as easily brute force the actual key. In practice people use shitty passwords, and crypto weakens as time moves forward, there are good and bad algorithms, and the whole point of a public key infrastructure is to keep private keys off the wire. So it’s generally seen as bad form to copy private keys around, even if they're encrypted. We’re still pretty far on the spectrum here because if your crypto breaks you have to rey key everything anyway. Not just re-encrypt unchanged private keys.
At the end of the day you're either copying a private key around or you aren't. And you should probably avoid situations where you need to do that because there are better ways to PKI. If your threat model can tolerate encrypted key backups and key sharing, then go for it. But that should be something you control.
If people have bad passwords, that makes brute force recovery of the private key on a Keybase server plausible, right? At least a lot more so than the whole key from scratch. I'd assume that a machine generated key has more entropy than any password that a human can memorize.
If sharing a password-protected private key is perfectly safe, why bother having them? Why don't PGP users just password protect everything?
Above all else though, is there an authoritative source that can answer these questions? As a run-of-the-mill programmer, I don't really understand how crypto works well enough to trust my own common sense here. It's been drilled into my head that there are certain rules to follow set out by people who do know what they're doing. And when people say "it's all good, it's password protected", and I'm not sure what their credentials are, I get a little nervous. I did notice that Werner Koch uses Keybase, but if they could simply point to an "okay" from him or Zimmerman explaining the situation, it would be settled. To me anyway, it's not simply an abundance of caution ("paranoia"), it's that something seems fundamentally wrong with the approach and I just don't know the actual cost.
I think people are confusing things a bit here. Sure, you can protect your pgp key with a password, but I don't think that adds a whole lot of security to your uploaded private keys. When you upload a pgp key to keybase, it encrypts the key again, using your keybase device key. So its double encrypted, basically.
The keybase model revolves around devices. Device keys are private keys that are tied to a particular device (your phone, pc, etc) and never leave that device (unless it gets compromised somehow). The only way you can decrypt your data on another device is by registering it using another authenticated device. These keys don't have passwords.
Its basically like encrypting a pgp key with another pgp key, and uploading it somewhere, like people upload all manner of secrets to github or s3 or whatever.
Keybase just provides an easier flow to register new devices and to import and decrypt your secrets (like via a QR code scanned by your phone, for example). Your private keys are as secure as any private, encrypted piece of data that you might send out over the wire, so long as your devices are secure, that is.
If one or more of your devices gets owned, all bets are off, AFAIK. Even if you set a passphrase on your pgp key, all it takes is a key-logger to get it. And since your device is already compromised...
This is where hardware keys win out (yubikey, etc), that require a physical touch to unlock.
DISCLAIMER: I really only have a layman's understanding of crypto.
> When you upload a pgp key to keybase, it encrypts the key again, using your keybase device key.
Except that long time ago, when device keys didn't even exist, there was a feature on Keybase website that allowed to upload a PGP private key encrypted only by your account password (which was never transmitted to Keybase in plaintext though – it was scrypted in browser when logging in, too – but this still means your private key was as secure as your password, which isn't a good practice in my opinion).
Thank you. If that's true I wish they would have just said so when people started complaining about it on Github. Everybody seems to have a different take on this.
Assuming what you're saying is correct, it seems much more sensible. It almost makes the PGP key seem superfluous, though I suppose it help with legacy this way.
It still seems not ideal, in that having one device compromised would give away your main private key and thus your whole identity. It would be nice to have it be some sort of subkey situation. I'd have to think about how that would work.
>It almost makes the PGP key seem superfluous, though I suppose it help with legacy this way.
This is actually one of the best "features" of keybase. They've backed everything by some strong pgp crypto roots, but none of their stuff really "operates" using pgp. The fact that they have abstracted it, in my opinion, is part of why people have adopted it so easily.
At the end of the day, your keybase device key is, itself, simply encrypted with your keybase password. The point I've been trying to make clear is:
> Your private keys are as secure as any private, encrypted piece of data that you might send out over the wire, so long as your devices are secure, that is.
> If sharing a password-protected private key is perfectly safe, why bother having them? Why don't PGP users just password protect everything?
What’s “sharing” here? You “share” an encrypted private key with Keybase so you yourself can recover it back from anywhere using the password that you know. PGP, meanwhile, is used for communication with people who are not you.
> If people have bad passwords, that makes brute force recovery of the private key on a Keybase server plausible, right? At least a lot more so than the whole key from scratch.
Yes. If you want to upload an encrypted copy of your key to someone you wouldn’t trust with the key, you should use a strong password.
> I'd assume that a machine generated key has more entropy than any password that a human can memorize.
That’s not a correct assumption, but your password doesn’t have to be more complex than the key to be safe against brute force anyway, especially when work is added with scrypt (which is what Keybase uses).
Hmmmm... so wouldn't you agree that a percentage of keys would be decryptable by iterating over all encrypted files of all accounts using password dumps? Seems like a good way to decrypt maybe 10%. Still sounds like a major problem, though.. not at the individual level, but at the systems level.
This feature saved my skin on one occasion.