search

decentralized-identity / bbs-signature

The BBS Signature Scheme
https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html
Apache License 2.0
80 stars 26 forks source link

Create generators flexibility #264

Closed BasileiosKal closed 1 year ago

BasileiosKal commented 1 year ago

Closes #206

Going with option 2 from the issue, allowing the definition of new create_generators and listing the relative requirements. Τhis will also benefit use cases like Bound signatures.

BasileiosKal commented 1 year ago

Discussed on the WG call on the 29th of May, will re-consider the use of extra_info and add the PK as a parameter to the create_generators API.

christianpaquin commented 1 year ago

I'm not sure I understand the goal of parameterizing the generators creation. Isn't there a value for applications to pre-generate and reuse them across many issuers (which would not be possible of if they depend on an issuer PK). Is the goal of the header to further scope the generators, so an issuer can have multiple distinct generators? Generators can be used to track users, so their uniformity has value.

andrewwhitehead commented 1 year ago

The ciphersuite does not have to take the PK and header into account when creating the generators, and the ones defined by the spec will not. It just seemed reasonable to pass those parameters in case the suite wants to define the generators differently (such as how the original implementation did, based on the issuer PK and number of messages). I don't think this increases correlation as the PK and header are known to all verifiers.

christianpaquin commented 1 year ago

I don't think this increases correlation as the PK and header are known to all verifiers.

What header is this again? Is it a ciphersuite defined one, or a per-issuance one? I was just concerned that an issuer could pick a different header to create a "tagged" signature for a user.

andrewwhitehead commented 1 year ago

It's the signature header, which is per issuance (and may be empty). It contributes to the domain hash.

christianpaquin commented 1 year ago

It's the signature header, which is per issuance (and may be empty). It contributes to the domain hash.

Ok, so it doesn't add traceability risks then.

BasileiosKal commented 1 year ago

I think a malicious issuer could use a unique header per signature to track the user. There are plans for adding privacy considerations to address this. The user (or anyone else) could check the header and decide if it is conformant to those considerations.

Indented use-cases for the header (e.g., to include algorithm/protocol identifiers etc.,) make it hard to define it as part of the ciphersuite.

BasileiosKal commented 1 year ago

Discussed on the WG call on the 19th of June. Will remove the header parameter from the Inputs of create_generators.

christianpaquin commented 1 year ago

Discussed on the WG call on the 19th of June. Will remove the header parameter from the Inputs of create_generators.

The fixtures from PR #269 currently used the header, right?

BasileiosKal commented 1 year ago

The fixtures from PR https://github.com/decentralized-identity/bbs-signature/pull/269 currently used the header, right?

I think the header should be ignored by the create generators procedure. It should be the same procedure, (i.e., hash_to_generators == the current create_generators from the main spec).

Similar to the PK, it was supplied in the core operations but ignored by the ciphersuite (I did removed the header entirely also)

tplooker commented 1 year ago

Discussed on WG call 26th of June, multiple approvals merging.