RFC 9496: The ristretto255 and decaf448 Groups
- H. de Valence,
- J. Grigg,
- M. Hamburg,
- I. Lovecruft,
- G. Tankersley,
- F. Valsorda
Abstract
This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448.¶
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.¶
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Research Task Force
(IRTF). The IRTF publishes the results of Internet
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
Decaf [Decaf] is a technique for constructing prime-order groups with nonmalleable encodings from non-prime-order elliptic curves. Ristretto extends this technique to support cofactor-8 curves such as Curve25519 [RFC7748]. In particular, this allows an existing Curve25519 library to provide a prime-order group with only a thin abstraction layer.¶
Many group-based cryptographic protocols require the number of elements in the group (the group order) to be prime. Prime-order groups are useful because every non-identity element of the group is a generator of the entire group. This means the group has a cofactor of 1, and all elements are equivalent from the perspective of hardness of the discrete logarithm problem.¶
Edwards curves provide a number of implementation benefits for cryptography. These benefits include formulas for curve operations that are among the fastest currently known, and for which the addition formulas are complete with no exceptional points. However, the group of points on the curve is not of prime order, i.e., it has a cofactor larger than 1. This abstraction mismatch is usually handled, if it is handled at all, by means of ad hoc protocol tweaks such as multiplying by the cofactor in an appropriate place.¶
Even for simple protocols such as signatures, these tweaks can cause subtle issues. For instance, Ed25519 implementations may have different validation behavior between batched and singleton verification, and at least as specified in [RFC8032], the set of valid signatures is not defined precisely [Ed25519ValidCrit].¶
For more complex protocols, careful analysis is required 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 described in [MoneroVuln]).¶
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
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 can be implemented using Curve25519, and the decaf448 group, which can be implemented using edwards448.¶
There are other elliptic curves that can be used internally to implement ristretto255 or decaf448; those implementations would be interoperable with one based on Curve25519 or edwards448, but those constructions are out of scope for this document.¶
The Ristretto construction is described and justified in detail at [RistrettoGroup].¶
This document represents the consensus of the Crypto Forum Research Group (CFRG). This document is not an IETF product and is not a standard.¶
2. Notation and Conventions Used in This Document
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Readers are cautioned that the term "Curve25519" has varying interpretations in the literature and that the canonical meaning of the term has shifted over time. Originally, it referred to a specific Diffie-Hellman key exchange mechanism. Use shifted over time, and "Curve25519" has been used to refer to the abstract underlying curve, its concrete representation in Montgomery form, or the specific Diffie-Hellman mechanism. This document uses the term "Curve25519" to refer to the abstract underlying curve, as recommended in [Naming]. The abstract Edwards form of the curve we refer to here as "Curve25519" is referred to in [RFC7748] as "edwards25519", and the Montgomery form that is isogenous to the Edwards form is referred to in [RFC7748] as "curve25519".¶
Elliptic curve points in this document are represented in extended
Edwards coordinates in the (x, y, z, t) format [Twisted], also called
extended homogeneous coordinates in Section 5.1.4 of [RFC8032]. Field
elements are values modulo p, the Curve25519 prime 2255 - 19 or the
edwards448 prime 2448 - 2224 - 1, as specified in Sections
4.1 and 4.2 of [RFC7748], respectively. All
formulas specify field operations unless otherwise noted. The symbol
^ denotes exponentiation.¶
The | symbol represents a constant-time logical OR.¶
The notation array[A:B] means the elements of array from A
to B-1. That is, it is exclusive of B. Arrays are indexed
starting from 0.¶
A byte is an 8-bit entity (also known as "octet"), and a byte string is an ordered sequence of bytes. An N-byte string is a byte string of N bytes in length.¶
Element encodings are presented as hex-encoded byte strings with whitespace added for readability.¶
2.1. Negative Field Elements
As in [RFC8032], given a field element e, define IS_NEGATIVE(e) as
TRUE if the least nonnegative integer representing e is odd and
FALSE if it is even. This SHOULD be implemented in constant time.¶
2.2. Constant-Time Operations
We assume that the field element implementation supports the following operations, which SHOULD be implemented in constant time:¶
Note that CT_ABS MAY be implemented as:¶
3. The Group Abstraction
Ristretto and Decaf implement an abstract prime-order group interface that exposes only the behavior that is useful to higher-level protocols, without leaking curve-related details and pitfalls.¶
Each abstract group exposes operations on abstract element and abstract scalar types. The operations defined on these types include: decoding, encoding, equality, addition, negation, subtraction, and (multi-)scalar multiplication. Each abstract group also exposes a deterministic function to derive abstract elements from fixed-length byte strings. A description of each of these operations is below.¶
Decoding is a function from byte strings to abstract elements with built-in validation, so that only the canonical encodings of valid elements are accepted. The built-in validation avoids the need for explicit invalid curve checks.¶
Encoding is a function from abstract elements to byte strings. Internally, an abstract element might have more than one possible representation; for example, the implementation might use projective coordinates. When encoding, all equivalent representations of the same element are encoded as identical byte strings. Decoding the output of the encoding function always succeeds and returns an element equivalent to the encoding input.¶
The equality check reports whether two representations of an abstract element are equivalent.¶
The element derivation function maps deterministical
Second, although the element derivation function is many-to-one and therefore
not strictly invertible, it is not pre-image resistant. On the contrary,
given an arbitrary abstract group element P, there is an efficient algorithm
to randomly sample from byte strings that map to P. In some contexts, this
property would be a weakness, but it is important in some contexts: in particular,
it means that a combination of a cryptographic hash function and the element
derivation function is suitable to define encoding functions such as
hash (Appendix B of [RFC9380]) and hash_to_decaf448
(Appendix C of [RFC9380]).¶
Addition is the group operation. The group has an identity element and
prime order l. Adding together l copies of the same element gives the
identity. Adding the identity element to
any element returns that element unchanged. Negation returns an element
that, when added to the negation input, gives the identity element.
Subtraction is the addition of a negated element, and scalar
multiplication is the repeated addition of an element.¶
4. ristretto255
ristretto255 is an instantiation of the abstract prime-order group
interface defined in Section 3. This document describes how to
implement the ristretto255 prime-order group using Curve25519 points as
internal representations
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. Each group element can have
multiple equivalent internal representations
Encoding, decoding, equality, and the element derivation function are defined in Section 4.3. Element addition, subtraction, negation, and scalar multiplication are implemented by applying the corresponding operations directly to the internal representation.¶
The group order is the same as the order of the Curve25519 prime-order subgroup:¶
Since ristretto255 is a prime-order group, every element except the
identity is a generator. However, for interoperabilit
4.1. Implementation Constants
This document references the following constant field element values that are used for the implementation of group operations.¶
4.2. Square Root of a Ratio of Field Elements
The following function is defined on field elements and is used to implement other ristretto255 functions. This function is only used internally to implement some of the group operations.¶
On input field elements u and v, the function SQRT_RATIO_M1(u, v) returns:¶
where +sqrt(x) indicates the nonnegative square root of x in the
field.¶
The computation is similar to what is described in Section 5.1.3 of [RFC8032], 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 derivation function. The function can be refactored from an existing Ed25519 implementation.¶
SQRT_RATIO_M1(u, v) is defined as follows:¶
4.3. ristretto255 Group Operations
This section describes the implementation of the external functions exposed by the ristretto255 prime-order group.¶
4.3.2. Encode
A group element with internal representation (x0, y0, z0, t0) is
encoded as follows:¶
Note that decoding and then re-encoding a valid group element will yield an identical byte string.¶
4.3.3. Equals
The equality function returns TRUE when two internal representations correspond to the same group element. Note that internal representations MUST NOT be compared in any way other than specified here.¶
For two internal representations (x1, y1, z1, t1) and (x2, y2, z2, t2),
if¶
evaluates to TRUE, then return TRUE. Otherwise, return FALSE.¶
Note 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.¶
Implementations MAY also perform constant-time byte comparisons on the encodings of group elements (produced by Section 4.3.2) for an equivalent, although less efficient, result.¶
4.3.4. Element Derivation
The element derivation function operates on 64-byte strings.
To obtain such an input from an arbitrary
The element derivation function on an input string b proceeds as follows:¶
The MAP function is defined on 32-byte strings as:¶
4.4. Scalar Field
The scalars for the ristretto255 group are integers modulo the order l
of the ristretto255 group. Note that this is the same scalar field as
Curve25519, allowing existing implementations to be reused.¶
Scalars are encoded as 32-byte strings in little-endian order.
Implementations SHOULD check that any scalar s falls in the range
0 <= s < l when parsing them and reject non-canonical scalar
encodings. Implementations SHOULD reduce scalars modulo l when
encoding them as byte strings. Omitting these strict range checks is
NOT RECOMMENDED but is allowed to enable reuse of scalar
arithmetic implementations in existing Curve25519 libraries.¶
Given a uniformly distributed 64-byte string b, implementations can
obtain a uniformly distributed scalar by interpreting the 64-byte
string as a 512-bit unsigned integer in little-endian order and reducing the
integer modulo l, as in [RFC8032]. To obtain such an input from an
arbitrary
5. decaf448
decaf448 is an instantiation of the abstract prime-order group
interface defined in Section 3. This document describes how to
implement the decaf448 prime-order group using edwards448 points as
internal representations
A "decaf448 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 decaf448. Each group element can have multiple
equivalent internal representations
Encoding, decoding, equality, and the element derivation functions are defined in Section 5.3. Element addition, subtraction, negation, and scalar multiplication are implemented by applying the corresponding operations directly to the internal representation.¶
The group order is the same as the order of the edwards448 prime-order subgroup:¶
Since decaf448 is a prime-order group, every element except the
identity is a generator; however, for interoperabilitB, where B is the edwards448 base point, enabling reuse of
existing precomputation for scalar multiplication. The encoding of
this canonical generator, as produced by the function specified in
Section 5.3.2, is:¶
This repetitive constant is equal to 1/sqrt(5) in decaf448's field,
corresponding to the curve448 base point with x = 5.¶
5.1. Implementation Constants
This document references the following constant field element values that are used for the implementation of group operations.¶
5.2. Square Root of a Ratio of Field Elements
The following function is defined on field elements and is used to implement other decaf448 functions. This function is only used internally to implement some of the group operations.¶
On input field elements u and v, the function SQRT_RATIO_M1(u, v) returns:¶
where +sqrt(x) indicates the nonnegative square root of x in
the field.¶
The computation is similar to what is described in Section 5.2.3 of [RFC8032], 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 derivation function. The function can be refactored from an existing edwards448 implementation.¶
SQRT_RATIO_M1(u, v) is defined as follows:¶
5.3. decaf448 Group Operations
This section describes the implementation of the external functions exposed by the decaf448 prime-order group.¶
5.3.2. Encode
A group element with internal representation (x0, y0, z0, t0) is
encoded as follows:¶
Note that decoding and then re-encoding a valid group element will yield an identical byte string.¶
5.3.3. Equals
The equality function returns TRUE when two internal representations correspond to the same group element. Note that internal representations MUST NOT be compared in any way other than specified here.¶
For two internal representations (x1, y1, z1, t1) and (x2, y2, z2, t2),
if¶
evaluates to TRUE, then return TRUE. Otherwise, return FALSE.¶
Note 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.¶
Implementations MAY also perform constant-time byte comparisons on the encodings of group elements (produced by Section 5.3.2) for an equivalent, although less efficient, result.¶
5.3.4. Element Derivation
The element derivation function operates on 112-byte strings.
To obtain such an input from an arbitrary
The element derivation function on an input string b proceeds as follows:¶
The MAP function is defined on 56-byte strings as:¶
5.4. Scalar Field
The scalars for the decaf448 group are integers modulo the order l
of the decaf448 group. Note that this is the same scalar field as
edwards448, allowing existing implementations to be reused.¶
Scalars are encoded as 56-byte strings in little-endian order.
Implementations SHOULD check that any scalar s falls in the range
0 <= s < l when parsing them and reject non-canonical scalar
encodings. Implementations SHOULD reduce scalars modulo l when
encoding them as byte strings. Omitting these strict range checks is
NOT RECOMMENDED but is allowed to enable reuse of scalar
arithmetic implementations in existing edwards448 libraries.¶
Given a uniformly distributed 64-byte string b, implementations can
obtain a uniformly distributed scalar by interpreting the 64-byte
string as a 512-bit unsigned integer in little-endian order and reducing the
integer modulo l. To obtain such an input from an arbitrary
6. API Considerations
ristretto255 and decaf448 are abstractions that implement two prime-order groups. Their elements are represented by curve points, but are not curve points, and implementations SHOULD reflect that fact. That is, the type representing an element of the group SHOULD be opaque to the caller, meaning they do not expose the underlying curve point or field elements. Moreover, implementations SHOULD NOT expose any internal constants or functions used in the implementation of the group operations.¶
The reason for this encapsulation is that ristretto255 and decaf448 implementations can change their underlying curve without causing any breaking change. The ristretto255 and decaf448 constructions are carefully designed so that this will be the case, as long as implementations do not expose internal representations or operate on them except as described in this document. In particular, implementations SHOULD NOT define any external ristretto255 or decaf448 interface as operating on arbitrary curve points, and they SHOULD NOT construct group elements except via decoding, the element derivation function, or group operations on other valid group elements per Section 3. However, they are allowed to apply any optimization strategy to the internal representations as long as it doesn't change the exposed behavior of the API.¶
It is RECOMMENDED that implementations not perform a decoding and encoding operation for each group operation, as it is inefficient and unnecessary. Implementations SHOULD instead provide an opaque type to hold the internal representation through multiple operations.¶
7. IANA Considerations
This document has no IANA actions.¶
8. Security Considerations
The ristretto255 and decaf448 groups provide higher-level protocols with the abstraction they expect: a prime-order group. Therefore, it's expected to be safer for use in any situation where Curve25519 or edwards448 is used to implement a protocol requiring a prime-order group. Note that the safety of the abstraction can be defeated by implementations that do not follow the guidance in Section 6.¶
There is no function to test whether an elliptic curve point is a
valid internal representation of a group element. The decoding
function always returns a valid internal representation or an error, and
operations exposed by the group per Section 3 return valid internal
representations when applied to valid internal representations
9. References
9.1. Normative References
- [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174
9.2. Informative References
- [Decaf]
-
Hamburg, M., "Decaf: Eliminating cofactors through point compression", , <https://
www >..shiftleft .org /papers /decaf /decaf .pdf - [Ed25519Valid
Crit] -
de Valence, H., "It's 255:19AM. Do you know what your validation criteria are?", , <https://
hdevalence >..ca /blog /2020 -10 -04 -its -25519am - [MoneroVuln]
-
Nick, J., "Exploiting Low Order Generators in One-Time Ring Signatures", , <https://
jonasnick >..github .io /blog /2017 /05 /23 /exploiting -low -order -generators -in -one -time -ring -signatures / - [Naming]
-
Bernstein, D. J., "Subject: [Cfrg] 25519 naming", message to the Cfrg mailing list, , <https://
mailarchive >..ietf .org /arch /msg /cfrg /-9LEdnz Vr E5RORux3Oo _o DDRks U / - [RFC7748]
-
Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10
.17487 , , <https:///RFC7748 www >..rfc -editor .org /info /rfc7748 - [RFC8032]
-
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10
.17487 , , <https:///RFC8032 www >..rfc -editor .org /info /rfc8032 - [RFC9380]
-
Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S., and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380, DOI 10
.17487 , , <https:///RFC9380 www >..rfc -editor .org /info /rfc9380 - [RistrettoGroup]
-
de Valence, H., Lovecruft, I., Arcieri, T., and M. Hamburg, "The Ristretto Group", <https://
ristretto >..group - [Twisted]
-
Hisil, H., Wong, K. K., Carter, G., and E. Dawson, "Twisted Edwards Curves Revisited", Cryptology ePrint Archive, Paper 2008/522, , <https://
eprint >..iacr .org /2008 /522
Appendix A. Test Vectors for ristretto255
This section contains test vectors for ristretto255. The octets are hex encoded, and whitespace is inserted for readability.¶
A.1. Multiples of the Generator
The following are the encodings of the multiples 0 to 15 of the canonical generator, represented as an array of elements. That is, the first entry is the encoding of the identity element, and each successive entry is obtained by adding the generator to the previous entry.¶
Note that because¶
these test vectors allow testing of the encoding function and the implementation of addition simultaneously.¶
A.2. Invalid Encodings
These are examples of encodings that MUST be rejected according to Section 4.3.1.¶
A.3. Group Elements from Uniform Byte Strings
The following pairs are inputs to the element derivation function of Section 4.3.4 and their encoded outputs.¶
The following element derivation function inputs all produce the same encoded output.¶
A.4. Square Root of a Ratio of Field Elements
The following are inputs and outputs of SQRT_RATIO_M1(u, v) defined
in Section 4.2. The values are little-endian encodings of field
elements.¶
Appendix B. Test Vectors for decaf448
This section contains test vectors for decaf448. The octets are hex encoded, and whitespace is inserted for readability.¶
B.1. Multiples of the Generator
The following are the encodings of the multiples 0 to 15 of the canonical generator, represented as an array of elements. That is, the first entry is the encoding of the identity element, and each successive entry is obtained by adding the generator to the previous entry.¶
B.2. Invalid Encodings
These are examples of encodings that MUST be rejected according to Section 5.3.1.¶
B.3. Group Elements from Uniform Byte Strings
The following pairs are inputs to the element derivation function of Section 5.3.4 and their encoded outputs.¶
Acknowledgements
The authors would like to thank Daira Emma Hopwood, Riad S. Wahby, Christopher Wood, and Thomas Pornin for their comments on the document.¶