Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is Keybase liable to Censorship? #11102

Open
balupton opened this issue Mar 27, 2018 · 10 comments
Open

Is Keybase liable to Censorship? #11102

balupton opened this issue Mar 27, 2018 · 10 comments

Comments

@balupton
Copy link

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
Copy link
Contributor

strib commented Mar 27, 2018

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
Copy link

junderw commented Mar 28, 2018

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:

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

@strib is my assessment correct here?

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

@strib
Copy link
Contributor

strib commented Mar 28, 2018

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
Copy link
Contributor

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
Copy link

junderw commented Mar 21, 2019

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
Copy link

junderw commented Mar 21, 2019

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
Copy link

phoolish commented May 28, 2019

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
Copy link

@strib #11102 (comment)

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
Copy link
Author

Happy for this to be closed with answer as:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants
@balupton @phoolish @eli-schwartz @strib @junderw @Hattshire and others