Re: [Cfrg] Adoption request: draft-hdevalence-cfrg-ristretto

["Riad S. Wahby" <[e-mail]>]

Filippo Valsorda <[e-mail]> wrote:
> I fully agree that Section 3.3 should be expanded to clarify that the
> operations are indeed edwards25519 addition, subtraction and scalar
> multiplication (when using edwards25519 as internal representatives).

Sweet! Thank you so much for your patience helping me understand.

Here's a concrete proposal to clarify the document:

1. Make the Section 3 implementations of ENCODE, DECODE, EQUALS, and
   FROM_UNIFORM_BYTES normative, and clarify that the inputs to ENCODE
   and EQUALS and the outputs of DECODE and FROM_UNIFORM_BYTES are
   edwards25519 points that are "internal representations."

2. As now, forbid implementors from exposing any point that is an
   internal representation.

3. Explicitly allow mapping any internal representation to any curve
   isomorphic to edwards25519, and state that the output of any such
   mapping remains an internal representation and thus subject to
   all of these requirements.

   (List the edwards25519/curve25519 isomorphism as an example,
   and direct the reader to the birational map in RFC7748.)

   I'd also get rid of the text in the Section 3 header that talks
   about groups of order l, since edwards25519 is not such a group
   and thus no group isomorphic to it is either.

4. Explicitly allow addition, subtraction / inversion, and
   multiplication on any point that is an internal representation.
   These operations MUST be isomorphic to addition, subtraction /
   inversion, and multiplication on edwards25519.

5. Explicitly state that any internal representation that is the
   result of a sequence of mapping operations MUST be converted back
   to edwards25519 internal representation via the inverse sequence
   of mappings before applying the ENCODE or EQUALS function.

6. Explain that implementors MAY compose (e.g.)  DECODE/mapping,
   FROM_UNIFORM_BYTES/mapping, reverse-mapping/ENCODE,
   reverse-mapping/EQUALS, and similar into monolithic functions.
   In other words, the idea isn't to dictate the structure of the code,
   only the underlying algebraic properties.

7. Make FROM_UNIFORM_BYTES incorporate edwards25519-SHA256-EDELL2-RO
   by reference, and specify a DST (domain separation tag, see Section
   5.1 and 5.3 of hash-to-curve), e.g., "Ristretto255-Hash".

I'm happy to read future drafts, create PRs, etc.---let me know how
I can help!

-=rsw