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

Derive all server secrets from a common string instead of the VRF private key #184

Closed
kevinlewi opened this issue Mar 17, 2022 · 1 comment

Comments

@kevinlewi
Copy link
Contributor

In #123, we need to introduce a "commitment key", which is similar to the VRF private key in that the server needs to store it somewhere and keep it secure.

However, instead of introducing another kind of storage for this, I think it would be better to slightly generalize how we are doing the VRF private key storage at the moment. Right now, we store the VRF private key somewhere, but ideally we would actually store a "ServerSecret" 32-byte string, from which the VRF private key could be derived (say, by hashing this server secret string along with a nonce), and from which a "commitment key" that I want to introduce will also be derived from that same server secret string. Any future server-only secrets could also be derived from this string, without having to change the storage layer.

At the moment, the commitment key is derived directly from the VRF private key for now -- this should be fixed.

@kevinlewi
Copy link
Contributor Author

Honestly, hashing the VRF private key to get the commitment key is OK, and in some ways simpler.

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

1 participant