chris-wood
commented
3 years ago - Intro and abstract: Too much attack details — omit entirely and refer reader to the paper, noting implications. Maybe merge with section 3?
- Preliminaries: Are all details for curves necessary? Example: point at infinity, twists, etc?
- Section 4: choosing “widely used” over “efficiency” is interesting, as it may impede use cases that would consider adopting pairings but don’t due to the cost. How would some of the recommendations change if “efficiency” were prioritized over “widely used”? (Would BLS12-381 still stand on top?)
- Section 4: 192-bit security is mentioned into the intro, but there is no matching recommendation. Recommend removing from intro.
- Section 4: move adoption status to an appendix?
- Section 4: link to application table points to a blog post. Consider removing?
- Section 4.1.2: lots of libraries mentioned here — do any of them have formally verified implementations? Adding new curve support to a library is a tall order, but easier if, say, that code can be generated and formally verified.
- Section 4.2: 128-bit security level: interesting that we’re recommending things with less than 128 bits of security. At what rate does the security of this curve deteriorate? Generally: unclear if the CFRG has or will ever draw the line somewhere beneath this bound.
- Section 4.2: Unclear what the security level of BN462 is — is it 128 bits?
- Reference to I-D.ietf-lwig-curve-representations is unclear. What is the status of that draft?
- Generally: parameters for curves are provided, but there’s no safe implementable pairing specification. (The appendix code is not constant time, it seems. Is that important?) Unclear what the target audience is for. If this is for implementers deciding how to implement one of these curves, would they not need to know the corresponding pairing details? If it’s for applications choosing curves, do they need to know all these curve details? (Same goes for encoding and decoding, which has some text in the security considerations section and then has one serialization format for BLS12_381. What about other curves? Do we want to recommend one serialization format so things are interoperable? Should the serialization format be something that applications decide?)
- Appendix D: can this be dropped?
yumi-sakemi