This issue tracks adding blind signature protocol support to CIRCL. We currently have a digital signature package for computing non-interactive signatures, including ed2559 and ed448, as well as various post quantum algorithms. We don't have an API for interactive protocols that compute signatures, like we do for the OPRF.
Adding such an API is somewhat non-trivial as some protocols, like clause blind Schnorr, require more than two messages between client (verifier) and server (signer). However, it seems reasonable to start with two message protocols like blind RSA and blind BLS, rather than try and generalize to protocols with n >= 2 messages.
To that end, here's a simple start:
type Verifier interface {
Blind(message []byte) ([]byte, VerifierState, error) // return the message sent to the signer and verifier state, or an error
}
type VerifierState interface {
Finalize(data []byte) ([]byte, error) // return the signature upon success, and an error otherwise
}
type Signer interface {
BlindSign(data []byte) ([]byte, error) // return the signed, blinded message, or an error
}
The abstraction across this API is a byte stream, so all of the scheme-specific details about the signature contents and protocol messages are hidden. We could choose to expose a bit more, but that seems unnecessarily complicated.
@armfazh, @cjpatton: what do you think? I'd like to add blind RSA support, so if this seems reasonable I'll send a PR.
This issue tracks adding blind signature protocol support to CIRCL. We currently have a digital signature package for computing non-interactive signatures, including ed2559 and ed448, as well as various post quantum algorithms. We don't have an API for interactive protocols that compute signatures, like we do for the OPRF.
Adding such an API is somewhat non-trivial as some protocols, like clause blind Schnorr, require more than two messages between client (verifier) and server (signer). However, it seems reasonable to start with two message protocols like blind RSA and blind BLS, rather than try and generalize to protocols with n >= 2 messages.
To that end, here's a simple start:
One would use it like so:
The abstraction across this API is a byte stream, so all of the scheme-specific details about the signature contents and protocol messages are hidden. We could choose to expose a bit more, but that seems unnecessarily complicated.
@armfazh, @cjpatton: what do you think? I'd like to add blind RSA support, so if this seems reasonable I'll send a PR.