5 ms·

Wait, what? People gave Keybase their private keys?? Isn't keybase just some glorified modernized web of trust infrastructure?

by gspr 7y ago

coldpie 7y ago
It was well-intentioned. For a time, Keybase provided users the option to upload their private keys so they didn't have to maintain them themselves. You could just log into Keybase and send signed messages, decrypt messages, etc without the hassle of managing your keys locally. It was definitely a bad idea and I think they dropped it a few months/years later, but it at least wasn't totally out of left field.
- bamboozled 7y ago
  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. This feature saved my skin on one occasion.
  - coldpie 7y ago
    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.
    - minitech 7y ago
      > a private key encrypted with a password is not cryptographically different from a plaintext private key It is different. Keybase could update the app to steal your key, but that’s a visible attack that can’t be done retroactively. > If it was truly secure, then you'd be using a new private key to encrypt your real private key There’s no reason to use asymmetric crypto for symmetric encryption.
    - dcow 7y ago
      I didn't downvote. Here are my thoughts. > 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.
      - chaps 6y ago
        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.
      - orblivion 6y ago
        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.
  - floatboth 7y ago
    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!
    - namibj 6y ago
      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.
dcow 7y ago
No, they didn't. There is an option to have Keybase sync a [backup] copy of your private key(s) between your devices for you but the key is encrypted by you. And, none of their stuff like chat or git etc. depends on using/accessing those keys in anyway (they built out their own domain-applicable pki for that—in other words, chat doesn't use pgp). It’s just a convenience option for those who want it and it’s not the default.

Wait, what? People gave Keybase their private keys?? Isn't keybase just some glorified modernized web of trust infrastructure?

by gspr 7y ago

Wait, what? People gave Keybase their private keys?? Isn't keybase just some glorified modernized web of trust infrastructure?

coldpie 7y ago

It was well-intentioned. For a time, Keybase provided users the option to upload their private keys so they didn't have to maintain them themselves. You could just log into Keybase and send signed messages, decrypt messages, etc without the hassle of managing your keys locally. It was definitely a bad idea and I think they dropped it a few months/years later, but it at least wasn't totally out of left field.

bamboozled 7y ago
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. This feature saved my skin on one occasion.
- coldpie 7y ago
  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.
  - minitech 7y ago
    > a private key encrypted with a password is not cryptographically different from a plaintext private key It is different. Keybase could update the app to steal your key, but that’s a visible attack that can’t be done retroactively. > If it was truly secure, then you'd be using a new private key to encrypt your real private key There’s no reason to use asymmetric crypto for symmetric encryption.
  - dcow 7y ago
    I didn't downvote. Here are my thoughts. > 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.
    - chaps 6y ago
      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.
    - orblivion 6y ago
      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.
- floatboth 7y ago
  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!
  - namibj 6y ago
    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.

dcow 7y ago

No, they didn't. There is an option to have Keybase sync a [backup] copy of your private key(s) between your devices for you but the key is encrypted by you. And, none of their stuff like chat or git etc. depends on using/accessing those keys in anyway (they built out their own domain-applicable pki for that—in other words, chat doesn't use pgp). It’s just a convenience option for those who want it and it’s not the default.