search

facebook / ristretto255-js

Javascript implementation of the Ristretto255 group operations, built on top of the popular TweetNaCl.js crypto library
MIT License
34 stars 10 forks source link

Refer to internal representations instead of Edwards points #3

Closed str4d closed 4 years ago

str4d commented 4 years ago

The README currently contains language like:

The ristretto technique gives a way to map ristretto255 group elements to Edwards points (fromBytes()) and to convert a certain subset of Edwards points back to ristretto255 group elements (toBytes()).

This suggests to users that it is potentially valid to convert between ristretto255 group elements and Edwards points, and use the latter in other contexts. This is not the case, as the ristretto255 RFC draft strongly states in section 4 (and elsewhere in the spec):

ristretto255 is an abstraction which exposes a prime-order group, and ristretto255 elements are represented by curve points, but they are not curve points. The API needs to reflect that: the type representing an element of the group SHOULD be opaque and MUST NOT expose the underlying curve point.

It SHOULD be possible for a ristretto255 implementation to change its underlying curve without causing any breaking change. A ristretto255 implementation MUST be interoperable with any other implementation, even if that implementation uses a different curve internally. Any operation on ristretto255 elements that only works correctly or leads to different results based on the underlying curve is explicitly disallowed.

In particular, implementations MUST NOT define the ristretto255 functions as operating on arbitrary curve points, and they MUST NOT construct group elements except via "DECODE" and "FROM_UNIFORM_BYTES".

However, it is RECOMMENDED that implementations don't perform a "DECODE" and "ENCODE" operation for each operation in Section 3.3, as it is inefficient and unnecessary. Implementation SHOULD instead provide an opaque type to hold the internal representation in between operations.

I presume that limitations of JavaScript prevent you from providing an opaque type that contains the internal representation as an Edwards point (thus making the safe APIs perform a DECODE and ENCODE operation for each API operation). An opaque type is strongly preferred, but if it is not possible, then the language in the README should be altered to ensure that users understand they MUST NOT operate directly on the internal representations (beyond the specific unsafe APIs provided) under any circumstances.

kevinlewi commented 4 years ago

Thanks for pointing this out -- README updated.