Add partially blind RSA implementation

[chris-wood]

See the specification for more information. This is needed to help experiment with a version of Privacy Pass that supports public metadata, described here.

This change removes some of the interfaces that were previously unused, like the generic blindsign.Verifier and BlindSign.Signer interfaces.

cc @Guss123

[bwesterb]

This breaks the old API. In particular, it will break this online example. Do we need to break it?

[armfazh]

I did one pass, will do another one once the suggested changes are addressed.

[chris-wood]

This breaks the old API. In particular, it will break this online example. Do we need to break it?

I suppose not, but I don't think we need to worry about API stability for a library like this.

[chris-wood]

@bwesterb @armfazh most specific changes have been addressed, but we have open the API compatibility question and stuff about naming.

[armfazh]

I'm ok with refactoring the code (and breaking API) if it improves the code. So, here is my suggestion.

The package blindrsa already indicates it is a blind signature of RSA type. So we can remove some prefixes.

BRSASigner -> Signer
BRSAVerifier -> Verifier
BRSAVerifierState -> VerifierState

Make the following types unexported since there exist New<> functions for them:

DeterminsiticBRSAVerifier -> determinsiticBRSAVerifier
RandomBRSAVerifier -> randomBRSAVerifier
BigPrivateKey -> bigPrivateKey
BigPublicKey -> bigPublicKey 

Coalesce NewBRSAVerifier and NewDeterministicBRSAVerifier in a single function NewVerifier(pk,hash,flag) Verifier with a boolean flag to choose whether is randomized or deterministic.

For Partially-blind RSA, my suggestion is to create a subpackage:

/circl/blindsign/blindrsa                   # blind RSA 
/circl/blindsign/blindrsa/partialblindrsa   # partial blind RSA 
/circl/blindsign/blindrsa/internal/         # common code

This ease the naming to have plain Signer, Verifier, etc. names.

[chris-wood]

Thanks @armfazh -- I enacted all your suggestions except for the one to merge constructors. I think it's better to avoid constructors with boolean flags. For the other comments regarding key generation and whatnot, we could implement that in this change or separately. Do you have a preference?

[armfazh]

adding some comments to blindrsa, still need to review partialblind

[armfazh]

there are some exported functions that require keys from /internal/keys package, which is an internal package.
Thus, these keys cannot be instantiated in other packages (unless providing a generator function).

Can we reconsider to unexport, for example, VerifyMessageSignature, since we already have two constructors to get a Verifier?

[chris-wood]

Can we reconsider to unexport, for example, VerifyMessageSignature, since we already have two constructors to get a Verifier?

I'm not sure I follow this. Can you rephrase?

[armfazh]

Currently there are three methods to verify a signature:

1. building a NewVerifier, and calling its Verify method.
2. building a NewDeterministicVerifier, and calling its Verify method.
3. using the VerifyMessageSignature function.

I see redundancy on having so many functions that do the same thing (unless they behave differently).
It seems to me that 3) should not be exposed and moved to an internal package.

[chris-wood]

Got it -- thanks for clarifying. VerifyMessageSignature is what's called internally for the Verify function of both NewVerifier and NewDeterminsiticVerifier.

[armfazh]

few minor changes only, otherwise lgtm

[chris-wood]

@armfazh thanks again for the suggestions -- I applied them.

[chris-wood]

Thanks for the changes @armfazh!