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

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

> Document scope and structure
> 
>    - Should the draft stay focused on curve parameters and test vectors, or  
>    also include interface guidance, serialization formats, or tutorial  
>    content? Should nonessential background material (e.g. pairing formulae,  
>    curve surveys) be moved to an appendix or companion document? Should the  
>    draft’s title or positioning be updated to reflect this narrower focus?
> 

The pure math is sufficiently covered in the literature and does not require re-publication at the IRTF.
I am most interested in unifying the interface between applications (focusing on octet strings) and various ECC protocols (dealing with abstractions like cyclic group elements and scalars). These are details which should never be reinvented by WGs, and neither should they be restated in every protocol using these curves.

Thus, surveys can be moved to a different document (or the appendix), while serialization and tutorials/algorithms should become more central.

Good RFCs to look to are
- RFC 7748, which gives explicit algorithms for de-/serialization and curve multiplication, and
- RFC 8032, which gives advice for efficiently decoding a compressed point.

Pairing-friendly curves should extend this level of detail to common operations like pairings.

> Curve selection
> 
>    - Is the current set of curves appropriate? Some suggest narrowing to  
>    BLS12-381 plus one BLS24 and one BLS48 to target 128-, 192-, and 256-bit  
>    security levels. Others recommend removing BN curves that may no longer  
>    meet security or deployment criteria. A shared rationale is needed for  
>    inclusion or removal. Should this document support only BLS-style use  
>    cases, or also applications like ZKPs or IBE?
> 

I am in favor of removing options here. ECC as a whole has limited value when we need PQ solutions, so focusing on getting one or two options correct (and implementations secure) right now seems better. Even with RFC7748, I only see one of those curves in practice.

I would like to see BLS12-381 and optionally one 256-bit curve where implementation experience from the former is most useful for implementing the latter.

> Interfaces and related primitives
> 
>    - Should the draft describe expected abstractions or interfaces (e.g.  
>    mapping to G1/G2, referencing hash-to-curve), or should it remain neutral  
>    and defer to other specs like RFC 9380? Should the draft specify a minimal  
>    pairing API (e.g. function signature or domain separation guidance), or  
>    leave that entirely to downstream specs?
> 

RFC 9380 already contains quite detailed, constant-time, optimized algorithms for computing hashing operations. A reference suffices I think.
For the pairing, similarly detailed instructions should be given.
A brief overview/list of all the supported operations would be nice in the introduction.

> Serialization
> 
>    - The current draft allows both compressed and uncompressed encodings,  
>    including identity elements. Concerns were raised about interoperability  
>    and risks from optional encodings. Should the draft specify a simpler,  
>    consistent serialization format for implementers? Should identity points be  
>    disallowed or tightly constrained?
> 

I wrote the mail arguing against uncompressed formats and the identity element and still believe that this would be the preferable option to reach secure implementations.
However, I do see the argument for computational superiority of uncompressed points in theory.
In practice however, the square root computation seems cheap compared to the computation of pairings, which are the reason we are using these curves in the first place, and frequent hash-to-curve operations.

*If* there are major applications wishing to use uncompressed points, I would advise them against mixing the two serialization formats (especially "on demand"). In this case, I would prefer to stick to one of the following options:
- Have the _very_ few applications requiring uncompressed points (assuming these are rare) define their own version of an encoding including detailed instructions on how to parse incoming octets, or
- Specify a second, dedicated curve with identical parameters to the normal one, but a different identifier (to also be used in hash-to-curve), which uses the uncompressed format exclusively. Again, include detailed de-serialization instructions.

In any case, the identity element is not useful currently compared to the potential damage it can do (maybe even including timing leaks for checks?).

The option of only specifying the uncompressed format (as suggested by Watson) seems undesirable as long as the BBS schemes use the compressed format exclusively.

> Framing and utility
> 
>    - To support adoption, should the draft explicitly document security  
>    assumptions (e.g. resistance to DLP via exTNFS), implementation risks (e.g.  
>    subgroup checks), and what classes of protocols these curves are  
>    appropriate for? Should test vectors include intermediate values or results  
>    for multiple encodings?
> 

If you provide detailed instructions to de-serialize prime-order group elements, you do not need to talk about subgroup problems in detail thereafter. The same goes for constant-time operations. Any remaining implementation risks should be clearly documented, alongside some guidance.

Details on various attack performances and detailed discussions of the bit security belong in the scientific literature, which we should reference rather than repeat (as they are not very helpful to protocol/application designers or implementers).


Thanks for your efforts! Let me know if I can help out somehow.
Best,

-- TBB