You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
As things stand,
ssasy
only generates one public key for every private key. This raises some concerns from aprivacy
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.
The text was updated successfully, but these errors were encountered: