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

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

Hello Filippo,

Thanks for the email. Answers inline below.

Filippo Valsorda <[e-mail]> wrote:
> RSW wrote:
> > OK, but this can't actually be true, because there are other operations
> > alluded to (but not defined) in the document, and without those
> > operations (point addition, point inversion, scalar multiplication)
> > ristretto255 doesn't actually let me do anything.
> 
> The critical section here is Section 3.3 of -01, which reads
> 
> > 3.3.  Operations on internal representations
> >
> >   Group addition, subtraction and (multi-)scalar multiplication are
> >   performed without modification using the internal representations.
> >
> >   Implementations MUST NOT perform any other operation on internal
> >   representations.

Right, this is what is "alluded to" (self-quote above).

The problem, simply put, is that the document does not define how to
do these operations.

(Also: inversion, subtraction, either's fine.)

> The main challenge that we'd appreciate wording help with is that
> of defining the behavior of the group normatively through the example
> of its edwards25519 implementation, while making it clear that the
> edwards25519 internal representatives are an implementation choice,
> and must not be directly generated nor accessed, in order to make
> alternative implementations possible.

I'm super duper willing to help. I want this document to succeed.
But I cannot help when the document as it stands cannot be parsed
except by its authors and/or without some educated guessing.

> I want to mention that there is inherent value in clearly
> defining the public API surface of a cryptographic primitive

Totally agreed! I want to be crystal clear, this is not my complaint.

> We believe sections 3.2 and 3.3 provide all operations necessary to
> implement the "prime order group" interface (and if not, we should
> specify the missing ones).

Here is the problem: Sections 3.2 and 3.3 *do not* provide those
operations. For example, the document does not indicate how to perform
point addition, because nowhere in the document is it made clear that
the output of DECODE as defined in Section 3 is an edwards25519 point.

> (Notwithstanding the fact that someone who read the Decaf paper like
> you might indeed make safe abstraction breaches—modulo alternative
> implementation compatibility. The point is that we are designing a
> primitive that aims to be misuse resistant because it neither requires
> nor allows such attempts.)

I promise, I really don't want to break the abstraction! I'm asking
these questions to try and triangulate what the document and the
claims in this thread mean, because right now it's totally unclear.

Again, thank you (all) for your patience with my questions,

-=rsw