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
The epoch mechanism requires that new issuance parameters be generated for every epoch. These issuance parameters may need some number of secret bytes, but since we can symmetrically expand a short secret into as much data as we need, we only have to consider how we generate a secret seed for each epoch.
Loss of key material means loss of availability, since all existing credentials can no longer be verified. Compromise of key material means credentials can be forged.
Forward security for issuance secrets requires that we have additional random inputs, but this cuts against ease of maintaining availability, since if there was no forward secrecy, all keys could be derived from a single seed that can be backed up by the issuer.
For now, deriving all keys from a single seed is the easiest thing to do.
Note: because this is the key schedule for the issuer's side, it's all hidden from the client anyways, so it can be changed later without breaking anything (though doing so in an existing deployment would be awkward / horrible).
The text was updated successfully, but these errors were encountered:
Very rough notes:
The epoch mechanism requires that new issuance parameters be generated for every epoch. These issuance parameters may need some number of secret bytes, but since we can symmetrically expand a short secret into as much data as we need, we only have to consider how we generate a secret seed for each epoch.
Loss of key material means loss of availability, since all existing credentials can no longer be verified. Compromise of key material means credentials can be forged.
Forward security for issuance secrets requires that we have additional random inputs, but this cuts against ease of maintaining availability, since if there was no forward secrecy, all keys could be derived from a single seed that can be backed up by the issuer.
For now, deriving all keys from a single seed is the easiest thing to do.
Note: because this is the key schedule for the issuer's side, it's all hidden from the client anyways, so it can be changed later without breaking anything (though doing so in an existing deployment would be awkward / horrible).
The text was updated successfully, but these errors were encountered: