Keybase, the company that asks you to upload your private keys to their servers, has just been acquired by Zoom, an essentially Chinese company notorious for having terrible concepts on how encryption should be implemented.
Even if you gave Keybase the benefit of the doubt beforehand, this is corporate suicide at it's most graphic. Delete your Keybase keys. Close your account. Rotate everything that Keybase touched, be that password or cryptomaterial.
π³π±
@kline They only have access to my public keys. They give an option for you to retain your own private key. In this configuration it is perfectly safe and provides a useful service to retain it.
Not happy with zoom aquiring them but until it poses a security risk or until an alternative comes online its usefulness will cause me to continue to keep my account.
@kline That protection is done the same way it is done with any compromised key. If the issuer happened to give keybase their private key at some point then it is expected that now that the user knows their key is compromised that they revoke their key. Just as you would expect if the key was stolen through other means.
Using a persons key means you trust the user is responsible with the security of their key. If you trust someone handles their private key securely then you can also trust their identity on keybase is secure. If you do not trust they handle their key securely (dont give out their private key) then you can't trust their identity anywhere, not just keybase.
@freemo for me, a pubkey being in keybase is something I now consider irresponsible.
Until now, you could balance it and give them the benefit of the doubt, but now that balance is thoroughly disrupted.
An encryption enthusiast might have considered it worth the risk, assuming the benefit of the doubt, but I think that it's no longer safe to do so, even if there are second-class modes in which keybase can be used less-unsafely.
@kline That makes no sense to me. There is nothing remotely unsafe on any level about a public key being in keybase. They are public by their very nature, keybase has access to your public key whether you want it to be or not.
We arent talking about a less-unsafely mode, we are talking about a 100% secure and safe mode. There is no risk of any kind in distributing a public key and even if you dont distribute it explicitly it is publicly accessable anyway.
@freemo If I see that someone's pubkey is in keybase, how can I verify that their privkey is not?
@ignaloidas @freemo if you take a sample of 1000 people who like and use keybase, and a sample of 1000 people who dislike and don't use keybase, there will be a much higher number of people in the first group that have handled their privkeys dangerously than in the second group.
You can't be 100% sure that any individual from either group has secure privkeys, but I no longer consider the elevated risk in the keybase group acceptable.
@ignaloidas @freemo fine, but that's a risk people can choose to take or not.
I've said why I think people should rotate anything - passwords or crypto - that has been in it and consider their account there. If your response is simply "I think that risk is acceptable", that's ok too, but it's not a position I can endorse.
That would only be valid reasoning if random selection is specifically and exclusively pulled from keybase.
If you randomly pick someone from keybase then yes its reasonable to assume they may not know cryptography security very well.
However if you randomly select someone from, say a cryptography convention and they just happen to have a keybase account they would be no more likely to have a compromised key than someone without a keybase account.
A big reason for that would be that there are likely tons of throwaway and junk accounts on keybase that dont represent real professionals using pgp in any serious way.
@freemo @ignaloidas even if you exclude throwaway and junk accounts and go with only people who use it on a regular basis, the risk is still elevated past what I will accept.
Even in that case what I stated is still true. If you met the person outside of keybase then there is no elevated risk of any kind
Your logic is flawed you assume random selection of a high risk group implies that a person it is high risk if they are part of that group even when you havent randomly selected directly from the group in the first place.
A failure to understand how statistical reasoning works on your part.
But to eat their own, your allowed to be wrong :)
@freemo @ignaloidas there are some people I absolutely trust to have not uploaded their private keys, but as a rule I'm not doing it any more.
As a general rule you shouldnt trust anyone's key is secure unless you know them well enough to know it is. You should have been skeptical long before keybase even existed
@kline Lets rephrase that more generally.
How do I know bob's private key hasn't been compromised?
The answer is, you dont, you never did. So that concern is hardly unique to keybase.
They dont do it "unencrypted" but i can attest that giving them your private key so they can encrypt things for you server side is an option. Though you also have the choice to not upload the private key which means you can still do all the same operations but the commands are a bit more complicated, so people are sometimes compelled to give them your private key instead.
You will see the option if you try to setup a new account or new key.
@erAck @freemo in the past, they used to request you upload your private and public keys so that you could both decrypt and sign messages in the browser.
This was during the pgp-model days. Most of the documentation has been wiped as it's no longer the dominant model, but lots of privatekey material will still exist.
I was using the term encrypt rather loosely (and yes even incorrectly)... they us it to sign and decrypt if you want to get technical.
Either way your arguing about a point that isnt in debate. You can go to the site yourself and easily see the option to upload your private key on signup if you wish.
They could have changed it maybe if your saying you didnt see it. But when I signed up providing your private key was certainly an option.
@erAck just as a reminder: you could get access to these encrypted keys from any computer, so the means to decrypt it were held centrally.
So a state actor sufficient leverage could say "you are to decrypt the private key and send it to us".
The US could do that, but you can at least argue with such demands. Lavabit fought them in court and decided to shut down rather than give up the data. This isn't an option in China.
@kline
That's an argument I can follow.
However, a person that could be affected by state actors shouldn't (and probably would not) had uploaded a secret key, and "they" could always seize their equipment anyway in countries where there are no options.
@erAck anyone could be affected by state actors. It doesn't happen until it happens.
The issue is that the encryption relied on trust that the server side wont store your password and decrypt it without your permission, just as you trust a website you use wont store your password plain text.
Since the entire system is proprietary that just doubles the concern.
so trust is very much an issue should you happen to have uploaded your private key.
If you really need proof here is a github issue pointing out the private key upload:
https://github.com/keybase/keybase-issues/issues/160
Here is an article discussing it:
https://blog.filippo.io/on-keybase-dot-io-and-encrypted-private-key-sharing/
@freemo there's no way for other users to identify if they have anything more than your public key.
I can't communicate with anyone who uses Keybase with a given public as I can't verify ahead of time if they uploaded the private key or not.
It might be safe from your point of view looking out, but not for others looking in.