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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: