[Cfrg] Comments on draft-hdevalence-cfrg-ristretto-01

[Watson Ladd <[e-mail]>]

Dear all,

I read the draft and don't really have a technical comment so much as
a broader organizational comment and perhaps mathematical, verging on
philosophical concerns. The first thrust of my concerns is that it's
always important to understand why calculations take the form they do.
And this missing from the draft. I think the word isogeny (although
not quite right: Edwards curves aren't smooth, it's a more complicated
thing) really does need to appear, as does an explanation of what the
EQUALS routine is doing. Otherwise the routines appear
decontextualized and it is difficult to understand why they have to be
used in the manner they are.

Given that the draft extends Decaf I'd like to be e able to
mechanically check the equations for typos and the like and verify the
assertions made. I recall there is such a thing floating about, I just
don't remember where I saw it.

The draft talks about a group G, and says that we have ENCODING and
DECODING maps to this other group G'. G' is of course the twisted
Edwards form of Ed25519 aka Curve25519. But what isn't mentioned is
what these maps are really doing: G is actually a sort of mysterious
combination of a subgroup and a product (and I'm not sure I understand
the Decaf paper well enough to say precisely what) and the maps are
lifting to elements of G'. So the ENCODING map has a very nontrivial
kernel and is squashing the equivalence classes down. The DECODING map
sections the ENCODING map.

The problem of course is that the group structure on G is left very
implicit. What I think should be said explicitly is you do group
operations by DECODING, performing the operations and then ENCODING.

Then there is the question of exposure. I don't understand what is
meant by implementation exposing something. Having used Ed25519
libraries that expose the multiple point representations used for
efficient calculation and taking advantage of that extra exposure, I
think the issue is really a protocol level one: if you are using
risttreto you should output and input ristretto points, not any
internal form, just as internal representations as Jacobian points
should never be input and output but used as intermediates in
calculations.

Perhaps this is the same as Riad's point: I'm not quite sure I
understood that one either.

Sincerely,
Watson