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

[Michele Orrù <[e-mail]>]

Hi Yumi,

Neat. I updated
<https://github.com/mmaker/draft-irtf-cfrg-sigma-protocols/pull/160/changes>
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.

> 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
<https://github.com/mmaker/draft-irtf-cfrg-sigma-protocols/pull/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.