The ristretto255 Groupietf@hdevalence.caietf@jackgrigg.comietf@gtank.ccietf@filippo.ioietf@en.ciph.re
InternetCrypto Forum Research GroupThis memo specifies a prime-order group, ristretto255, suitable for
implementing complex cryptographic protocols such as zero-knowledge
proofs. The ristretto255 group can be implemented using Curve25519,
allowing existing Curve25519 implementations to be reused and
extended to provide a prime-order group.Ristretto is a technique for constructing prime order groups with
non-malleable encodings from non-prime-order elliptic curves. It
extends the approach to cofactor elimination to support
cofactor-8 curves such as Curve25519 . In particular, this
allows an existing Curve25519 library to provide a prime-order group
with only a thin abstraction layer.Edwards curves provide a number of implementation benefits for
cryptography, such as complete addition formulas with no exceptional
points and the fastest known formulas for curve operations. However,
every Edwards curve has a point of order 4, so that the group of
points on the curve is not of prime order but has a small cofactor.This abstraction mismatch is usually handled by means of ad-hoc
protocol tweaks (such as multiplying by the cofactor in an
appropriate place), or not at all.Even for simple protocols such as signatures, these tweaks can cause
subtle issues. For instance, Ed25519 implementations may have
different validation behaviour between batched and singleton
verification, and at least as specified in , the set of
valid signatures is not defined by the standard.For more complex protocols, careful analysis is required for each
protocol, as the original security proofs may no longer apply, and the
tweaks for one protocol may have disastrous effects when applied to
another (for instance, the octuple-spend vulnerability in ).Decaf and Ristretto fix this abstraction mismatch in one place for
all protocols, providing an abstraction to protocol implementors that
matches the abstraction commonly assumed in protocol specifications,
while still allowing the use of high-performance curve
implementations internally.While Ristretto is a general method, and can be used in conjunction
with any Edwards curve with cofactor 4 or 8, this document specifies
the ristretto255 group, which MAY be implemented using Curve25519.It is also possible to implement ristretto255 using a different
elliptic curve internally, but that construction is out-of-scope for
this document.The ristretto255 abstraction layer provides the following API to
higher-level protocols:ENCODE, an encoding function from internal representations to
bytestrings so that all equivalent representations on the same
ristretto255 element are encoded as identical bytestrings;DECODE, a decoding function from bytestrings to internal
representations with built-in validation, so that only the canonical
encodings of valid ristretto255 elements are accepted;EQUALS, an equality check that operates on internal
representations, so that all representations of the same
ristretto255 element are considered equivalent;FROM_UNIFORM_BYTES, a map from uniformly distributed bytestrings
to ristretto255 elements suitable for hash-to-group and random-point
operations.The internal representatives are elliptic curve points, and
internally, group element addition and subtraction (and therefore
scalar multiplication) is implemented by applying point addition,
subtraction and scalar multiplication to the internal representation.In other words, an existing Edwards curve implementation can implement
ristretto255 by adding four functions: ENCODE, DECODE, EQUALS,
and FROM_UNIFORM_BYTES.The abstraction layer imposes minor
overhead, and certain operations (like EQUALS) are faster
than corresponding operations on the elliptic curve points used
internally.The Ristretto construction and its ristretto255 instantiation are
described and justified in detail at https://ristretto.group.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown here.A "ristretto255 group element" is the abstract element of the prime
order group. An "element encoding" is the unique reversible encoding
of a group element. An "internal representation" is a point on the
curve used to implement ristretto255, alternatively called a
"representative". Each group element can have multiple equivalent
internal representations.Elliptic curve points are represented in extended coordinates in the
(x, y, z, t) format . All formulas specify field operations
unless otherwise noted.This documents describes how to implement the ristretto255 group using
Curve25519 points as an internal representation. Note that
implementations MAY choose to use a different internal representation,
possibly based on a different curve, as long as they provide a group
of orderwhose encoding and decoding functions match the ones in this document.In particular, implementations MUST NOT expose the internal
representation and MUST NOT apply any operations defined on the
internal representations unless specified in this document.Since ristretto255 is a prime order group, every element is a
generator, but for interoperability a canonical generator is selected,
which can be internally represented by the Curve25519 basepoint,
enabling reuse of existing precomputation for scalar
multiplication. This is its encoding:The following functions are defined on field elements, and are used to
implement the other ristretto255 functions. These are defined in this
document for convenience in extending a Curve25519 implementation to
provide the ristretto255 API. Implementations SHOULD NOT expose
these to their API consumers.The order of the field is p, the Curve25519 prime 2^255-19, as
specified in Section 4.1 of . Other parameters used in this
document are:SQRT_M1 = 19681161376707505956807079304988542015446066515923890162744021073123829784752SQRT_AD_MINUS_ONE = 25063068953384623474111414158702152701244531502492656460079210482610430750235INVSQRT_A_MINUS_D = 54469307008909316920995813868745141605393597292927456921205312896311721017578ONE_MINUS_D_SQ = 1159843021668779879193775521855586647937357759715417654439879720876111806838D_MINUS_ONE_SQ = 40440834346308536858101042469323190826248399146238708352240133220865137265952As in , given a field element e, define IS_NEGATIVE(e) as
TRUE if the least significant bit of the encoding of e is 1, and FALSE
otherwise.We assume that the field element implementation supports the following
operations, which SHOULD be implemented in constant time:CT_EQ(u, v): Return TRUE if u = v, FALSE otherwise.CT_SELECT(v IF cond ELSE u): Return v if cond is TRUE, else return u.CT_NEG(u, cond): Return -u if cond is TRUE, else return u.CT_ABS(u): Return -u if u is negative, else return u.Note that if they are not already provided, CT_NEG can be implemented
as CT_SELECT(-u IF cond ELSE u) and CT_ABS can be implemented as
CT_SELECT(-u IF IS_NEGATIVE(u) ELSE u).On input field elements u and v, the function SQRT_RATIO_M1(u, v) returns:(TRUE, +sqrt(u/v)) if v is non-zero and u/v is square;(TRUE, zero) if u is zero;(FALSE, zero) if v is zero and u is non-zero;(FALSE, +sqrt(SQRT_M1*(u/v))) if u/v is non-square (so SQRT_M1*(u/v) is square).The computation is similar to Section 5.1.3 of , with the
difference that if the input is non-square, the function returns a
result with a defined relationship to the inputs. This result is used
for efficient implementation of the from-uniform-bytes functionality. The
function can be refactored from an existing Ed25519 implementation.SQRT_RATIO_M1(u, v) is defined as follows:A ristretto255 implementation MUST implement the following functions:All elements are encoded as a 32-byte string. Decoding proceeds as follows:First, interpret the string as an integer s in little-endian
representation. If the resulting value is >= p, decoding fails.If IS_NEGATIVE(s) returns TRUE, decoding fails.Process s as follows:If was_square is FALSE, or IS_NEGATIVE(t) returns TRUE, or y = 0,
decoding fails. Otherwise, return the internal representation in
extended coordinates (x, y, 1, t).An internal representation (x0, y0, z0, t0) is encoded as follows:Process the internal representation into a field element s as follows:Return the canonical little-endian encoding of s.Note that decoding and then re-encoding a valid group element will
yield an identical bytestring.The equality function returns TRUE when two representatives correspond
to the same group element. Note that internal representations
MUST NOT be compared in any other way than specified here.For two representatives (x1, y1, z1, t1) and (x2, y2, z2, t2), ifevaluates to TRUE, then return TRUE. Otherwise, return FALSE. Note
that a = -1 when using Curve25519 internally, simplifying the check toNote that the equality function always returns TRUE when applied to an
internal representation and to the internal representation obtained by
encoding and then re-decoding it. However, the internal
representations themselves might not be identical.Unlike the equality check for an elliptic curve point in projective
coordinates, the equality check for a ristretto255 group element does
not require an inversion.Define the function MAP(t) on field element t as:Then, given a uniformly distributed 64-byte string b:Set r0 to the low 255 bits of b[ 0..32], taken mod pSet r1 to the low 255 bits of b[32..64], taken mod pCompute group element P1 as MAP(r0)Compute group element P2 as MAP(r1).Return the group element P1 + P2.Group addition, subtraction and (multi-)scalar multiplication are
performed without modification using the internal representations.Implementations MUST NOT perform any other operation on internal
representations and MUST NOT construct group elements
except via DECODE and FROM_UNIFORM_BYTES.The scalars for the ristretto255 group are integers modScalars are encoded as 32-byte strings in little-endian order.
Implementations SHOULD check that scalars are reduced modulo l when
parsing them and reject non-canonical scalar encodings.
Implementations SHOULD reduce scalars modulo l when encoding them
as byte strings.Given a uniformly distributed 64-byte string b, implementations can
obtain a scalar by interpreting the 64-byte string as a 512-bit
integer in little-endian order and reducing the integer modulo l, as
in .This document has no IANA actions.ristretto255 elements are represented by curve points, but they are
not curve points. Not every curve point is a representative of a
ristretto255 element. The ristretto255 group is not a subgroup of the
curve, and the ristretto255 group is logically distinct from the group
of curve points.For these reasons, ristretto255 elements SHOULD have a different
type than curve points, and it SHOULD be a type error to mix
them. In particular, implementations MUST NOT define the
ristretto255 functions as operating on arbitrary curve points, rather
than only on the representatives obtained by decoding a ristretto255
encoding or by mapping arbitrary bytestrings.There is no function to test whether an elliptic curve point is a
valid internal representative of a group element. The decoding
function always returns a valid representative, or an error, and
allowed operations on valid internal representations return valid
internal representations. In this way, an implementation can maintain
the invariant that an internal representative is always valid, so that
checking is never necessary, and invalid states are unrepresentable.Ristretto was originally designed by Mike Hamburg as a variant of .Twisted Edwards Curves RevisitedDecaf: Eliminating cofactors through point
compressionRambus Cryptography ResearchExploiting Low Order Generators in One-Time Ring SignaturesThis section contains test vectors for ristretto255. The octets are
hex encoded, and whitespace is inserted for readability.The following are the encodings of the multiplies 0 to 15 of the
canonical generator. That is, the first line is the encoding of the
identity point, and each successive line is obtained by adding the
generator to the previous line.Note that becausethese test vectors allow testing the encoding function and
the implementation of addition simultaneously.These are examples of encodings that MUST be rejected according to
.The following pairs are inputs to FROM_UNIFORM_BYTES, and their encoded
outputs.