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

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

Filippo Valsorda <[e-mail]> wrote:
>     DECODE -> map -> (something) -> reverse_map -> ENCODE
> 
> This chain that you describe, if done correctly, would in fact be just
> an alternative implementation of ristretto255, as it operates entirely
> within the realm of internal representatives.

Sweet! I think I'm starting to get it...

In this case, let's be clear that we're talking about DECODE and ENCODE
as defined in Section 3, i.e., working on edwards25519 points as the
"internal representation."

>     ENCODE -> map -> (something) -> reverse_map -> DECODE
> 
> This, correct me if I'm wrong, is an example of the kind of map Jeff
> is talking about: something that takes abstract ristretto255 elements
> (which might be implemented with something else than edwards25519) and
> maps them to edwards25519 points (NOT internal representatives).

Sorry, I don't understand this. edwards25519 points *are* valid
internal representations.

(I fully understand that munging the bitstring that comes out of
ENCODE is crazy and not allowedt, though!)

>     edwards25519 point -> (something) -> reverse_map -> ENCODE
> 
>     DECODE -> map -> edwards25519 point -> (something)

Wait, what is the type signature of reverse_map? ENCODE takes an
edwards25519 point (again, per Section 3), so to me this looks like
a type error, in which case I fully agree this can't return anything
intelligible.

> An example of this is draft-irtf-cfrg-voprf-01 defining its own map to
> ristretto255 internal representatives.

As the Ristretto draft is currently written, that appears to be true
(or, at least, if it's false, it's only by chance).

(Not to muddy the waters, but for the record I'm strongly hoping
that the next Ristretto draft will replace its specification of
FROM_UNIFORM_BYTES with edwards25519-SHA256-EDELL2-RO. There's
no reason for Ristretto to be incompatible with hash-to-curve.
But let's worry about other issues first.)

-=rsw