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

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

With apologies for a self-reply, a few addenda to my suggestions
based on off-list discussions:

0. Define the term "internal representation" up front. Make clear
   that it's a restricted version of an elliptic curve point that
   is defined over some underlying curve, and that all operations on
   intenal representations not explicitly allowed by the text of the
   document are prohibited.

"Riad S. Wahby" <[e-mail]> wrote:
> 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."

Clarify in the above that inputs to ENCODE and EQUALS MUST be internal
representations; any other inputs are prohibited.

Also clarify that the only way to get an internal representation
is from DECODE, FROM_UNIFORM_BYTES, or from a permitted operation
applied to an existing internal representation.

> 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".

Also, rename FROM_UNIFORM_BYTES to either FROM_BYTES or FROM_STRING,
and remove the length and distribution requirements on the input.
The hash-to-curve document handles the uniformity internally while
ensuring that conforming usage meets relevant security requirements.
There's no reason to make higher-level protocols reinvent the wheel.

Again, happy to write a PR for this and/or read future drafts,

-=rsw