Create generators flexibility

[BasileiosKal]

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]

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]

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]

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]

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]

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

[christianpaquin]

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]

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]

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

[christianpaquin]

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]

The fixtures from PR #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)

[christianpaquin]

LGTM

[tplooker]

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