keybase / keybase/client

Proofs for confidential (hashed) usernames

Open
#7,488 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
9.2k
Forks
1.3k
Avg merge
12h 58m
Merged PRs (30d)
56

Description

Currently, adding a social media account to Keybase creates a two-way link; anyone who knows your social media username can find your Keybase username, and anyone who knows your Keybase username gets a list of all your social media accounts. In fact, once you have added a social media account, it becomes impossible to ever disclaim ownership of it, since the (revoked) proof will remain in your sigchain. This makes it a poor choice to use for private accounts, personal accounts for public figures, etc.

This is, in a way, a similar problem to the issue of NSEC records in DNSSEC leaking zone info in the name of cryptographic proof, and it lends itself to a similar solution: instead of my sigchain containing a signed statement saying "I claim ownership of the github account 'dmchurch'", it could contain a signed statement saying "I claim ownership of the github account with sha256 hash 'd140f4...a12fd4'". Anyone trying to ask the question "Is dmchurch@github on keybase" could find the answer by hashing the username with whatever functions the keybase protocol supports and checking that way, but if someone only had my keybase username, the most they'd get would be "danichurch@keybase claims ownership of a confidential github account".

This could conceivably be taken one step further, changing all social proofs in the sigchain to use hashed usernames, and the Keybase client could publish a "current list of publicized usernames" as a signed statement that exists outside the sigchain, in the same mechanism as KBFS public folders. This way, anyone that ever wants to disassociate themselves with a past username - trans individuals who don't want to out themselves by their former name, victims of abuse and stalking for whom having a past name or identity online can be a physical danger, or even just people who realized a little too late that "ShinjiIkariKissBoy34" is maybe not the right twitter handle for an IT professional - can do so simply by removing that name from the currently-publicized list.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The proposal concerns social proofs in the sigchain and a possible signed list of currently publicized usernames. Start by locating the existing social-proof and sigchain entry points; define how hashed usernames, verification, revocation, and disclosure would work before implementation. Done would require an agreed protocol design and corresponding tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cryptography, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.