[CFRG] Re: draft-irtf-cfrg-pairing-friendly-curves: question on the scope of PR #71 (Group/Scalar interface)

[Watson Ladd <[e-mail]>]

On Fri, Sep 11, 2026 at 8:33 AM Michele Orrù <[e-mail]> wrote:
>
> Hi Yumi,
>
> Neat. I updated our references to the pairing draft so that we are all aligned with the next revision. If you can double-check that we aren't missing anything, we're good to go. What follows are some more thoughts on canonical encodings, and some inline answers to your message.
>
> Can we still drop uncompressed serialization? Is any adopter actively using uncompressed serialization?
> In practice: keep the same wire format, but drop uncompressed and add a test vector that asserts rejection for C_bit = 0. That's what should happen in practice.
>
> In signatures and zero-knowledge proofs, having two possible encodings (which occurs since there are two valid  serialization algorithms) leads to malleability attacks.
> An attacker can take a signature/proof in compressed form, re-encode it in uncompressed form, and present it as a fresh forgery.
> For instance, cloudflare/circl and microsoft/bbs-node-reference don't satisfy strong unforgeability because of this.
> For those doing pseudonymous authentication, this is even worse because it means that users have two different pseudonyms per scope.

That's not necessarily true: it depends on the details of the
pseudonym and what kind of comparison is being done. If you just
blindly pass in the data rather than normalize, you'll have a fun
time. Having a single canonical encoding does help here, as does not
accepting other options, but it isn't a necessary consequence.
>
> > There is also a structural gap: pairing-based work has G_T, which Section 2.2 defines as an order-r subgroup of the multiplicative group of GF(p^k) rather than a group of curve points, and an EC group interface has no slot for it.
>
> I don't see the problem. G_T is a multiplicative subgroup of a finite field, therefore it is also a group. The interface we're looking for is a group interface.
>
> > [..] and [1, r-1] does not arise in it; Section 5.6.Section 5.6.3 covers only the receiving side: whether a protocol accepts a zero scalar it has decoded. If you see a reason for a curve document to address the sampling range as well, we would be glad to hear it.
>
> My comment didn't concern your specification, it's more about a lack of uniformity among different drafts, which might have repercussions for implementers.
> This was more for the whole CFRG than a single specific draft.
>
> A note contradicting my previous message:
>
> > - sigma-protocols rejects the identity during group-element deserialization [12].
>
> After a few conversations, we are most likely going to allow the identity element in sigma-proofs; there are too many good use cases to leave it out. Thanks to Ian Goldberg and Jan Bobolz for their patience and helpful discussions. This is #159.
>
> P.S. As a side note, I personally don’t mind reading AI-assisted text, and I completely understand the language barrier. That said, receiving a large wall of undigested text might discourage other cryptographers from taking the time to review your spec.
>
> Best,
> --
> Michele.
>
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Astra mortemque praestare gradatim