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

one private key, many unique public keys #7

Open
this-oliver opened this issue Mar 22, 2023 · 0 comments
Open

one private key, many unique public keys #7

this-oliver opened this issue Mar 22, 2023 · 0 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@this-oliver
Copy link
Member

this-oliver commented Mar 22, 2023

As things stand, ssasy only generates one public key for every private key. This raises some concerns from a privacy perspective because users can be tracked by their public key - hence they are no longer anonymous on the internet. A practical example could be aggregating a user's behavior by colluding with other services that have also registered the same public key.

option A

One solution to this problem would be to create a new key pair for every service that you considered sensitive. This solves the privacy problem because it no longer becomes feasible to track a user unless you get all the services that they use to disclose the user's public key. Assuming that the services require personally identifiable information when registering users.

So far so good. However, there are some trade-offs that must be considered. First of all, this solution is tedious because your key management scales up with the number of sensitive services that you use.

This also means that you are more likely to get things wrong because the effort that you invested in securing one key will be divided for as many keys as you create. When this occurs, you eventually make mistakes (e.g. storing keys like people store passwords on post-it note).

option B

Another solution would be to create a new and unique public key for every service that you created. This public key should still be tied to your private key, meaning that you are able to perform cryptographic operations as though it was your original public key (that came with the private key).

Unlike option A, the number of keys that you have to manage remains at ONE even when the number of services grows.

@this-oliver this-oliver added the question Further information is requested label Mar 22, 2023
@this-oliver this-oliver added the enhancement New feature or request label Sep 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
Status: No status
Development

No branches or pull requests

1 participant