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

Two message blind signature protocols #307

Closed
chris-wood opened this issue Dec 8, 2021 · 0 comments · Fixed by #308
Closed

Two message blind signature protocols #307

chris-wood opened this issue Dec 8, 2021 · 0 comments · Fixed by #308

Comments

@chris-wood
Copy link
Contributor

chris-wood commented Dec 8, 2021

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
}

One would use it like so:

verifier := NewFooVerifier(... public key, options ...)
signer := NewFooSigner(... private key, options ...)

msg := []byte("test")
req, state, err := veriifer.Blind(msg)
resp, err := signer.BlindSign(req)
sig, err := state.Finalize(resp)

// use (msg, sig) pair as needed

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.

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

Successfully merging a pull request may close this issue.

1 participant