[CFRG] Re: Review of BBS Signatures draft-07

[Vasilis Kalos <[e-mail]>]

Dear Michele and all,

Thank you for the review! I do agree with the suggestions. See some comments inline.

> *.BBS tokens and keyed-verification*
> … the issuer and redeemer are the same person just like in Privacy Pass (this is called "algebraic MAC" in cryptography). In fact, if the verifier has x, then we don't need a pairing map to check signatures: a BBS signature (A, e) for a message commitment C is valid if xA = C - eA.

That’s true, but I don’t think the User (Client in pp) will have access to the Issuer's sk. In the algebraic MAC case, it will be the Verifier (Origin I think in pp) that will have the Issuer’s sk. For the Client to verify the signature without pairings, the Issuer will have to generate a ZKP of knowledge for an x so that pk = G * x and A * x = C - A * e. That to say, although I do really like the idea of a DH oracle, making the pairings optional may not be that simple.

(We do have a draft on the above here<https://basileioskal.github.io/pairing-free-bbs/draft-vasilis-pairing-free-bbs.html>. Would be open to merging the documents if there is a need)

> *.Concrete security of the protocol *
> *Suggestion 4: understand the security and efficiency trade-offs with PS signatures*

The main advantage of BBS Signatures IMHO is the decoupling of the PK from the number of messages. TMU, in PS each “type” of credentials (with a different number of attributes) will need a different PK. For that reason, BBS Signatures are more suitable for “generic use cases”, providing more flexibility (like hiding the Issuer use cases).

> *.Blind BBS multiplicative blinding*
> It is possible to have "blind BBS" as a pair (A, e) consistent with the signature using *multiplicative* instead of additive blind.

Note that in the last version of blind signatures<https://www.ietf.org/archive/id/draft-kalos-bbs-blind-signatures-03.html> we removed the “signer_blind” and re-introduced it in pseudonyms<https://www.ietf.org/archive/id/draft-kalos-bbs-per-verifier-linkability-00.html> only. So, the blind signature currently is (A, e).

> *.Blind BBS API design*
> one-more unforgeable tokens. If the user proof can be optional, it's easy
to just have another specification say that that function is just a nop

We also added `FinalizeBlind<https://www.ietf.org/archive/id/draft-kalos-bbs-blind-signatures-03.html#name-finalize-blind-sign>` (Section 4.3.3 on the blind BBS signatures draft<https://www.ietf.org/archive/id/draft-kalos-bbs-blind-signatures-03.html>) which will sign any point B, without checking any user provided proof.

In any case, the documents are far from final. Any proposal and contribution will be extremely appreciated.
> *.On the zero-knowledge proofs*
> *Suggestion 9: simplify Fiat-Shamir and have a generic framework for future proofs*

For a generic ZKP I expressed my thoughts here<https://mailarchive.ietf.org/arch/msg/cfrg/d58lWLAOLN5UgGSvu3VmwsJtG2E/>. I’m still not convinced that the core BBS draft is the best place for such a description.

Nevertheless, I will be happy to help with that, no matter where it lands, since I do find it really useful.

Kind regards,
Vasilis Kalos