keybase / client

Keybase Go Library, Client, Service, OS X, iOS, Android, Electron
BSD 3-Clause "New" or "Revised" License
8.85k stars 1.22k forks source link

Is Keybase liable to Censorship? #11102

Open balupton opened 6 years ago

balupton commented 6 years ago

What happens when a user is hosting a keybase encrypted git repository that a particular government or company does not like? Is Keybase able to be compelled to remove the git repo, the kbfs files, and the user from their system? Or is the only person who can remove content the creator?

strib commented 6 years ago

Keybase can disable accounts and/or block file/git access to a particular folder, yes. But, we don't know the names of any of your non-public repos, and neither would any particular companies or governments, so they wouldn't be able to find out through us what is being hosted.

junderw commented 6 years ago

Thing to keep in mind: the usernames for the folders is known by keybase.

ie. Let's say the FBI forces keybase to disclose all active folders. (private/mra,mrb/) Keybase knows mra and mrb have some encrypted blobs in their private folder, and FBI can use that info to corroborate with other sources to assume "ok they are storing the data for their illegal activity on keybase!"

However, if I am reading the code correctly, a team can effectively hide the membership from keybase, so here is my assertion:

@strib is my assessment correct here?

Also, disclaimer: Don't break laws. Don't use Keybase to break laws.

strib commented 6 years ago

However, if I am reading the code correctly, a team can effectively hide the membership from keybase, so here is my assertion:

if you need to share files using git/kbfs, create a team rather than a collective private folder. It leaks less info to Keybase.

No, I don't think this is true. Your team membership is private to non-team-members who aren't Keybase, but Keybase still needs to know the team membership, so we can avoid even showing the existence of the team to anyone not on the team.

Also, disclaimer: Don't break laws. Don't use Keybase to break laws.

Yes, this, thanks!

eli-schwartz commented 6 years ago

Keybase knows mra and mrb have some encrypted blobs in their private folder, and FBI can use that info to corroborate with other sources to assume "ok they are storing the data for their illegal activity on keybase!"

They could just assume you're up to something illicit due to your use of encryption at all. Depending on which totalitarian governments we're discussing, that might even be true. But I think we're past the point where the US and other nominally fair governments will use the presence of encryption itself as corroborating evidence of misdeeds. If this was a legitimate concern we'd all be in trouble and might as well give up and go home right now.

...

Keybase is a platform for making it easier to encrypt files, the mere fact you have a keybase account implies you're using it somehow. If the encryption is secure and the service does not have a backdoor then I don't see what more there is to worry about.

junderw commented 5 years ago

Keybase is the backdoor.

Sounds cool, unfortunately it's misleading.

"backdoor" in cryptography means "a person with knowledge of the backdoor can decrypt all data and/or create signatures on behalf of someone without prior knowledge of their private key"

Which keybase can not do.

They can hand over metadata though. A is talking with B, C is sharing 500 MB of something with D on kbfs, etc.

No one considers metadata leakage a "backdoor" in a cryptographic sense.

junderw commented 5 years ago

Also denial of service is possible.

Keybase could delete your account and delete all your encrypted data whenever they feel like it.

So a govt. might pressure them to do so.

I agree a federated keybase would better suit the ethos of keybase, but a centralized service keybase better serves any (still unknown) future business models.

ie. If FBI shares evidence with Keybase of a child porn ring on a keybase team, I would hope they shut it down and ban everyone. But obviously keybase could be tricked into banning people, so federated is best imo.

phoolish commented 5 years ago

I've noticed a couple of usernames/profile picture pop into my "Consider Following" feed that seem to imply illicit activities. I am not sure what the next step is. Not trying to hijack this issue, but it was the only one that popped up during my search.

Hattshire commented 4 years ago

@strib https://github.com/keybase/client/issues/11102#issuecomment-376700257

Keybase can [...] block file/git access to a particular folder [...]

Does this means that private file system structure exists in the server as non-user-exclusively encrypted metadata or does it only applies on public-readable file system metadata?


Also, given the answer to the title question is yes, arguments were given, and the question is 2yo without author's(@balupton ) response, should this issue be closed?

balupton commented 4 years ago

Happy for this to be closed with answer as:

If the metadata is known, then keybase can be compelled to pull it.