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

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

Jeff Burdges <[e-mail]> wrote:
> The real issue is that there are two such mappings, depending upon the
> branch of the inverse square root chosen.  These two interoperate
> seamlessly, provided the mapping is not exposed.  If however the mapping
> is exposed later then they suddenly differ.  The problematic scenario goes:

Just to clarify: the mappings you're talking about are the ones in
RFC7748, Section 4.1, and the value whose sign you're worried about
is sqrt(-486664) mod p, right?

A second clarification: we're really talking about mapping *from*
edwards25519 *to* curve25519, since what's in the Ristretto draft
Section 3 apparently works on edwards25519 points (I think).

> Joe later expands his protocol by adding and using the mapping, using
> the form of the mapping natural given the arithmetic he inherited.
> Again everything works, so now people depend upon Joe's mapping.  Joe
> does not however check all newly applicable test vectors from the
> standard because everything works fine.

Again, "the mapping" being the one to curve25519?

> Joe expands his protocol to interoperate with another implementation.
> Now suddenly everything breaks because the mappings differ.  Yet both
> incompatible forms are deployed.

Same question as above re "the mappings".

Can you give a specific example of the kind of interop that would
break? In particular, provided that reverse_map(map(X)) == X for all
rational points X on edwards25519, wouldn't it always be safe to do
something like

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

provided that (something) includes only allowed operations (addition,
inversion, multiplication)?

-=rsw