Deterministic Signatures with Key Rotation
Deterministic Signatures are used to identify versions. As the name suggests, two signatures with the same key and of the same value should result in the same signature. However, it is not required that there is only one possible valid signature, just that there is a convention of creating the same signature.
The signed data is fed into the signer/verifier like a SHO, and most schemes will use a SHO internally. This allows for signatures to be verified on a summary as well as on a complete input.
In addition to strong existential unforgeability of messages and signatures for a given public key, we require existential unforgeability of messages and public keys for a given signature. This prevents forging a version with a particular signature.
Operations
-
Initialize(domain): Creates the signer-verifier. Passing in a different domain will result in a different signature. -
Clone(): duplicates the signer-verifier. -
Feed(input): This inserts data into the signer-verifier. -
Extract(): Extract a summary of the current input. -
Inject(state): Creates a signer-verifier from the extracted state. -
Demarc(): Creates an out-of-band demarcation point in the input stream, such that no possible input can collide with it. This must be equivalent toExtractfollowed byInject. -
Sign(secret_key, public_key): Create a signature using the given secret key for a particular public key. Typically, the public key will be the one corresponding to the secret key, but a wrapped threshold scheme may target a different public key. -
Verify(public_key, signature): Check the current input against a public key and signature. -
Derive(master_key, rotation_key): Derive a secret key and a commitment, from a master key and a public rotation key.
Serialization
Signatures are serialized with a 1 tag followed by the serialization of the contained signature. Public Keys are serialized with a 2 tag followed by the serialization of the contained key. Secret Keys are serialized with a 3 tag followed by the serialization of the contained key. Signer-Verifier extractions are serialized with a 33 tag followed by the serialization of the contained extraction.