[CFRG] Re: Pairing-Friendly Curves: Open Questions Before Draft Update

["Bellebaum, Thomas" <[e-mail]>]

Hi David,

> In the BLS case, that encoding should be a subset of the ZCash-based serialization, restricting that “C" is always 1 and “I" is always 0. BBS I believe constrains the algorithm to only support compressed points, but does not constrain serializing infinity.

BBS does constrain deserializing infinity, but not centrally in appendix B.2.
Instead, points are validated as follows:

- The public key is validated to not be Identity_G2 in octets_to_pubkey, line 4. It is preceded by a subgroup check.
- The proof points Abar, Bbar and D are validated to not be Identity_G1 in octets_to_proof, line 7. This test is followed by a subgroup check.
- The signature value A is validated to not be Identity_G1 in octets_to_signature, line 6. This test is followed by a subgroup check.

For blind signatures:

- The commitment C is validated to not be Identity_G1 in octets_to_commitment_with_proof, line 6. There is no subgroup check, which may or may not be an oversight. There is an implicit subgroup check provided by the associated proof (which asserts that the prover knows how to generate C through the set of generators), but if we go for this logic then there is no need to perform a subgroup check for all three of Abar, Bbar and D above...

It is interesting to note that deserialize_and_validate_commit returns Identity_G1, but does so deliberately to reuse existing code paths in case there is no commitment. In no realistic scenario should an identity ever be serialized or deserialized (assuming access to unbiased random bits).

Best regards,

-- TBB