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

["Filippo Valsorda" <[e-mail]>]

2019-07-25 04:10 GMT+02:00 Riad S. Wahby <[e-mail]>:
> Filippo Valsorda <[e-mail]> wrote:
> >     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.

edwards25519 points generated by DECODE or FROM_UNIFORM_BYTES are *one
possible kind* of internal representatives.
 
> >     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.

That was a bad diagram on my part. This should be more accurate.

    (something) -> edwards25519 point -> ENCODE

where (something) is neither DECODE nor FROM_UNIFORM_BYTES from the same
edwards25519-based ristretto255 implementation.

To borrow your type error analogy, internal_representative is a
different type from edwards25519_point, although it might or might not
be an opaque wrapper around edwards25519_point, and ENCODE takes an
internal_representative, not an edwards25519_point.


Looking at the Go implementation might also help (although of course
the spec will need to stand on its own) as it puts this into actual types.

https://github.com/gtank/ristretto255