Cloudflare

101 Townsend St San Francisco United States of America armfazh@cloudflare.com

Cornell Tech

2 West Loop Rd New York, New York 10044 United States of America sam.scott@cornell.edu

Cloudflare

101 Townsend St San Francisco United States of America nick@cloudflare.com

Stanford University

rsw@cs.stanford.edu

Cloudflare

101 Townsend St San Francisco United States of America caw@heapingbits.net

CFRG Internet-Draft This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve.

Introduction Many cryptographic protocols require a procedure that encodes an arbitrary input, e.g., a password, to a point on an elliptic curve. This procedure is known as hashing to an elliptic curve. Prominent examples of cryptosystems that hash to elliptic curves include password-authenticated key exchanges , Identity-Based Encryption , Boneh-Lynn-Shacham signatures , Verifiable Random Functions , and Oblivious Pseudorandom Functions . Unfortunately for implementors, the precise hash function that is suitable for a given protocol implemented using a given elliptic curve is often unclear from the protocol's description. Meanwhile, an incorrect choice of hash function can have disastrous consequences for security. This document aims to bridge this gap by providing a comprehensive set of recommended algorithms for a range of curve types. Each algorithm conforms to a common interface: it takes as input an arbitrary-length byte string and produces as output a point on an elliptic curve. We provide implementation details for each algorithm, describe the security rationale behind each recommendation, and give guidance for elliptic curves that are not explicitly covered. We also present optimized implementations for internal functions used by these algorithms. Readers wishing to quickly specify or implement a conforming hash function should consult , which lists recommended hash-to-curve suites and describes both how to implement an existing suite and how to specify a new one. This document does not cover rejection sampling methods, sometimes referred to as "try-and-increment" or "hunt-and-peck," because the goal is to describe algorithms that can plausibly be computed in constant time. Use of these rejection methods is NOT RECOMMENDED, because they have been a perennial cause of side-channel vulnerabilities. See Dragonblood as one example of this problem in practice.

Requirements Notation 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.

Background

Elliptic curves The following is a brief definition of elliptic curves, with an emphasis on important parameters and their relation to hashing to curves. For further reference on elliptic curves, consult or . Let F be the finite field GF(q) of prime characteristic p > 3. (This document does not consider elliptic curves over fields of characteristic 2 or 3.) In most cases F is a prime field, so q = p. Otherwise, F is an extension field, so q = p^m for an integer m > 1. This document writes elements of extension fields in a primitive element or polynomial basis, i.e., as a vector of m elements of GF(p) written in ascending order by degree. The entries of this vector are indexed in ascending order starting from 1, i.e., x = (x_1, x_2, ..., x_m). For example, if q = p^2 and the primitive element basis is (1, I), then x = (a, b) corresponds to the element a + b * I, where x_1 = a and x_2 = b. An elliptic curve E is specified by an equation in two variables and a finite field F. An elliptic curve equation takes one of several standard forms, including (but not limited to) Weierstrass, Montgomery, and Edwards. The curve E induces an algebraic group whose elements are those points with coordinates (x, y) satisfying the curve equation, and where x and y are elements of F. This group has order n, meaning that there are n distinct points. This document uses additive notation for the elliptic curve group operation. For security reasons, cryptographic uses of elliptic curves generally require using a (sub)group of prime order. Let G be such a subgroup of the curve of prime order r, where n = h * r. In this equation, h is an integer called the cofactor. An algorithm that takes as input an arbitrary point on the curve E and produces as output a point in the subgroup G of E is said to "clear the cofactor." Such algorithms are discussed in . Certain hash-to-curve algorithms restrict the form of the curve equation, the characteristic of the field, or the parameters of the curve. For each algorithm presented, this document lists the relevant restrictions. The table below summarizes quantities relevant to hashing to curves:

Symbol	Meaning	Relevance
F,q,p	Finite field F of characteristic p and #F = q = p^m.	For prime fields, q = p; otherwise, q = p^m and m>1.
E	Elliptic curve.	E is specified by an equation and a field F.
n	Number of points on the elliptic curve E.	n = h * r, for h and r defined below.
G	A prime-order subgroup of the points on E.	Destination group to which byte strings are encoded.
r	Order of G.	r is a prime factor of n (usually, the largest such factor).
h	Cofactor, h >= 1.	An integer satisfying n = h * r.

Terminology In this section, we define important terms used throughout the document.

Mappings A mapping is a deterministic function from an element of the field F to a point on an elliptic curve E defined over F. In general, the set of all points that a mapping can produce over all possible inputs may be only a subset of the points on an elliptic curve (i.e., the mapping may not be surjective). In addition, a mapping may output the same point for two or more distinct inputs (i.e., the mapping may not be injective). For example, consider a mapping from F to an elliptic curve having n points: if the number of elements of F is not equal to n, then this mapping cannot be bijective (i.e., both injective and surjective) since the mapping is defined to be deterministic. Mappings may also be invertible, meaning that there is an efficient algorithm that, for any point P output by the mapping, outputs an x in F such that applying the mapping to x outputs P. Some of the mappings given in are invertible, but this document does not discuss inversion algorithms.

Encodings Encodings are closely related to mappings. Like a mapping, an encoding is a function that outputs a point on an elliptic curve. In contrast to a mapping, however, the input to an encoding is an arbitrary-length byte string. This document constructs deterministic encodings by composing a hash function Hf with a deterministic mapping. In particular, Hf takes as input an arbitrary string and outputs an element of F. The deterministic mapping takes that element as input and outputs a point on an elliptic curve E defined over F. Since Hf takes arbitrary-length byte strings as inputs, it cannot be injective: the set of inputs is larger than the set of outputs, so there must be distinct inputs that give the same output (i.e., there must be collisions). Thus, any encoding built from Hf is also not injective. Like mappings, encodings may be invertible, meaning that there is an efficient algorithm that, for any point P output by the encoding, outputs a string s such that applying the encoding to s outputs P. The instantiation of Hf used by all encodings specified in this document () is not invertible. Thus, the encodings are also not invertible. In some applications of hashing to elliptic curves, it is important that encodings do not leak information through side channels. is one example of this type of leakage leading to a security vulnerability. discusses further.

Random oracle encodings Two different types of encodings are possible, nonuniform encodings and random oracle encodings. Nonuniform encodings induce a distribution of points that is not uniformly random. Random oracle encodings, in contrast, induce a distribution of points that is statistically close to uniformly random. They also satisfy a stronger property: a random oracle encoding can be proved indifferentiable from a random oracle under a suitable assumption, meaning it is appropriate for use in many cryptographic protocols proven secure in the random oracle model. (Note, however, that indifferentiability is not always sufficient for security; see for further discussion.) The construction described in is indifferentiable from a random oracle when instantiated following the guidelines in this document. and discuss this construction further.

Serialization A procedure related to encoding is the conversion of an elliptic curve point to a bit string. This is called serialization, and is typically used for compactly storing or transmitting points. The inverse operation, deserialization, converts a bit string to an elliptic curve point. For example, and give standard methods for serialization and deserialization. Deserialization is different from encoding in that only certain strings (namely, those output by the serialization procedure) can be deserialized. In contrast, this document is concerned with encodings from arbitrary strings to elliptic curve points. This document does not cover serialization or deserialization.

Domain separation Cryptographic protocols proven secure in the random oracle model are often analyzed under the assumption that the random oracle only answers queries generated by the protocol. In practice, this assumption does not hold if two protocols use the same function to instantiate the random oracle. Concretely, consider protocols P1 and P2 that query a random oracle RO: if P1 and P2 both query RO on the same value x, the security analysis of one or both protocols may be invalidated. A common way of addressing this issue is called domain separation, which allows a single random oracle to simulate multiple, independent oracles. This is effected by ensuring that each simulated oracle sees queries that are distinct from those seen by all other simulated oracles. For example, to simulate two oracles RO1 and RO2 given a single oracle RO, one might define where || is the concatenation operator. In this example, "RO1" and "RO2" are called domain separation tags; they ensure that queries to RO1 and RO2 cannot result in identical queries to RO. Thus, it is safe to treat RO1 and RO2 as independent oracles.

Encoding byte strings to elliptic curves This section presents a general framework and interface for encoding byte strings to points on an elliptic curve. To construct these encodings, we rely on three basic functions:

• The function hash_to_field, {0, 1}^* x {1, 2, ...} -> (F, F, ...), hashes arbitrary-length byte strings to a list of one or more elements of a finite field F; its implementation is defined in .
• The function map_to_curve, F -> E, calculates a point on the elliptic curve E from an element of the finite field F over which E is defined. describes mappings for a range of curve families.
• The function clear_cofactor, E -> G, sends any point on the curve E to the subgroup G of E. describes methods to perform this operation.

We describe two high-level encoding functions (), a nonuniform encoding and a random oracle encoding. Although these functions have the same interface, the distributions of their outputs are different.

• Nonuniform encoding (encode_to_curve). This function encodes byte strings to points in G. The distribution of the output is not uniformly random in G.

• Random oracle encoding (hash_to_curve). This function encodes byte strings to points in G. This function is suitable for applications requiring a random oracle returning points in G when instantiated with any of the map_to_curve functions described in .

Each hash-to-curve suite in instantiates one of these encoding functions for a specifc elliptic curve.

Domain separation requirements All uses of the encoding functions defined in this document MUST include domain separation () to avoid interfering with other uses of similar functionality. Applications that instantiate multiple, independent instances of either hash_to_curve or encode_to_curve MUST enforce domain separation between those instances. This requirement applies both in the case of multiple instances targeting the same curve and in the case of multiple instances targeting different curves. (This is because the internal hash_to_field primitive () requires domain separation to guarantee independent outputs.) Domain separation is enforced with a domain separation tag (DST), which is a byte string constructed according to the following requirements:

1. Tags MUST be supplied as the DST parameter to hash_to_field, as described in .
2. Tags MUST have nonzero length. A minimum length of 16 bytes is RECOMMENDED to reduce the chance of collisions with other applications.
3. Tags SHOULD begin with a fixed identification string that is unique to the application.
4. Tags SHOULD include a version number.
5. For applications that define multiple ciphersuites, each ciphersuite's tag MUST be different. For this purpose, it is RECOMMENDED to include a ciphersuite identifier in each tag.
6. For applications that use multiple encodings, either to the same curve or to different curves, each encoding MUST use a different tag. For this purpose, it is RECOMMENDED to include the encoding's Suite ID () in the domain separation tag. For independent encodings based on the same suite, each tag should also include a distinct identifier, e.g., "ENC1" and "ENC2".

As an example, consider a fictional application named Quux that defines several different ciphersuites. A reasonable choice of tag is "QUUX-V<xx>-CS<yy>-<suiteID>", where <xx> and <yy> are two-digit numbers indicating the version and ciphersuite, respectively, and <suiteID> is the Suite ID of the encoding used in ciphersuite <yy>. As another example, consider a fictional application named Baz that requires two independent random oracles to the same curve. Reasonable choices of tags for these oracles are "BAZ-V<xx>-CS<yy>-<suiteID>-ENC1" and "BAZ-V<xx>-CS<yy>-<suiteID>-ENC2", respectively, where <xx>, <yy>, and <suiteID> are as described above.

Utility functions Algorithms in this document use the utility functions described below, plus standard arithmetic operations (addition, multiplication, modular reduction, etc.) and elliptic curve point operations (point addition and scalar multiplication). For security, implementations of these functions SHOULD be constant time, i.e., execution time SHOULD NOT depend on the values of the inputs. For such constant-time implementations, all arithmetic, comparisons, and assignments MUST be implemented in constant time. briefly discusses constant-time security issues. Guidance on implementing low-level operations (in constant time or otherwise) is beyond the scope of this document; readers should consult standard reference material .

• CMOV(a, b, c): If c is False, CMOV returns a, otherwise it returns b. For constant-time implementations, this operation must run in time independent of the value of c.
• AND, OR, NOT, and XOR are standard bitwise logical operators. For constant-time implementations, short-circuit operators MUST be avoided.
• is_square(x): This function returns True whenever the value x is a square in the field F. By Euler's criterion, this function can be calculated in constant time as In certain extension fields, is_square can be computed in constant time more quickly than by the above exponentiation. and describe optimized methods for extension fields. gives an optimized straight-line method for GF(p^2).
• sqrt(x): The sqrt operation is a multi-valued function, i.e., there exist two roots of x in the field F whenever x is square. To maintain compatibility across implementations while allowing implementors leeway for optimizations, this document does not require sqrt() to return a particular value. Instead, as explained in , any function that calls sqrt also specifies how to determine the correct root. The preferred way of computing square roots is to fix a deterministic algorithm particular to F. We give several algorithms in .
• sgn0(x): This function returns either 0 or 1 indicating the "sign" of x, where sgn0(x) == 1 just when x is "negative". (In other words, this function always considers 0 to be positive.) defines this function and discusses its implementation.
• inv0(x): This function returns the multiplicative inverse of x in F, extended to all of F by fixing inv0(0) == 0. To implement inv0 in constant time, compute inv0(x) := x^(q - 2). Notice on input 0, the output is 0 as required.
• I2OSP and OS2IP: These functions are used to convert a byte string to and from a non-negative integer as described in .
• a || b: denotes the concatenation of byte strings a and b. For example, "ABC" || "DEF" == "ABCDEF".
• substr(str, sbegin, slen): for a byte string str, this function returns the slen-byte substring starting at position sbegin; positions are zero indexed. For example, substr("ABCDEFG", 2, 3) == "CDE".
• len(str): for a byte string str, this function returns the length of str in bytes. For example, len("ABC") == 3.
• strxor(str1, str2): for byte strings str1 and str2, strxor(str1, str2) returns the bitwise XOR of the two strings. For example, strxor("abc", "XYZ") == "9;9" (the strings in this example are ASCII literals, but strxor is defined for arbitrary byte strings). In this document, strxor is only applied to inputs of equal length.

The sgn0 function This section defines a generic sgn0 implementation that applies to any field F = GF(p^m). It also gives simplified implementations for the cases F = GF(p) and F = GF(p^2). See for a discussion of representing elements of extension fields as vectors. = 1 (see immediately above). Input: x, an element of F. Output: 0 or 1. Steps: 1. sign = 0 2. zero = 1 3. for i in (1, 2, ..., m): 4. sign_i = x_i mod 2 5. zero_i = x_i == 0 6. sign = sign OR (zero AND sign_i) # Avoid short-circuit logic ops 7. zero = zero AND zero_i 8. return sign ]]> Note that any valid sgn0 function for extension fields must iterate over the entire vector representation of the input element. To see why, imagine a function sgn0* that ignores the final entry in its input vector, and consider a field element x = (0, x_2). Since sgn0* ignores x_2, sgn0*(x) == sgn0*(-x), which is incorrect when x_2 != 0. A similar argument applies to any entry of the vector representation of x. When m == 1, sgn0 can be significantly simplified: The case m == 2 is only slightly more complicated:

Hashing to a finite field The hash_to_field function hashes a byte string msg of arbitrary length into one or more elements of a field F. This function works in two steps: it first hashes the input byte string to produce a uniformly random byte string, and then interprets this byte string as one or more elements of F. For the first step, hash_to_field calls an auxiliary function expand_message. This document defines two variants of expand_message: one appropriate for hash functions like SHA-2 or SHA-3 , and another appropriate for extensible-output functions such as SHAKE-128 . Security considerations for each expand_message variant are discussed below (, ). Implementors MUST NOT use rejection sampling to generate a uniformly random element of F. The reason is that rejection sampling procedures are difficult to implement in constant time, and later well-meaning "optimizations" may silently render an implementation non-constant-time.

Security considerations The hash_to_field function is designed to be indifferentiable from a random oracle when expand_message () is modeled as a random oracle (see ). Ensuring indifferentiability requires care; to see why, consider a prime p that is close to 3/4 * 2^256. Reducing a random 256-bit integer modulo this p yields a value that is in the range [0, p / 3] with probability roughly 1/2, meaning that this value is statistically far from uniform in [0, p - 1]. To control bias, hash_to_field instead uses random integers whose length is at least ceil(log2(p)) + k bits, where k is the target security level for the suite in bits. Reducing such integers mod p gives bias at most 2^-k for any p; this bias is appropriate when targeting k-bit security. For each such integer, hash_to_field uses expand_message to obtain L uniform bytes, where These uniform bytes are then interpreted as an integer via OS2IP . For example, for a 255-bit prime p, and k = 128-bit security, L = ceil((255 + 128) / 8) = 48 bytes. Note that k is an upper bound on the security level for the corresponding curve. See for more details, and for guidelines on choosing k for a given curve.

hash_to_field implementation The following procedure implements hash_to_field. The expand_message parameter to this function MUST conform to the requirements given in . discusses the REQUIRED method for constructing DST, the domain separation tag. = 1 (see immediately above). - L = ceil((ceil(log2(p)) + k) / 8), where k is the security parameter of the suite (e.g., k = 128). - expand_message, a function that expands a byte string and domain separation tag into a uniformly random byte string (see discussion above). Inputs: - msg, a byte string containing the message to hash. - count, the number of elements of F to output. Outputs: - (u_0, ..., u_(count - 1)), a list of field elements. Steps: 1. len_in_bytes = count * m * L 2. uniform_bytes = expand_message(msg, DST, len_in_bytes) 3. for i in (0, ..., count - 1): 4. for j in (0, ..., m - 1): 5. elm_offset = L * (j + i * m) 6. tv = substr(uniform_bytes, elm_offset, L) 7. e_j = OS2IP(tv) mod p 8. u_i = (e_0, ..., e_(m - 1)) 9. return (u_0, ..., u_(count - 1)) ]]>

expand_message expand_message is a function that generates a uniformly random byte string. It takes three arguments:

1. msg, a byte string containing the message to hash,
2. DST, a byte string that acts as a domain separation tag, and
3. len_in_bytes, the number of bytes to be generated.

This document defines the following two variants of expand_message:

• expand_message_xmd () is appropriate for use with a wide range of hash functions, including SHA-2 , SHA-3 , BLAKE2 , and others.
• expand_message_xof () is appropriate for use with extensible-output functions (XOFs) including functions in the SHAKE or BLAKE2X families.

These variants should suffice for the vast majority of use cases, but other variants are possible; discusses requirements.

expand_message_xmd The expand_message_xmd function produces a uniformly random byte string using a cryptographic hash function H that outputs b bits. For security, H must meet the following requirements:

• The number of bits output by H MUST be b >= 2 * k, for k the target security level in bits. This ensures k-bit collision resistance.
• H MAY be a Merkle-Damgaard hash function like SHA-2. In this case, security holds when the underlying compression function is modeled as a random oracle . (See for discussion.)
• H MAY be a sponge-based hash function like SHA-3 or BLAKE2. In this case, security holds when the inner function is modeled as a random transformation or as a random permutation .
• Otherwise, H MUST be a hash function that has been proved indifferentiable from a random oracle under a reasonable cryptographic assumption.

SHA-2 and SHA-3 are typical and RECOMMENDED choices. As an example, for the 128-bit security level, b >= 256 bits and either SHA-256 or SHA3-256 would be an appropriate choice. The following procedure implements expand_message_xmd. 255 3. DST_prime = DST || I2OSP(len(DST), 1) 4. Z_pad = I2OSP(0, r_in_bytes) 5. l_i_b_str = I2OSP(len_in_bytes, 2) 6. msg_prime = Z_pad || msg || l_i_b_str || I2OSP(0, 1) || DST_prime 7. b_0 = H(msg_prime) 8. b_1 = H(b_0 || I2OSP(1, 1) || DST_prime) 9. for i in (2, ..., ell): 10. b_i = H(strxor(b_0, b_(i - 1)) || I2OSP(i, 1) || DST_prime) 11. uniform_bytes = b_1 || ... || b_ell 12. return substr(uniform_bytes, 0, len_in_bytes) ]]> Note that the string Z_pad is prepended to msg when computing b_0 (step 7). This is necessary for security when H is a Merkle-Damgaard hash, e.g., SHA-2 (see ). Hashing this additional data means that the cost of computing b_0 is higher than the cost of simply computing H(msg). In most settings this overhead is negligible, because the cost of evaluating H is much less than the other costs involved in hashing to a curve. It is possible, however, to entirely avoid this overhead by taking advantage of the fact that Z_pad depends only on H, and not on the arguments to expand_message_xmd. To do so, first precompute and save the internal state of H after ingesting Z_pad. Then, when computing b_0, initialize H using the saved state. Further details are implementation dependent, and beyond the scope of this document.

expand_message_xof The expand_message_xof function produces a uniformly random byte string using an extensible-output function (XOF) H. For security, H must meet the following criteria:

• The collision resistance of H MUST be at least k bits.
• H MUST be an XOF that has been proved indifferentiable from a random oracle under a reasonable cryptographic assumption.

The SHAKE XOF family is a typical and RECOMMENDED choice. As an example, for 128-bit security, SHAKE-128 would be an appropriate choice. The following procedure implements expand_message_xof.

Using DSTs longer than 255 bytes The expand_message variants defined in this section accept domain separation tags of at most 255 bytes. If applications require a domain separation tag longer than 255 bytes, e.g., because of requirements imposed by an invoking protocol, implementors MUST compute a short domain separation tag by hashing, as follows:

• For expand_message_xmd using hash function H, DST is computed as

• For expand_message_xof using extensible-output function H, DST is computed as

Here, a_very_long_DST is the DST whose length is greater than 255 bytes, "H2C-OVERSIZE-DST-" is a 17-byte ASCII string literal, and k is the target security level in bits.

Defining other expand_message variants When defining a new expand_message variant, the most important consideration is that hash_to_field models expand_message as a random oracle. Thus, implementors SHOULD prove indifferentiability from a random oracle under an appropriate assumption about the underlying cryptographic primitives; see for more information. In addition, expand_message variants:

• MUST give collision resistance commensurate with the security level of the target elliptic curve.
• MUST be built on primitives designed for use in applications requiring cryptographic randomness. As examples, a secure stream cipher is an appropriate primitive, whereas a Mersenne twister pseudorandom number generator is not.
• MUST NOT use rejection sampling.
• MUST give independent values for distinct (msg, DST, length) inputs. Meeting this requirement is subtle. As a simplified example, hashing msg || DST does not work, because in this case distinct (msg, DST) pairs whose concatenations are equal will return the same output (e.g., ("AB", "CDEF") and ("ABC", "DEF")). The variants defined in this document use a suffix-free encoding of DST to avoid this issue.
• MUST use the domain separation tag DST to ensure that invocations of cryptographic primitives inside of expand_message are domain separated from invocations outside of expand_message. For example, if the expand_message variant uses a hash function H, an encoding of DST MUST be either prepended or appended to the input to each invocation of H (appending is the RECOMMENDED approach).
• SHOULD read msg exactly once, for efficiency when msg is long.

In addition, each expand_message variant MUST specify a unique EXP_TAG that identifies that variant in a Suite ID. See for more information.

Deterministic mappings The mappings in this section are suitable for implementing either nonuniform or random oracle encodings using the constructions in . Certain mappings restrict the form of the curve or its parameters. For each mapping presented, this document lists the relevant restrictions. Note that mappings in this section are not interchangeable: different mappings will almost certainly output different points when evaluated on the same input.

Choosing a mapping function This section gives brief guidelines on choosing a mapping function for a given elliptic curve. Note that the suites given in are recommended mappings for the respective curves. If the target elliptic curve is a Montgomery curve (), the Elligator 2 method () is recommended. Similarly, if the target elliptic curve is a twisted Edwards curve (), the twisted Edwards Elligator 2 method () is recommended. The remaining cases are Weierstrass curves. For curves supported by the Simplified SWU method (), that mapping is the recommended one. Otherwise, the Simplified SWU method for AB == 0 () is recommended if the goal is best performance, while the Shallue-van de Woestijne method () is recommended if the goal is simplicity of implementation. (The reason for this distinction is that the Simplified SWU method for AB == 0 requires implementing an isogeny map in addition to the mapping function, while the Shallue-van de Woestijne method does not.) The Shallue-van de Woestijne method () works with any curve, and may be used in cases where a generic mapping is required. Note, however, that this mapping is almost always more computationally expensive than the curve-specific recommendations above.

Interface The generic interface shared by all mappings in this section is as follows: The input u and outputs x and y are elements of the field F. The affine coordinates (x, y) specify a point on an elliptic curve defined over F. Note that the point (x, y) is not a uniformly random point. If uniformity is required for security, the random oracle construction of MUST be used instead.

Notation As a rough guide, the following conventions are used in pseudocode:

• All arithmetic operations are performed over a field F, unless explicitly stated otherwise.
• u: the input to the mapping function. This is an element of F produced by the hash_to_field function.
• (x, y), (s, t), (v, w): the affine coordinates of the point output by the mapping. Indexed variables (e.g., x1, y2, ...) are used for candidate values.
• tv1, tv2, ...: reusable temporary variables.
• c1, c2, ...: constant values, which can be computed in advance.

Sign of the resulting point In general, elliptic curves have equations of the form y^2 = g(x). The mappings in this section first identify an x such that g(x) is square, then take a square root to find y. Since there are two square roots when g(x) != 0, this may result in an ambiguity regarding the sign of y. When necessary, the mappings in this section resolve this ambiguity by specifying the sign of the y-coordinate in terms of the input to the mapping function. Two main reasons support this approach: first, this covers elliptic curves over any field in a uniform way, and second, it gives implementors leeway in optimizing square-root implementations.

Exceptional cases Mappings may have have exceptional cases, i.e., inputs u on which the mapping is undefined. These cases must be handled carefully, especially for constant-time implementations. For each mapping in this section, we discuss the exceptional cases and show how to handle them in constant time. Note that all implementations SHOULD use inv0 () to compute multiplicative inverses, to avoid exceptional cases that result from attempting to compute the inverse of 0.

Mappings for Weierstrass curves The mappings in this section apply to a target curve E defined by the equation where 4 * A^3 + 27 * B^2 != 0.

Shallue-van de Woestijne method Shallue and van de Woestijne describe a mapping that applies to essentially any elliptic curve. (Note, however, that this mapping is more expensive to evaluate than the other mappings in this document.) The parameterization given below is for Weierstrass curves; its derivation is detailed in . This parameterization also works for Montgomery () and twisted Edwards () curves via the rational maps given in : first evaluate the Shallue-van de Woestijne mapping to an equivalent Weierstrass curve, then map that point to the target Montgomery or twisted Edwards curve using the corresponding rational map. Preconditions: A Weierstrass curve y^2 = x^3 + A * x + B. Constants:

• A and B, the parameter of the Weierstrass curve.
• Z, a non-zero element of F meeting the below criteria. gives a Sage script that outputs the RECOMMENDED Z.
  1. g(Z) != 0 in F.
  2. -(3 * Z^2 + 4 * A) / (4 * g(Z)) != 0 in F.
  3. -(3 * Z^2 + 4 * A) / (4 * g(Z)) is square in F.
  4. At least one of g(Z) and g(-Z / 2) is square in F.

Sign of y: Inputs u and -u give the same x-coordinate for many values of u. Thus, we set sgn0(y) == sgn0(u). Exceptions: The exceptional cases for u occur when (1 + u^2 * g(Z)) * (1 - u^2 * g(Z)) == 0. The restrictions on Z given above ensure that implementations that use inv0 to invert this product are exception free. Operations: gives an example straight-line implementation of this mapping.

Simplified Shallue-van de Woestijne-Ulas method The function map_to_curve_simple_swu(u) implements a simplification of the Shallue-van de Woestijne-Ulas mapping described by Brier et al. , which they call the "simplified SWU" map. Wahby and Boneh generalize and optimize this mapping. Preconditions: A Weierstrass curve y^2 = x^3 + A * x + B where A != 0 and B != 0. Constants:

• A and B, the parameters of the Weierstrass curve.
• Z, an element of F meeting the below criteria. gives a Sage script that outputs the RECOMMENDED Z. The criteria are:
  1. Z is non-square in F,
  2. Z != -1 in F,
  3. the polynomial g(x) - Z is irreducible over F, and
  4. g(B / (Z * A)) is square in F.

Sign of y: Inputs u and -u give the same x-coordinate. Thus, we set sgn0(y) == sgn0(u). Exceptions: The exceptional cases are values of u such that Z^2 * u^4 + Z * u^2 == 0. This includes u == 0, and may include other values depending on Z. Implementations must detect this case and set x1 = B / (Z * A), which guarantees that g(x1) is square by the condition on Z given above. Operations: gives an example straight-line implementation of this mapping. gives optimized straight-line procedures that apply to specific classes of curves and base fields. For more information on optimizing this mapping, see Section 4 or the example code found at .

Simplified SWU for AB == 0 Wahby and Boneh show how to adapt the simplified SWU mapping to Weierstrass curves having A == 0 or B == 0, which the mapping of does not support. (The case A == B == 0 is excluded because y^2 = x^3 is not an elliptic curve.) This method applies to curves like secp256k1 and to pairing-friendly curves in the Barreto-Lynn-Scott , Barreto-Naehrig , and other families. This method requires finding another elliptic curve E' given by the equation that is isogenous to E and has A' != 0 and B' != 0. (See , Appendix A, for one way of finding E' using .) This isogeny defines a map iso_map(x', y') given by a pair of rational functions. iso_map takes as input a point on E' and produces as output a point on E. Once E' and iso_map are identified, this mapping works as follows: on input u, first apply the simplified SWU mapping to get a point on E', then apply the isogeny map to that point to get a point on E. Note that iso_map is a group homomorphism, meaning that point addition commutes with iso_map. Thus, when using this mapping in the hash_to_curve construction of , one can effect a small optimization by first mapping u0 and u1 to E', adding the resulting points on E', and then applying iso_map to the sum. This gives the same result while requiring only one evaluation of iso_map. Preconditions: An elliptic curve E' with A' != 0 and B' != 0 that is isogenous to the target curve E with isogeny map iso_map from E' to E. Helper functions:

• map_to_curve_simple_swu is the mapping of to E'
• iso_map is the isogeny map from E' to E

Sign of y: for this map, the sign is determined by map_to_curve_simple_swu. No further sign adjustments are necessary. Exceptions: map_to_curve_simple_swu handles its exceptional cases. Exceptional cases of iso_map are inputs that cause the denominator of either rational function to evaluate to zero; such cases MUST return the identity point on E. Operations: See or Section 4.3 for details on implementing the isogeny map.

Mappings for Montgomery curves The mapping defined in this section applies to a target curve M defined by the equation

Elligator 2 method Bernstein, Hamburg, Krasnova, and Lange give a mapping that applies to any curve with a point of order 2 , which they call Elligator 2. Preconditions: A Montgomery curve K * t^2 = s^3 + J * s^2 + s where J != 0, K != 0, and (J^2 - 4) / K^2 is non-zero and non-square in F. Constants:

• J and K, the parameters of the elliptic curve.
• Z, a non-square element of F. gives a Sage script that outputs the RECOMMENDED Z.

Sign of t: this mapping fixes the sign of t as specified in . No additional adjustment is required. Exceptions: The exceptional case is Z * u^2 == -1, i.e., 1 + Z * u^2 == 0. Implementations must detect this case and set x1 = -(J / K). Note that this can only happen when q = 3 (mod 4). Operations: gives an example straight-line implementation of this mapping. gives optimized straight-line procedures that apply to specific classes of curves and base fields.

Mappings for twisted Edwards curves Twisted Edwards curves (a class of curves that includes Edwards curves) are given by the equation with a != 0, d != 0, and a != d . These curves are closely related to Montgomery curves (): every twisted Edwards curve is birationally equivalent to a Montgomery curve (, Theorem 3.2). This equivalence yields an efficient way of hashing to a twisted Edwards curve: first, hash to an equivalent Montgomery curve, then transform the result into a point on the twisted Edwards curve via a rational map. This method of hashing to a twisted Edwards curve thus requires identifying a corresponding Montgomery curve and rational map. We describe how to identify such a curve and map immediately below.

Rational maps from Montgomery to twisted Edwards curves There are two ways to select a Montgomery curve and rational map for use when hashing to a given twisted Edwards curve. The selected Montgomery curve and rational map MUST be specified as part of the hash-to-curve suite for a given twisted Edwards curve; see .

1. When hashing to a standardized twisted Edwards curve for which a corresponding Montgomery form and rational map are also standardized, the standard Montgomery form and rational map SHOULD be used to ensure compatibility with existing software. In certain cases, e.g., edwards25519 , the sign of the rational map from the twisted Edwards curve to its corresponding Montgomery curve is not given explicitly. In this case, the sign MUST be fixed such that applying the rational map to the twisted Edwards curve's base point yields the Montgomery curve's base point with correct sign. (For edwards25519, see and .) When defining new twisted Edwards curves, a Montgomery equivalent and rational map SHOULD also be specified, and the sign of the rational map SHOULD be stated explicitly.
2. When hashing to a twisted Edwards curve that does not have a standardized Montgomery form or rational map, the map given in SHOULD be used.

Elligator 2 method Preconditions: A twisted Edwards curve E and an equivalent Montgomery curve M meeting the requirements in . Helper functions:

• map_to_curve_elligator2 is the mapping of to the curve M.
• rational_map is a function that takes a point (s, t) on M and returns a point (v, w) on E, as defined in .

Sign of t (and v): for this map, the sign is determined by map_to_curve_elligator2. No further sign adjustments are required. Exceptions: The exceptions for the Elligator 2 mapping are as given in . The exceptions for the rational map are as given in . No other exceptions are possible. The following procedure implements the Elligator 2 mapping for a twisted Edwards curve. (Note that the output point is denoted (v, w) because it is a point on the target twisted Edwards curve.)

Clearing the cofactor The mappings of always output a point on the elliptic curve, i.e., a point in a group of order h * r (). Obtaining a point in G may require a final operation commonly called "clearing the cofactor," which takes as input any point on the curve and produces as output a point in the prime-order (sub)group G (). The cofactor can always be cleared via scalar multiplication by h. For elliptic curves where h = 1, i.e., the curves with a prime number of points, no operation is required. This applies, for example, to the NIST curves P-256, P-384, and P-521 . In some cases, it is possible to clear the cofactor via a faster method than scalar multiplication by h. These methods are equivalent to (but usually faster than) multiplication by some scalar h_eff whose value is determined by the method and the curve. Examples of fast cofactor clearing methods include the following:

• For certain pairing-friendly curves having subgroup G2 over an extension field, Scott et al. describe a method for fast cofactor clearing that exploits an efficiently-computable endomorphism. Fuentes-Castaneda et al. propose an alternative method that is sometimes more efficient. Budroni and Pintore give concrete instantiations of these methods for Barreto-Lynn-Scott pairing-friendly curves . This method is described for the specific case of BLS12-381 in .
• Wahby and Boneh (, Section 5) describe a trick due to Scott for fast cofactor clearing on any elliptic curve for which the prime factorization of h and the structure of the elliptic curve group meet certain conditions.

The clear_cofactor function is parameterized by a scalar h_eff. Specifically, where * represents scalar multiplication. When a curve does not support a fast cofactor clearing method, h_eff = h and the cofactor MUST be cleared via scalar multiplication. When a curve admits a fast cofactor clearing method, clear_cofactor MAY be evaluated either via that method or via scalar multiplication by the equivalent h_eff; these two methods give the same result. Note that in this case scalar multiplication by the cofactor h does not generally give the same result as the fast method, and SHOULD NOT be used.

Suites for hashing This section lists recommended suites for hashing to standard elliptic curves. A hash-to-curve suite fully specifies the procedure for hashing byte strings to points on a specific elliptic curve group. describes how to implement a suite. Applications that require hashing to an elliptic curve should use either an existing suite or a new suite specified as described in . All applications using a hash-to-curve suite MUST choose a domain separation tag (DST) in accordance with the guidelines in . In addition, applications whose security requires a random oracle that returns points on the target curve MUST use a suite whose encoding type is hash_to_curve; see and immediately below for more information. A hash-to-curve suite comprises the following parameters:

• Suite ID, a short name used to refer to a given suite. discusses the naming conventions for suite IDs.
• encoding type, either random oracle (hash_to_curve) or nonuniform (encode_to_curve). See for definitions of these encoding types.
• E, the target elliptic curve over a field F.
• p, the characteristic of the field F.
• m, the extension degree of the field F.
• k, the target security level of the suite in bits. (See for discussion.)
• L, the length parameter for hash_to_field ().
• expand_message, one of the variants specified in plus any parameters required for the specified variant (for example, H, the underlying hash function).
• f, a mapping function from .
• h_eff, the scalar parameter for clear_cofactor ().

In addition to the above parameters, the mapping f may require additional parameters Z, M, rational_map, E', or iso_map. When applicable, these MUST be specified. The below table lists suites RECOMMENDED for some elliptic curves. The corresponding parameters are given in the following subsections. Applications instantiating cryptographic protocols whose security analysis relies on a random oracle MUST NOT use a nonuniform encoding. Moreover, applications that use a nonuniform encoding SHOULD carefully analyze the security implications of nonuniformity. When the required encoding is not clear, applications SHOULD use a random oracle for security.

E	Suites	Section
NIST P-256	P256_XMD:SHA-256_SSWU_RO_ P256_XMD:SHA-256_SSWU_NU_
NIST P-384	P384_XMD:SHA-512_SSWU_RO_ P384_XMD:SHA-512_SSWU_NU_
NIST P-521	P521_XMD:SHA-512_SSWU_RO_ P521_XMD:SHA-512_SSWU_NU_
curve25519	curve25519_XMD:SHA-512_ELL2_RO_ curve25519_XMD:SHA-512_ELL2_NU_
edwards25519	edwards25519_XMD:SHA-512_ELL2_RO_ edwards25519_XMD:SHA-512_ELL2_NU_
curve448	curve448_XMD:SHA-512_ELL2_RO_ curve448_XMD:SHA-512_ELL2_NU_
edwards448	edwards448_XMD:SHA-512_ELL2_RO_ edwards448_XMD:SHA-512_ELL2_NU_
secp256k1	secp256k1_XMD:SHA-256_SSWU_RO_ secp256k1_XMD:SHA-256_SSWU_NU_
BLS12-381 G1	BLS12381G1_XMD:SHA-256_SSWU_RO_ BLS12381G1_XMD:SHA-256_SSWU_NU_
BLS12-381 G2	BLS12381G2_XMD:SHA-256_SSWU_RO_ BLS12381G2_XMD:SHA-256_SSWU_NU_

Implementing a hash-to-curve suite A hash-to-curve suite requires the following functions. Note that some of these require utility functions from .

1. Base field arithmetic operations for the target elliptic curve, e.g., addition, multiplication, and square root.
2. Elliptic curve point operations for the target curve, e.g., point addition and scalar multiplication.
3. The hash-to-field function; see . This includes the expand_message variant () and any constituent hash function or XOF.
4. The suite-specified mapping function; see the corresponding subsection of .
5. A cofactor clearing function; see . This may be implemented as scalar multiplication by h_eff or as a faster equivalent method.
6. The desired encoding function; see . This is either hash_to_curve or encode_to_curve.

Suites for NIST P-256 This section defines ciphersuites for the NIST P-256 elliptic curve . P256_XMD:SHA-256_SSWU_RO_ is defined as follows:

• encoding type: hash_to_curve ()
• E: y^2 = x^3 + A * x + B, where
  • A = -3
  • B = 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b
• p: 2^256 - 2^224 + 2^192 + 2^96 - 1
• m: 1
• k: 128
• expand_message: expand_message_xmd ()
• H: SHA-256
• L: 48
• f: Simplified SWU method,
• Z: -10
• h_eff: 1

P256_XMD:SHA-256_SSWU_NU_ is identical to P256_XMD:SHA-256_SSWU_RO_, except that the encoding type is encode_to_curve (). An optimized example implementation of the Simplified SWU mapping to P-256 is given in .

Suites for NIST P-384 This section defines ciphersuites for the NIST P-384 elliptic curve . P384_XMD:SHA-512_SSWU_RO_ is defined as follows:

• encoding type: hash_to_curve ()
• E: y^2 = x^3 + A * x + B, where
  • A = -3
  • B = 0xb3312fa7e23ee7e4988e056be3f82d19181d9c6efe8141120314088f5013875ac656398d8a2ed19d2a85c8edd3ec2aef
• p: 2^384 - 2^128 - 2^96 + 2^32 - 1
• m: 1
• k: 192
• expand_message: expand_message_xmd ()
• H: SHA-512
• L: 72
• f: Simplified SWU method,
• Z: -12
• h_eff: 1

P384_XMD:SHA-512_SSWU_NU_ is identical to P384_XMD:SHA-512_SSWU_RO_, except that the encoding type is encode_to_curve (). An optimized example implementation of the Simplified SWU mapping to P-384 is given in .

Suites for NIST P-521 This section defines ciphersuites for the NIST P-521 elliptic curve . P521_XMD:SHA-512_SSWU_RO_ is defined as follows:

• encoding type: hash_to_curve ()
• E: y^2 = x^3 + A * x + B, where
  • A = -3
  • B = 0x51953eb9618e1c9a1f929a21a0b68540eea2da725b99b315f3b8b489918ef109e156193951ec7e937b1652c0bd3bb1bf073573df883d2c34f1ef451fd46b503f00
• p: 2^521 - 1
• m: 1
• k: 256
• expand_message: expand_message_xmd ()
• H: SHA-512
• L: 98
• f: Simplified SWU method,
• Z: -4
• h_eff: 1

P521_XMD:SHA-512_SSWU_NU_ is identical to P521_XMD:SHA-512_SSWU_RO_, except that the encoding type is encode_to_curve (). An optimized example implementation of the Simplified SWU mapping to P-521 is given in .

Suites for curve25519 and edwards25519 This section defines ciphersuites for curve25519 and edwards25519 . curve25519_XMD:SHA-512_ELL2_RO_ is defined as follows:

• encoding type: hash_to_curve ()
• E: K * t^2 = s^3 + J * s^2 + s, where
  • J = 486662
  • K = 1
• p: 2^255 - 19
• m: 1
• k: 128
• expand_message: expand_message_xmd ()
• H: SHA-512
• L: 48
• f: Elligator 2 method,
• Z: 2
• h_eff: 8

edwards25519_XMD:SHA-512_ELL2_RO_ is identical to curve25519_XMD:SHA-512_ELL2_RO_, except for the following parameters:

• E: a * v^2 + w^2 = 1 + d * v^2 * w^2, where
  • a = -1
  • d = 0x52036cee2b6ffe738cc740797779e89800700a4d4141d8ab75eb4dca135978a3
• f: Twisted Edwards Elligator 2 method,
• M: curve25519 defined in , Section 4.1
• rational_map: the birational map defined in , Section 4.1

curve25519_XMD:SHA-512_ELL2_NU_ is identical to curve25519_XMD:SHA-512_ELL2_RO_, except that the encoding type is encode_to_curve (). edwards25519_XMD:SHA-512_ELL2_NU_ is identical to edwards25519_XMD:SHA-512_ELL2_RO_, except that the encoding type is encode_to_curve (). Optimized example implementations of the above mappings are given in and .

Suites for curve448 and edwards448 This section defines ciphersuites for curve448 and edwards448 . curve448_XMD:SHA-512_ELL2_RO_ is defined as follows:

• encoding type: hash_to_curve ()
• E: K * t^2 = s^3 + J * s^2 + s, where
  • J = 156326
  • K = 1
• p: 2^448 - 2^224 - 1
• m: 1
• k: 224
• expand_message: expand_message_xmd ()
• H: SHA-512
• L: 84
• f: Elligator 2 method,
• Z: -1
• h_eff: 4

edwards448_XMD:SHA-512_ELL2_RO_ is identical to curve448_XMD:SHA-512_ELL2_RO_, except for the following parameters:

• E: a * v^2 + w^2 = 1 + d * v^2 * w^2, where
  • a = 1
  • d = -39081
• f: Twisted Edwards Elligator 2 method,
• M: curve448, defined in , Section 4.2
• rational_map: the 4-isogeny map defined in , Section 4.2

curve448_XMD:SHA-512_ELL2_NU_ is identical to curve448_XMD:SHA-512_ELL2_RO_, except that the encoding type is encode_to_curve (). edwards448_XMD:SHA-512_ELL2_NU_ is identical to edwards448_XMD:SHA-512_ELL2_RO_, except that the encoding type is encode_to_curve (). Optimized example implementations of the above mappings are given in and .

Suites for secp256k1 This section defines ciphersuites for the secp256k1 elliptic curve . secp256k1_XMD:SHA-256_SSWU_RO_ is defined as follows:

• encoding type: hash_to_curve ()
• E: y^2 = x^3 + 7
• p: 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1
• m: 1
• k: 128
• expand_message: expand_message_xmd ()
• H: SHA-256
• L: 48
• f: Simplified SWU for AB == 0,
• Z: -11
• E': y'^2 = x'^3 + A' * x' + B', where
  • A': 0x3f8731abdd661adca08a5558f0f5d272e953d363cb6f0e5d405447c01a444533
  • B': 1771
• iso_map: the 3-isogeny map from E' to E given in
• h_eff: 1

secp256k1_XMD:SHA-256_SSWU_NU_ is identical to secp256k1_XMD:SHA-256_SSWU_RO_, except that the encoding type is encode_to_curve (). An optimized example implementation of the Simplified SWU mapping to the curve E' isogenous to secp256k1 is given in .

Suites for BLS12-381 This section defines ciphersuites for groups G1 and G2 of the BLS12-381 elliptic curve . The curve parameters in this section match the ones listed in , Appendix C.

BLS12-381 G1 BLS12381G1_XMD:SHA-256_SSWU_RO_ is defined as follows:

• encoding type: hash_to_curve ()
• E: y^2 = x^3 + 4
• p: 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab
• m: 1
• k: 128
• expand_message: expand_message_xmd ()
• H: SHA-256
• L: 64
• f: Simplified SWU for AB == 0,
• Z: 11
• E': y'^2 = x'^3 + A' * x' + B', where
  • A' = 0x144698a3b8e9433d693a02c96d4982b0ea985383ee66a8d8e8981aefd881ac98936f8da0e0f97f5cf428082d584c1d
  • B' = 0x12e2908d11688030018b12e8753eee3b2016c1f0f24f4070a0b9c14fcef35ef55a23215a316ceaa5d1cc48e98e172be0
• iso_map: the 11-isogeny map from E' to E given in
• h_eff: 0xd201000000010001

BLS12381G1_XMD:SHA-256_SSWU_NU_ is identical to BLS12381G1_XMD:SHA-256_SSWU_RO_, except that the encoding type is encode_to_curve (). Note that the h_eff values for these suites are chosen for compatibility with the fast cofactor clearing method described by Scott ( Section 5). An optimized example implementation of the Simplified SWU mapping to the curve E' isogenous to BLS12-381 G1 is given in .

BLS12-381 G2 BLS12381G2_XMD:SHA-256_SSWU_RO_ is defined as follows:

• encoding type: hash_to_curve ()
• E: y^2 = x^3 + 4 * (1 + I)
• base field F is GF(p^m), where
  • p: 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab
  • m: 2
  • (1, I) is the basis for F, where I^2 + 1 == 0 in F
• k: 128
• expand_message: expand_message_xmd ()
• H: SHA-256
• L: 64
• f: Simplified SWU for AB == 0,
• Z: -(2 + I)
• E': y'^2 = x'^3 + A' * x' + B', where
  • A' = 240 * I
  • B' = 1012 * (1 + I)
• iso_map: the isogeny map from E' to E given in
• h_eff: 0xbc69f08f2ee75b3584c6a0ea91b352888e2a8e9145ad7689986ff031508ffe1329c2f178731db956d82bf015d1212b02ec0ec69d7477c1ae954cbc06689f6a359894c0adebbf6b4e8020005aaa95551

BLS12381G2_XMD:SHA-256_SSWU_NU_ is identical to BLS12381G2_XMD:SHA-256_SSWU_RO_, except that the encoding type is encode_to_curve (). Note that the h_eff values for these suites are chosen for compatibility with the fast cofactor clearing method described by Budroni and Pintore (, Section 4.1), and summarized in . An optimized example implementation of the Simplified SWU mapping to the curve E' isogenous to BLS12-381 G2 is given in .

Defining a new hash-to-curve suite The RECOMMENDED way to define a new hash-to-curve suite is:

1. E, F, p, and m are determined by the elliptic curve and its base field.
2. k is an upper bound on the target security level of the suite (). A reasonable choice of k is ceil(log2(r) / 2), where r is the order of the subgroup G of the curve E ().
3. Choose encoding type, either hash_to_curve or encode_to_curve ().
4. Compute L as described in .
5. Choose an expand_message variant from plus any underlying cryptographic primitives (e.g., a hash function H).
6. Choose a mapping following the guidelines in , and select any required parameters for that mapping.
7. Choose h_eff to be either the cofactor of E or, if a fast cofactor clearing method is to be used, a value appropriate to that method as discussed in .
8. Construct a Suite ID following the guidelines in .

When hashing to an elliptic curve not listed in this section, corresponding hash-to-curve suites SHOULD be fully specified as described above.

Suite ID naming conventions Suite IDs MUST be constructed as follows: The fields CURVE_ID, HASH_ID, MAP_ID, and ENC_VAR are ASCII-encoded strings of at most 64 characters each. Fields MUST contain only ASCII characters between 0x21 and 0x7E (inclusive) except that underscore (i.e., 0x5f) is not allowed. As indicated above, each field (including the last) is followed by an underscore ("_", ASCII 0x5f). This helps to ensure that Suite IDs are prefix free. Suite IDs MUST include the final underscore and MUST NOT include any characters after the final underscore. Suite ID fields MUST be chosen as follows:

• CURVE_ID: a human-readable representation of the target elliptic curve.
• HASH_ID: a human-readable representation of the expand_message function and any underlying hash primitives used in hash_to_field (). This field MUST be constructed as follows: EXP_TAG indicates the expand_message variant:
  • "XMD" for expand_message_xmd ().
  • "XOF" for expand_message_xof ().
  HASH_NAME is a human-readable name for the underlying hash primitive. As examples:
  1. For expand_message_xof () with SHAKE-128, HASH_ID is "XOF:SHAKE-128".
  2. For expand_message_xmd () with SHA3-256, HASH_ID is "XMD:SHA3-256".
• MAP_ID: a human-readable representation of the map_to_curve function as defined in . These are defined as follows:
  • "SVDW" for or Shallue and van de Woestijne ().
  • "SSWU" for Simplified SWU (, ).
  • "ELL2" for Elligator 2 (, ).
• ENC_VAR: a string indicating the encoding type and other information. The first two characters of this string indicate whether the suite represents a hash_to_curve or an encode_to_curve operation (), as follows:
  • If ENC_VAR begins with "RO", the suite uses hash_to_curve.
  • If ENC_VAR begins with "NU", the suite uses encode_to_curve.
  • ENC_VAR MUST NOT begin with any other string.
  ENC_VAR MAY also be used to encode other information used to identify variants, for example, a version number. The RECOMMENDED way to do so is to add one or more subfields separated by colons. For example, "RO:V02" is an appropriate ENC_VAR value for the second version of a random-oracle suite, while "RO:V02:FOO01:BAR17" might be used to indicate a variant of that suite.

IANA considerations This document has no IANA actions.

Security considerations describes considerations related to domain separation. See for further discussion. describes considerations for uniformly hashing to field elements; see and for further discussion. Each encoding type () accepts an arbitrary byte string and maps it to a point on the curve sampled from a distribution that depends on the encoding type. It is important to note that using a nonuniform encoding or directly evaluating one of the mappings of produces an output that is easily distinguished from a uniformly random point. Applications that use a nonuniform encoding SHOULD carefully analyze the security implications of nonuniformity. When the required encoding is not clear, applications SHOULD use a random oracle encoding. When the hash_to_curve function () is instantiated with a hash_to_field function that is indifferentiable from a random oracle (), the resulting function is indifferentiable from a random oracle (, , , ). In many cases such a function can be safely used in cryptographic protocols whose security analysis assumes a random oracle that outputs points on an elliptic curve. As Ristenpart et al. discuss in , however, not all security proofs that rely on random oracles continue to hold when those oracles are replaced by indifferentiable functionalities. This limitation should be considered when analyzing the security of protocols relying on the hash_to_curve function. When hashing passwords using any function described in this document, an adversary who learns the output of the hash function (or potentially any intermediate value, e.g., the output of hash_to_field) may be able to carry out a dictionary attack. To mitigate such attacks, it is recommended to first execute a more costly key derivation function (e.g., PBKDF2 or scrypt ) on the password, then hash the output of that function to the target elliptic curve. For collision resistance, the hash underlying the key derivation function should be chosen according to the guidelines listed in . Constant-time implementations of all functions in this document are STRONGLY RECOMMENDED for all uses, to avoid leaking information via side channels. It is especially important to use a constant-time implementation when inputs to an encoding are secret values; in such cases, constant-time implementations are REQUIRED for security against timing attacks (e.g., ). When constant-time implementations are required, all basic operations and utility functions must be implemented in constant time, as discussed in . In some applications (e.g., embedded systems), leakage through other side channels (e.g., power or electromagnetic side channels) may be pertinent. Defending against such leakage is outside the scope of this document, because the nature of the leakage and the appropriate defense depends on the application.

hash_to_field security The hash_to_field function defined in is indifferentiable from a random oracle when expand_message () is modeled as a random oracle. By composability of indifferentiability proofs, this also holds when expand_message is proved indifferentiable from a random oracle relative to an underlying primitive that is modeled as a random oracle. When following the guidelines in , both variants of expand_message defined in that section meet this requirement (see also ). We very briefly sketch the indifferentiability argument for hash_to_field. Notice that each integer mod p that hash_to_field returns (i.e., each element of the vector representation of F) is a member of an equivalence class of roughly 2^k integers of length log2(p) + k bits, all of which are equal modulo p. For each integer mod p that hash_to_field returns, the simulator samples one member of this equivalence class at random and outputs the byte string returned by I2OSP. (Notice that this is essentially the inverse of the hash_to_field procedure.)

expand_message_xmd security The expand_message_xmd function defined in is indifferentiable from a random oracle when one of the following holds:

1. H is indifferentiable from a random oracle,
2. H is a sponge-based hash function whose inner function is modeled as a random transformation or random permutation , or
3. H is a Merkle-Damgaard hash function whose compression function is modeled as a random oracle .

For cases (1) and (2), the indifferentiability of expand_message_xmd follows directly from the indifferentiability of H. For case (3), i.e., for H a Merkle-Damgaard hash function, indifferentiability follows from , Theorem 3.5. In particular, expand_message_xmd computes b_0 by prepending one block of 0-bytes to the message and auxiliary information (length, counter, and DST). Then, each of the output blocks b_i, i >= 1 in expand_message_xmd is the result of invoking H on a unique, prefix-free encoding of b_0. This is true, first, because the length of the input to all such invocations is equal and fixed by the choice of H and DST, and second, because each such input has a unique suffix (because of the inclusion of the counter byte I2OSP(i, 1)). The essential difference between the construction of and expand_message_xmd is that the latter hashes a counter appended to strxor(b_0, b_(i - 1)) (step 10) rather than to b_0. This approach increases the Hamming distance between inputs to different invocations of H, which reduces the likelihood that nonidealities in H affect the distribution of the b_i values. We note that expand_message_xmd can be used to instantiate a general-purpose indifferentiable functionality with variable-length output based on any hash function meeting one of the above criteria. Applications that use expand_message_xmd outside of hash_to_field should ensure domain separation by picking a distinct value for DST.

Domain separation recommendations As discussed in , the purpose of domain separation is to ensure that security analyses of cryptographic protocols that query multiple independent random oracles remain valid even if all of these random oracles are instantiated based on one underlying function H. The expand_message variants in this document () ensure domain separation by appending a suffix-free-encoded domain separation tag DST_prime to all strings hashed by H, an underlying hash or extensible output function. (Other expand_message variants that follow the guidelines in are expected to behave similarly, but these should be analyzed on a case-by-case basis.) For security, applications that use the same function H outside of expand_message should enforce domain separation between those uses of H and expand_message, and should separate all of these from uses of H in other applications. This section suggests four methods for enforcing domain separation from expand_message variants, explains how each method achieves domain separation, and lists the situations in which each is appropriate. These methods share a high-level structure: the application designer fixes a tag DST_ext distinct from DST_prime and augments calls to H with DST_ext. Each method augments calls to H differently, and each may impose additional requirements on DST_ext. These methods can be used to instantiate multiple domain separated functions (e.g., H1 and H2) by selecting distinct DST_ext values for each (e.g., DST_ext1, DST_ext2).

1. (Suffix-only domain separation.) This method is useful when domain separating invocations of H from expand_message_xmd or expand_message_xof. It is not appropriate for domain separating expand_message from HMAC-H ; for that purpose, see method 4. To instantiate a suffix-only domain separated function Hso, compute DST_ext should be suffix-free encoded (e.g., by appending one byte encoding the length of DST_ext) to make it infeasible to find distinct (msg, DST_ext) pairs that hash to the same value. This method ensures domain separation because all distinct invocations of H have distinct suffixes, since DST_ext is distinct from DST_prime.
2. (Prefix-suffix domain separation.) This method can be used in the same cases as the suffix-only method. To instantiate a prefix-suffix domain separated function Hps, compute DST_ext should be prefix-free encoded (e.g., by prepending one byte encoding the length of DST_ext) to make it infeasible to find distinct (msg, DST_ext) pairs that hash to the same value. This method ensures domain separation because appending the byte I2OSP(0, 1) ensures that inputs to H inside Hps are distinct from those inside expand_message. Specifically, the final byte of DST_prime encodes the length of DST, which is required to be nonzero (, requirement 2), and DST_prime is always appended to invocations of H inside expand_message.
3. (Prefix-only domain separation.) This method is only useful for domain separating invocations of H from expand_message_xmd. It does not give domain separation for expand_message_xof or HMAC-H. To instantiate a prefix-only domain separated function Hpo, compute In order for this method to give domain separation, DST_ext should be at least b bits long, where b is the number of bits output by the hash function H. In addition, at least one of the first b bits must be nonzero. Finally, DST_ext should be prefix-free encoded (e.g., by prepending one byte encoding the length of DST_ext) to make it infeasible to find distinct (msg, DST_ext) pairs that hash to the same value. This method ensures domain separation as follows. First, since DST_ext contains at least one nonzero bit among its first b bits, it is guaranteed to be distinct from the value Z_pad (, step 4), which ensures that all inputs to H are distinct from the input used to generate b_0 in expand_message_xmd. Second, since DST_ext is at least b bits long, it is almost certainly distinct from the values b_0 and strxor(b_0, b_(i - 1)), and therefore all inputs to H are distinct from the inputs used to generate b_i, i >= 1, with high probability.
4. (XMD-HMAC domain separation.) This method is useful for domain separating invocations of H inside HMAC-H (i.e., HMAC instantiated with hash function H) from expand_message_xmd. It also applies to HKDF-H , as discussed below. Specifically, this method applies when HMAC-H is used with a non-secret key to instantiate a random oracle based on a hash function H (note that expand_message_xmd can also be used for this purpose; see ). When using HMAC-H with a high-entropy secret key, domain separation is not necessary; see discussion below. To choose a non-secret HMAC key DST_key that ensures domain separation from expand_message_xmd, compute Then, to instantiate the random oracle Hro using HMAC-H, compute The trailing zero byte in DST_key_preimage ensures that this value is distinct from inputs to H inside expand_message_xmd (because all such inputs have suffix DST_prime, which cannot end with a zero byte as discussed above). This ensures domain separation because, with overwhelming probability, all inputs to H inside of HMAC-H using key DST_key have prefixes that are distinct from the values Z_pad, b_0, and strxor(b_0, b_(i - 1)) inside of expand_message_xmd. For uses of HMAC-H that instantiate a private random oracle by fixing a high-entropy secret key, domain separation from expand_message_xmd is not necessary. This is because, similarly to the case above, all inputs to H inside HMAC-H using this secret key almost certainly have distinct prefixes from all inputs to H inside expand_message_xmd. Finally, this method can be used with HKDF-H by fixing the salt input to HKDF-Extract to DST_key, computed as above. This ensures domain separation for HKDF-Extract by the same argument as for HMAC-H using DST_key. Moreover, assuming that the IKM input to HKDF-Extract has sufficiently high entropy (say, commensurate with the security parameter), the HKDF-Expand step is domain separated by the same argument as for HMAC-H with a high-entropy secret key (since PRK is exactly that).

Target security levels Each ciphersuite specifies a target security level (in bits) for the underlying curve. This parameter ensures the corresponding hash_to_field instantiation is conservative and correct. We stress that this parameter is only an upper bound on the security level of the curve, and is neither a guarantee nor endorsement of its suitability for a given application. Mathematical and cryptographic advancements may reduce the effective security level for any curve.

Acknowledgements The authors would like to thank Adam Langley for his detailed writeup of Elligator 2 with Curve25519 ; Dan Boneh, Christopher Patton, Benjamin Lipp, and Leonid Reyzin for educational discussions; and David Benjamin, Frank Denis, Sean Devlin, Justin Drake, Bjoern Haase, Mike Hamburg, Dan Harkins, Thomas Icart, Andy Polyakov, Mamy Ratsimbazafy, Michael Scott, and Mathy Vanhoef for helpful feedback.

Contributors

• Sharon Goldberg Boston University goldbe@cs.bu.edu
• Ela Lee Royal Holloway, University of London Ela.Lee.2010@live.rhul.ac.uk
• Michele Orru michele.orru@ens.fr

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. Pairing-based cryptography, a variant of elliptic curve cryptography, has received attention for its flexible and applicable functionality. Pairing is a special map defined over elliptic curves and it can be applied to construct several cryptographic protocols such as identity-based encryption, attribute-based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security, however, it ensures no more than a 100-bit security level due to the effect of the attack. In this memo, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and classify them in 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely use", we select the recommended pairing-friendly curves considering exTNFS. Informative References Electric Coin Company Standards for Efficient Cryptography Group (SECG) Standards for Efficient Cryptography Group (SECG) National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) STMicroelectronics STMicroelectronics NXP Semiconductors STMicroelectronics University of Luxembourg New York University University of Luxembourg New York University Sagem Securite and Universite du Luxembourg Department of Computer Science, University of Illinois at Chicago, USA Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, The Netherlands Thomson R&D France Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, The Netherlands Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, The Netherlands Universite Bordeaux Universite de Rennes New York University Abu Dhabi Tel Aviv University and KU Leuven Macquarie Universit Macquarie Universit Macquarie Universit University of Texas Ecole Normale Superieure and INRIA Rennes NTT Secure Platform Laboratories Ecole Normale Superieure and INRIA Rennes NTT Secure Platform Laboratories Ecole Normale Superieure and INRIA Rennes Sorbonne Universite NTT Secure Platform Laboratories Universite de Rennes Universite de Rennes Universite Pierre et Marie Curie ISFA, Universite Claude Bernard Lyon 1, Villeurbanne, France CINVESTAV-IPN, San Pedro Zacatenco, Mexico City, Mexico. Escola Politecnica, Universidade de Sao Paulo, Sao Paulo, Brazil Lehrstuhl fur Theoretische Informationstechnik, Rheinisch-Westfalische Technische Hochschule Aachen, Aachen, Germany Institute of Computing, University of Campinas Universite de Rennes 1 and Institut Universitaire de France ENS Rennes NTT Secure Platform Laboratories INRIA NTT Secure Platform Laboratories NTT Secure Platform Laboratories NTT Secure Platform Laboratories Stanford University UC Davis Stanford University Stanford University Stanford University Universidade de Sao Paulo, Brazil Stanford University Dublin City University, Ireland AT&T Bell Laboratories AT&T Bell Laboratories MIT Laboratory for Computer Science Bell Laboratories, Lucent Technologies Bell Laboratories, Lucent Technologies Integrity Sciences, Inc. Westboro, MA. School of Computing Dublin City University, Ballymun. Dublin, Ireland. School of Computing Dublin City University, Ballymun. Dublin, Ireland. School of Computing Dublin City University, Ballymun. Dublin, Ireland. School of Computing Dublin City University, Ballymun. Dublin, Ireland. School of Computing Dublin City University, Ballymun. Dublin, Ireland. Computer Science Department, CINVESTAV-IPN. Mexico Dept. Combinatorics & Optimization, University of Waterloo, Canada Computer Science Department, CINVESTAV-IPN. Mexico University of Bergen, Norway and MIRACL Labs, London, England University of Trento, Italy Department of Computer Science, University of Illinois at Chicago, USA Cryptography Research, a division of Rambus, USA Privacy & Identity lab, Institute for Computing and Information Sciences, Radboud University Nijmegen, The Netherlands Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, The Netherlands Department of Computer Science, University of Illinois at Chicago, USA Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, The Netherlands Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, The Netherlands Department of Mathematics and Computer Science, Technische Universiteit Eindhoven, The Netherlands Department of Mathemetics, University of Warsaw Department of Mathematics, University of Warsaw Department of Mathematics, University of Warsaw Mathematics Department, University of Wisconsin-Madison. Madison, USA. Mathematisch Instituut, Universiteit Leiden. Leiden, The Netherlands. Institute of Mathematics, Jagiellonian University. Poland Ingenico Universite du Luxembourg Universite du Luxembourg TELECOM-ParisTech TELECOM-ParisTech Universite du Luxembourg, Ecole normale superieure Stanford University Stanford University Macquarie Universit Ecole normale superieure Macquarie Universit Ecole normale superieure University of Texas ETH Zurich ETH Zurich ETH Zurich MIT Laboratory for Computer Science Harvard University Department of Applied Science MIT Laboratory for Computer Science Weizmann Institute Weizmann Institute The Sage Developers INRIA Paris INRIA Paris INRIA Paris University of Wisconsin-Madison UC San Diego Portland State University Stanford University IEEE Computer Society IEEE Computer Society BLS is a digital signature scheme with aggregation properties. Given set of signatures (signature_1, ..., signature_n) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use- cases, specifically when minimal storage space or bandwidth are required. A Verifiable Random Function (VRF) is the public-key version of a keyed cryptographic hash. Only the holder of the private key can compute the hash, but anyone with public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies several VRF constructions that are secure in the cryptographic random oracle model. One VRF uses RSA and the other VRF uses Eliptic Curves (EC). An Oblivious Pseudorandom Function (OPRF) is a two-party protocol for computing the output of a PRF. One party (the server) holds the PRF secret key, and the other (the client) holds the PRF input. The 'obliviousness' property ensures that the server does not learn anything about the client's input during the evaluation. The client should also not learn anything about the server's secret PRF key. Optionally, OPRFs can also satisfy a notion 'verifiability' (VOPRF). In this setting, the client can verify that the server's output is indeed the result of evaluating the underlying PRF with just a public key. This document specifies OPRF and VOPRF constructions instantiated within prime-order groups, including elliptic curves. This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures. BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC). This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community. This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema. This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.

Related work The problem of mapping arbitrary bit strings to elliptic curve points has been the subject of both practical and theoretical research. This section briefly describes the background and research results that underly the recommendations in this document. This section is provided for informational purposes only. A naive but generally insecure method of mapping a string msg to a point on an elliptic curve E having n points is to first fix a point P that generates the elliptic curve group, and a hash function Hn from bit strings to integers less than n; then compute Hn(msg) * P, where the * operator represents scalar multiplication. The reason this approach is insecure is that the resulting point has a known discrete log relationship to P. Thus, except in cases where this method is specified by the protocol, it must not be used; doing so risks catastrophic security failures. Boneh et al. describe an encoding method they call MapToGroup, which works roughly as follows: first, use the input string to initialize a pseudorandom number generator, then use the generator to produce a value x in F. If x is the x-coordinate of a point on the elliptic curve, output that point. Otherwise, generate a new value x in F and try again. Since a random value x in F has probability about 1/2 of corresponding to a point on the curve, the expected number of tries is just two. However, the running time of this method depends on the input string, which means that it is not safe to use in protocols sensitive to timing side channels. Schinzel and Skalba introduce a method of constructing elliptic curve points deterministically, for a restricted class of curves and a very small number of points. Skalba generalizes this construction to more curves and more points on those curves. Shallue and van de Woestijne further generalize and simplify Skalba's construction, yielding concretely efficient maps to a constant fraction of the points on almost any curve. Fouque and Tibouchi give a parameterization of this mapping for Barreto-Naehrig pairing-friendly curves . Ulas describes a simpler version of the Shallue-van de Woestijne map, and Brier et al. give a further simplification, which the authors call the "simplified SWU" map. That simplified map applies only to fields of characteristic p = 3 (mod 4); Wahby and Boneh generalize to fields of any characteristic, and give further optimizations. Boneh and Franklin give a deterministic algorithm mapping to certain supersingular curves over fields of characteristic p = 2 (mod 3) . Icart gives another deterministic algorithm which maps to any curve over a field of characteristic p = 2 (mod 3) . Several extensions and generalizations follow this work, including , , , , and . Following the work of Farashahi , Fouque et al. describe a mapping to curves over fields of characteristic p = 3 (mod 4) having a number of points divisible by 4. Bernstein et al. optimize this mapping and describe a related mapping that they call "Elligator 2," which applies to any curve over a field of odd characteristic having a point of order 2. This includes Curve25519 and Curve448, both of which are CFRG-recommended curves . Bernstein et al. extend the Elligator 2 map to a class of supersingular curves over fields of characteristic p = 3 (mod 4). An important caveat regarding all of the above deterministic mapping functions is that none of them map to the entire curve, but rather to some fraction of the points. This means that they cannot be used directly to construct a random oracle that outputs points on the curve. Brier et al. give two solutions to this problem. The first, which Brier et al. prove applies to Icart's method, computes f(H0(msg)) + f(H1(msg)) for two distinct hash functions H0 and H1 from bit strings to F and a mapping f from F to the elliptic curve E. The second, which applies to essentially all deterministic mappings but is more costly, computes f(H0(msg)) + H2(msg) * P, for P a generator of the elliptic curve group and H2 a hash from bit strings to integers modulo r, the order of the elliptic curve group. Farashahi et al. improve the analysis of the first method, showing that it applies to essentially all deterministic mappings. Tibouchi and Kim further refine the analysis and describe additional optimizations. Complementary to the problem of mapping from bit strings to elliptic curve points, Bernstein et al. study the problem of mapping from elliptic curve points to uniformly random bit strings, giving solutions for a class of curves including Montgomery and twisted Edwards curves. Tibouchi and Aranha et al. generalize these results. This document does not deal with this complementary problem.

Rational maps This section gives rational maps that can be used when hashing to twisted Edwards or Montgomery curves. Given a twisted Edwards curve, shows how to derive a corresponding Montgomery curve and how to map from that curve to the twisted Edwards curve. This mapping may be used when hashing to twisted Edwards curves as described in . Given a Montgomery curve, shows how to derive a corresponding Weierstrass curve and how to map from that curve to the Montgomery curve. This mapping can be used to hash to Montgomery or twisted Edwards curves via the Shallue-van de Woestijne () or Simplified SWU () method, as follows:

• For Montgomery curves, first map to the Weierstrass curve, then convert to Montgomery coordinates via the mapping.
• For twisted Edwards curves, compose the Weierstrass to Montgomery mapping with the Montgomery to twisted Edwards mapping () to obtain a Weierstrass curve and a mapping to the target twisted Edwards curve. Map to this Weierstrass curve, then convert to Edwards coordinates via the mapping.

Generic Montgomery to twisted Edwards map This section gives a generic birational map between twisted Edwards and Montgomery curves. The map in this section is a simplified version of the map given in , Theorem 3.2. Specifically, this section's map handles exceptional cases in a simplified way that is geared towards hashing to a twisted Edwards curve's prime-order subgroup. The twisted Edwards curve is birationally equivalent to the Montgomery curve which has the form required by the Elligator 2 mapping of . The coefficients of the Montgomery curve are

• J = 2 * (a + d) / (a - d)
• K = 4 / (a - d)

The rational map from the point (s, t) on the above Montgomery curve to the point (v, w) on the twisted Edwards curve is given by

• v = s / t
• w = (s - 1) / (s + 1)

This mapping is undefined when t == 0 or s == -1, i.e., when the denominator of either of the above rational functions is zero. Implementations MUST detect exceptional cases and return the value (v, w) = (0, 1), which is the identity point on all twisted Edwards curves. The following straight-line implementation of the above rational map handles the exceptional cases. For completeness, we also give the inverse relations. (Note that this map is not required when hashing to twisted Edwards curves.) The coefficients of the twisted Edwards curve corresponding to the above Montgomery curve are

• a = (J + 2) / K
• d = (J - 2) / K

The rational map from the point (v, w) on the twisted Edwards curve to the point (s, t) on the Montgomery curve is given by

• s = (1 + w) / (1 - w)
• t = (1 + w) / (v * (1 - w))

The mapping is undefined when v == 0 or w == 1. When the goal is to map into the prime-order subgroup of the Montgomery curve, it suffices to return the identity point on the Montgomery curve in the exceptional cases.

Weierstrass to Montgomery map The rational map from the point (s, t) on the Montgomery curve to the point (x, y) on the equivalent Weierstrass curve is given by:

• A = (3 - J^2) / (3 * K^2)
• B = (2 * J^3 - 9 * J) / (27 * K^3)
• x = (3 * s + J) / (3 * K)
• y = t / K

The inverse map, from the point (x, y) to the point (s, t), is given by

• s = (3 * K * x - J) / 3
• t = y * K

This mapping can be used to apply the Shallue-van de Woestijne () or Simplified SWU () method to Montgomery curves.

Isogeny maps for suites This section specifies the isogeny maps for the secp256k1 and BLS12-381 suites listed in . These maps are given in terms of affine coordinates. Wahby and Boneh (, Section 4.3) show how to evaluate these maps in a projective coordinate system (), which avoids modular inversions. Refer to the draft repository for a Sage script that constructs these isogenies.

3-isogeny map for secp256k1 This section specifies the isogeny map for the secp256k1 suite listed in . The 3-isogeny map from (x', y') on E' to (x, y) on E is given by the following rational functions:

• x = x_num / x_den, where
  • x_num = k_(1,3) * x'^3 + k_(1,2) * x'^2 + k_(1,1) * x' + k_(1,0)
  • x_den = x'^2 + k_(2,1) * x' + k_(2,0)
• y = y' * y_num / y_den, where
  • y_num = k_(3,3) * x'^3 + k_(3,2) * x'^2 + k_(3,1) * x' + k_(3,0)
  • y_den = x'^3 + k_(4,2) * x'^2 + k_(4,1) * x' + k_(4,0)

The constants used to compute x_num are as follows:

• k_(1,0) = 0x8e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38daaaaa8c7
• k_(1,1) = 0x7d3d4c80bc321d5b9f315cea7fd44c5d595d2fc0bf63b92dfff1044f17c6581
• k_(1,2) = 0x534c328d23f234e6e2a413deca25caece4506144037c40314ecbd0b53d9dd262
• k_(1,3) = 0x8e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38daaaaa88c

The constants used to compute x_den are as follows:

• k_(2,0) = 0xd35771193d94918a9ca34ccbb7b640dd86cd409542f8487d9fe6b745781eb49b
• k_(2,1) = 0xedadc6f64383dc1df7c4b2d51b54225406d36b641f5e41bbc52a56612a8c6d14

The constants used to compute y_num are as follows:

• k_(3,0) = 0x4bda12f684bda12f684bda12f684bda12f684bda12f684bda12f684b8e38e23c
• k_(3,1) = 0xc75e0c32d5cb7c0fa9d0a54b12a0a6d5647ab046d686da6fdffc90fc201d71a3
• k_(3,2) = 0x29a6194691f91a73715209ef6512e576722830a201be2018a765e85a9ecee931
• k_(3,3) = 0x2f684bda12f684bda12f684bda12f684bda12f684bda12f684bda12f38e38d84

The constants used to compute y_den are as follows:

• k_(4,0) = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffff93b
• k_(4,1) = 0x7a06534bb8bdb49fd5e9e6632722c2989467c1bfc8e8d978dfb425d2685c2573
• k_(4,2) = 0x6484aa716545ca2cf3a70c3fa8fe337e0a3d21162f0d6299a7bf8192bfd2a76f

11-isogeny map for BLS12-381 G1 The 11-isogeny map from (x', y') on E' to (x, y) on E is given by the following rational functions:

• x = x_num / x_den, where
  • x_num = k_(1,11) * x'^11 + k_(1,10) * x'^10 + k_(1,9) * x'^9 + ... + k_(1,0)
  • x_den = x'^10 + k_(2,9) * x'^9 + k_(2,8) * x'^8 + ... + k_(2,0)
• y = y' * y_num / y_den, where
  • y_num = k_(3,15) * x'^15 + k_(3,14) * x'^14 + k_(3,13) * x'^13 + ... + k_(3,0)
  • y_den = x'^15 + k_(4,14) * x'^14 + k_(4,13) * x'^13 + ... + k_(4,0)

The constants used to compute x_num are as follows:

• k_(1,0) = 0x11a05f2b1e833340b809101dd99815856b303e88a2d7005ff2627b56cdb4e2c85610c2d5f2e62d6eaeac1662734649b7
• k_(1,1) = 0x17294ed3e943ab2f0588bab22147a81c7c17e75b2f6a8417f565e33c70d1e86b4838f2a6f318c356e834eef1b3cb83bb
• k_(1,2) = 0xd54005db97678ec1d1048c5d10a9a1bce032473295983e56878e501ec68e25c958c3e3d2a09729fe0179f9dac9edcb0
• k_(1,3) = 0x1778e7166fcc6db74e0609d307e55412d7f5e4656a8dbf25f1b33289f1b330835336e25ce3107193c5b388641d9b6861
• k_(1,4) = 0xe99726a3199f4436642b4b3e4118e5499db995a1257fb3f086eeb65982fac18985a286f301e77c451154ce9ac8895d9
• k_(1,5) = 0x1630c3250d7313ff01d1201bf7a74ab5db3cb17dd952799b9ed3ab9097e68f90a0870d2dcae73d19cd13c1c66f652983
• k_(1,6) = 0xd6ed6553fe44d296a3726c38ae652bfb11586264f0f8ce19008e218f9c86b2a8da25128c1052ecaddd7f225a139ed84
• k_(1,7) = 0x17b81e7701abdbe2e8743884d1117e53356de5ab275b4db1a682c62ef0f2753339b7c8f8c8f475af9ccb5618e3f0c88e
• k_(1,8) = 0x80d3cf1f9a78fc47b90b33563be990dc43b756ce79f5574a2c596c928c5d1de4fa295f296b74e956d71986a8497e317
• k_(1,9) = 0x169b1f8e1bcfa7c42e0c37515d138f22dd2ecb803a0c5c99676314baf4bb1b7fa3190b2edc0327797f241067be390c9e
• k_(1,10) = 0x10321da079ce07e272d8ec09d2565b0dfa7dccdde6787f96d50af36003b14866f69b771f8c285decca67df3f1605fb7b
• k_(1,11) = 0x6e08c248e260e70bd1e962381edee3d31d79d7e22c837bc23c0bf1bc24c6b68c24b1b80b64d391fa9c8ba2e8ba2d229

The constants used to compute x_den are as follows:

• k_(2,0) = 0x8ca8d548cff19ae18b2e62f4bd3fa6f01d5ef4ba35b48ba9c9588617fc8ac62b558d681be343df8993cf9fa40d21b1c
• k_(2,1) = 0x12561a5deb559c4348b4711298e536367041e8ca0cf0800c0126c2588c48bf5713daa8846cb026e9e5c8276ec82b3bff
• k_(2,2) = 0xb2962fe57a3225e8137e629bff2991f6f89416f5a718cd1fca64e00b11aceacd6a3d0967c94fedcfcc239ba5cb83e19
• k_(2,3) = 0x3425581a58ae2fec83aafef7c40eb545b08243f16b1655154cca8abc28d6fd04976d5243eecf5c4130de8938dc62cd8
• k_(2,4) = 0x13a8e162022914a80a6f1d5f43e7a07dffdfc759a12062bb8d6b44e833b306da9bd29ba81f35781d539d395b3532a21e
• k_(2,5) = 0xe7355f8e4e667b955390f7f0506c6e9395735e9ce9cad4d0a43bcef24b8982f7400d24bc4228f11c02df9a29f6304a5
• k_(2,6) = 0x772caacf16936190f3e0c63e0596721570f5799af53a1894e2e073062aede9cea73b3538f0de06cec2574496ee84a3a
• k_(2,7) = 0x14a7ac2a9d64a8b230b3f5b074cf01996e7f63c21bca68a81996e1cdf9822c580fa5b9489d11e2d311f7d99bbdcc5a5e
• k_(2,8) = 0xa10ecf6ada54f825e920b3dafc7a3cce07f8d1d7161366b74100da67f39883503826692abba43704776ec3a79a1d641
• k_(2,9) = 0x95fc13ab9e92ad4476d6e3eb3a56680f682b4ee96f7d03776df533978f31c1593174e4b4b7865002d6384d168ecdd0a

The constants used to compute y_num are as follows:

• k_(3,0) = 0x90d97c81ba24ee0259d1f094980dcfa11ad138e48a869522b52af6c956543d3cd0c7aee9b3ba3c2be9845719707bb33
• k_(3,1) = 0x134996a104ee5811d51036d776fb46831223e96c254f383d0f906343eb67ad34d6c56711962fa8bfe097e75a2e41c696
• k_(3,2) = 0xcc786baa966e66f4a384c86a3b49942552e2d658a31ce2c344be4b91400da7d26d521628b00523b8dfe240c72de1f6
• k_(3,3) = 0x1f86376e8981c217898751ad8746757d42aa7b90eeb791c09e4a3ec03251cf9de405aba9ec61deca6355c77b0e5f4cb
• k_(3,4) = 0x8cc03fdefe0ff135caf4fe2a21529c4195536fbe3ce50b879833fd221351adc2ee7f8dc099040a841b6daecf2e8fedb
• k_(3,5) = 0x16603fca40634b6a2211e11db8f0a6a074a7d0d4afadb7bd76505c3d3ad5544e203f6326c95a807299b23ab13633a5f0
• k_(3,6) = 0x4ab0b9bcfac1bbcb2c977d027796b3ce75bb8ca2be184cb5231413c4d634f3747a87ac2460f415ec961f8855fe9d6f2
• k_(3,7) = 0x987c8d5333ab86fde9926bd2ca6c674170a05bfe3bdd81ffd038da6c26c842642f64550fedfe935a15e4ca31870fb29
• k_(3,8) = 0x9fc4018bd96684be88c9e221e4da1bb8f3abd16679dc26c1e8b6e6a1f20cabe69d65201c78607a360370e577bdba587
• k_(3,9) = 0xe1bba7a1186bdb5223abde7ada14a23c42a0ca7915af6fe06985e7ed1e4d43b9b3f7055dd4eba6f2bafaaebca731c30
• k_(3,10) = 0x19713e47937cd1be0dfd0b8f1d43fb93cd2fcbcb6caf493fd1183e416389e61031bf3a5cce3fbafce813711ad011c132
• k_(3,11) = 0x18b46a908f36f6deb918c143fed2edcc523559b8aaf0c2462e6bfe7f911f643249d9cdf41b44d606ce07c8a4d0074d8e
• k_(3,12) = 0xb182cac101b9399d155096004f53f447aa7b12a3426b08ec02710e807b4633f06c851c1919211f20d4c04f00b971ef8
• k_(3,13) = 0x245a394ad1eca9b72fc00ae7be315dc757b3b080d4c158013e6632d3c40659cc6cf90ad1c232a6442d9d3f5db980133
• k_(3,14) = 0x5c129645e44cf1102a159f748c4a3fc5e673d81d7e86568d9ab0f5d396a7ce46ba1049b6579afb7866b1e715475224b
• k_(3,15) = 0x15e6be4e990f03ce4ea50b3b42df2eb5cb181d8f84965a3957add4fa95af01b2b665027efec01c7704b456be69c8b604

The constants used to compute y_den are as follows:

• k_(4,0) = 0x16112c4c3a9c98b252181140fad0eae9601a6de578980be6eec3232b5be72e7a07f3688ef60c206d01479253b03663c1
• k_(4,1) = 0x1962d75c2381201e1a0cbd6c43c348b885c84ff731c4d59ca4a10356f453e01f78a4260763529e3532f6102c2e49a03d
• k_(4,2) = 0x58df3306640da276faaae7d6e8eb15778c4855551ae7f310c35a5dd279cd2eca6757cd636f96f891e2538b53dbf67f2
• k_(4,3) = 0x16b7d288798e5395f20d23bf89edb4d1d115c5dbddbcd30e123da489e726af41727364f2c28297ada8d26d98445f5416
• k_(4,4) = 0xbe0e079545f43e4b00cc912f8228ddcc6d19c9f0f69bbb0542eda0fc9dec916a20b15dc0fd2ededda39142311a5001d
• k_(4,5) = 0x8d9e5297186db2d9fb266eaac783182b70152c65550d881c5ecd87b6f0f5a6449f38db9dfa9cce202c6477faaf9b7ac
• k_(4,6) = 0x166007c08a99db2fc3ba8734ace9824b5eecfdfa8d0cf8ef5dd365bc400a0051d5fa9c01a58b1fb93d1a1399126a775c
• k_(4,7) = 0x16a3ef08be3ea7ea03bcddfabba6ff6ee5a4375efa1f4fd7feb34fd206357132b920f5b00801dee460ee415a15812ed9
• k_(4,8) = 0x1866c8ed336c61231a1be54fd1d74cc4f9fb0ce4c6af5920abc5750c4bf39b4852cfe2f7bb9248836b233d9d55535d4a
• k_(4,9) = 0x167a55cda70a6e1cea820597d94a84903216f763e13d87bb5308592e7ea7d4fbc7385ea3d529b35e346ef48bb8913f55
• k_(4,10) = 0x4d2f259eea405bd48f010a01ad2911d9c6dd039bb61a6290e591b36e636a5c871a5c29f4f83060400f8b49cba8f6aa8
• k_(4,11) = 0xaccbb67481d033ff5852c1e48c50c477f94ff8aefce42d28c0f9a88cea7913516f968986f7ebbea9684b529e2561092
• k_(4,12) = 0xad6b9514c767fe3c3613144b45f1496543346d98adf02267d5ceef9a00d9b8693000763e3b90ac11e99b138573345cc
• k_(4,13) = 0x2660400eb2e4f3b628bdd0d53cd76f2bf565b94e72927c1cb748df27942480e420517bd8714cc80d1fadc1326ed06f7
• k_(4,14) = 0xe0fa1d816ddc03e6b24255e0d7819c171c40f65e273b853324efcd6356caa205ca2f570f13497804415473a1d634b8f

3-isogeny map for BLS12-381 G2 The 3-isogeny map from (x', y') on E' to (x, y) on E is given by the following rational functions:

• x = x_num / x_den, where
  • x_num = k_(1,3) * x'^3 + k_(1,2) * x'^2 + k_(1,1) * x' + k_(1,0)
  • x_den = x'^2 + k_(2,1) * x' + k_(2,0)
• y = y' * y_num / y_den, where
  • y_num = k_(3,3) * x'^3 + k_(3,2) * x'^2 + k_(3,1) * x' + k_(3,0)
  • y_den = x'^3 + k_(4,2) * x'^2 + k_(4,1) * x' + k_(4,0)

The constants used to compute x_num are as follows:

• k_(1,0) = 0x5c759507e8e333ebb5b7a9a47d7ed8532c52d39fd3a042a88b58423c50ae15d5c2638e343d9c71c6238aaaaaaaa97d6 + 0x5c759507e8e333ebb5b7a9a47d7ed8532c52d39fd3a042a88b58423c50ae15d5c2638e343d9c71c6238aaaaaaaa97d6 * I
• k_(1,1) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c6b4f20a4181472aaa9cb8d555526a9ffffffffc71a * I
• k_(1,2) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c6b4f20a4181472aaa9cb8d555526a9ffffffffc71e + 0x8ab05f8bdd54cde190937e76bc3e447cc27c3d6fbd7063fcd104635a790520c0a395554e5c6aaaa9354ffffffffe38d * I
• k_(1,3) = 0x171d6541fa38ccfaed6dea691f5fb614cb14b4e7f4e810aa22d6108f142b85757098e38d0f671c7188e2aaaaaaaa5ed1

The constants used to compute x_den are as follows:

• k_(2,0) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa63 * I
• k_(2,1) = 0xc + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa9f * I

The constants used to compute y_num are as follows:

• k_(3,0) = 0x1530477c7ab4113b59a4c18b076d11930f7da5d4a07f649bf54439d87d27e500fc8c25ebf8c92f6812cfc71c71c6d706 + 0x1530477c7ab4113b59a4c18b076d11930f7da5d4a07f649bf54439d87d27e500fc8c25ebf8c92f6812cfc71c71c6d706 * I
• k_(3,1) = 0x5c759507e8e333ebb5b7a9a47d7ed8532c52d39fd3a042a88b58423c50ae15d5c2638e343d9c71c6238aaaaaaaa97be * I
• k_(3,2) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c6b4f20a4181472aaa9cb8d555526a9ffffffffc71c + 0x8ab05f8bdd54cde190937e76bc3e447cc27c3d6fbd7063fcd104635a790520c0a395554e5c6aaaa9354ffffffffe38f * I
• k_(3,3) = 0x124c9ad43b6cf79bfbf7043de3811ad0761b0f37a1e26286b0e977c69aa274524e79097a56dc4bd9e1b371c71c718b10

The constants used to compute y_den are as follows:

• k_(4,0) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffa8fb + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffa8fb * I
• k_(4,1) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffa9d3 * I
• k_(4,2) = 0x12 + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa99 * I

Straight-line implementations of deterministic mappings This section gives straight-line implementations of the mappings of . These implementations are generic, i.e., they are defined for any curve and field. gives example implementations that are optimized for specific classes of curves and fields.

Shallue-van de Woestijne method This section gives a straight-line implementation of the Shallue and van de Woestijne method for any Weierstrass curve of the form given in . See for information on the constants used in this mapping.

Simplified SWU method This section gives a straight-line implementation of the simplified SWU method for any Weierstrass curve of the form given in . See for information on the constants used in this mapping. gives optimized straight-line procedures that apply to specific classes of curves and base fields.

Elligator 2 method This section gives a straight-line implementation of the Elligator 2 method for any Montgomery curve of the form given in . See for information on the constants used in this mapping. gives optimized straight-line procedures that apply to specific classes of curves and base fields, including curve25519 and curve448 .

Optimized sample code This section gives sample implementations optimized for some of the elliptic curves listed in . Sample Sage code for each algorithm can also be found in the draft repository .

Interface and projective coordinate systems The sample code in this section uses a different interface than the mappings of . Specifically, each mapping function in this section has the following signature: The resulting affine point (x, y) is given by (xn / xd, yn / yd). The reason for this modified interface is that it enables further optimizations when working with points in a projective coordinate system. This is desirable, for example, when the resulting point will be immediately multiplied by a scalar, since most scalar multiplication algorithms operate on projective points. The following are two commonly used projective coordinate systems and the corresponding conversions:

• A point (X, Y, Z) in homogeneous projective coordinates corresponds to the affine point (x, y) = (X / Z, Y / Z); the inverse conversion is given by (X, Y, Z) = (x, y, 1). To convert (xn, xd, yn, yd) to homogeneous projective coordinates, compute (X, Y, Z) = (xn * yd, yn * xd, xd * yd).
• A point (X', Y', Z') in Jacobian projective coordinates corresponds to the affine point (x, y) = (X' / Z'^2, Y' / Z'^3); the inverse conversion is given by (X', Y', Z') = (x, y, 1). To convert (xn, xd, yn, yd) to Jacobian projective coordinates, compute (X', Y', Z') = (xn * xd * yd^2, yn * yd^2 * xd^3, xd * yd).

Simplified SWU

q = 3 (mod 4) The following is a straight-line implementation of the Simplified SWU mapping that applies to any curve over GF(q) where q = 3 (mod 4). This includes the ciphersuites for NIST curves P-256, P-384, and P-521 given in . It also includes the curves isogenous to secp256k1 () and BLS12-381 G1 (). The implementations for these curves differ only in the constants and the base field. The constant definitions below are given in terms of the parameters for the Simplified SWU mapping; for parameter values for the curves listed above, see (P-256), (P-384), (P-521), (E' isogenous to secp256k1), and (E' isogenous to BLS12-381 G1).

q = 5 (mod 8) The following is a straight-line implementation of the Simplified SWU mapping that applied to any curve over GF(q) where q = 5 (mod 8).

q = 9 (mod 16) The following is a straight-line implementation of the Simplified SWU mapping that applies to any curve over GF(q) where q = 9 (mod 16). This includes the curve isogenous to BLS12-381 G2 ().

Elligator 2

curve25519 (q = 5 (mod 8), K = 1) The following is a straight-line implementation of Elligator 2 for curve25519 as specified in . This implementation can also be used for any Montgomery curve with K = 1 over GF(q) where q = 5 (mod 8).

edwards25519 The following is a straight-line implementation of Elligator 2 for edwards25519 as specified in . The subroutine map_to_curve_elligator2_curve25519 is defined in . Note that the sign of the constant c1 below is chosen as specified in , i.e., applying the rational map to the edwards25519 base point yields the curve25519 base point (see erratum ).

curve448 (q = 3 (mod 4), K = 1) The following is a straight-line implementation of Elligator 2 for curve448 as specified in . This implementation can also be used for any Montgomery curve with K = 1 over GF(q) where q = 3 (mod 4).

edwards448 The following is a straight-line implementation of Elligator 2 for edwards448 as specified in . The subroutine map_to_curve_elligator2_curve448 is defined in .

q = 3 (mod 4) The following is a straight-line implementation of Elligator 2 that applies to any curve over GF(q) where q = 3 (mod 4). For curves where K = 1, the implementation given in gives identical results with slightly reduced cost.

q = 5 (mod 8) The following is a straight-line implementation of Elligator 2 that applies to any curve over GF(q) where q = 5 (mod 8). For curves where K = 1, the implementation given in gives identical results with slightly reduced cost.

Cofactor clearing for BLS12-381 G2 The curve BLS12-381, whose parameters are defined in , admits an efficiently-computable endomorphism psi that can be used to speed up cofactor clearing for G2 (see also ). This section implements the endomorphism psi and a fast cofactor clearing method described by Budroni and Pintore . The functions in this section operate on points whose coordinates are represented as ratios, i.e., (xn, xd, yn, yd) corresponds to the point (xn / xd, yn / yd); see for further discussion of projective coordinates. When points are represented in affine coordinates, one can simply ignore the denominators (xd == 1 and yd == 1). The following function computes the Frobenius endomorphism for an element of F = GF(p^2) with basis (1, I), where I^2 + 1 == 0 in F. (This is the base field of the elliptic curve E defined in .) The following function computes the endomorphism psi for points on the elliptic curve E defined in . The following function efficiently computes psi(psi(P)). The following function maps any point on the elliptic curve E () into the prime-order subgroup G2. This function returns a point equal to h_eff * G2, where h_eff is the parameter given in .

Scripts for parameter generation This section gives Sage scripts used to generate parameters for the mappings of .

Finding Z for the Shallue-van de Woestijne map The below function outputs an appropriate Z for the Shallue and van de Woestijne map ().

Finding Z for Simplified SWU The below function outputs an appropriate Z for the Simplified SWU map (). = F[] # Polynomial ring over F g = xx^3 + F(A) * xx + F(B) # y^2 = g(x) = x^3 + A * x + B ctr = F.gen() while True: for Z_cand in (F(ctr), F(-ctr)): if Z_cand.is_square(): # Criterion 1: Z is non-square in F. continue if Z_cand == F(-1): # Criterion 2: Z != -1 in F. continue if not (g - Z_cand).is_irreducible(): # Criterion 3: g(x) - Z is irreducible over F. continue if g(B / (Z_cand * A)).is_square(): # Criterion 4: g(B / (Z * A)) is square in F. return Z_cand ctr += 1 ]]>

Finding Z for Elligator 2 The below function outputs an appropriate Z for the Elligator 2 map ().

sqrt and is_square functions This section defines special-purpose sqrt functions for the three most common cases, q = 3 (mod 4), q = 5 (mod 8), and q = 9 (mod 16), plus a generic constant-time algorithm that works for any prime modulus. In addition, it gives an optimized is_square method for GF(p^2).

q = 3 (mod 4)

q = 5 (mod 8)

q = 9 (mod 16)

Constant-time Tonelli-Shanks algorithm This algorithm is a constant-time version of the classic Tonelli-Shanks algorithm (, Algorithm 1.5.1) due to Sean Bowe, Jack Grigg, and Eirik Ogilvie-Wigley , adapted and optimized by Michael Scott. This algorithm applies to GF(p) for any p. Note, however, that the special-purpose algorithms given in the prior sections are faster, when they apply.

is_square for F = GF(p^2) The following is_square method applies to any field F = GF(p^2) with basis (1, I) represented as described in , i.e., an element x = (x_1, x_2) = x_1 + x_2 * I. Other optimizations of this type are possible in other even-order extension fields; see .

Suite test vectors This section gives test vectors for each suite defined in . The test vectors in this section were generated using code that is available from . Each test vector in this section lists values computed by the appropriate encoding function, with variable names defined as in . For example, for a suite whose encoding type is random oracle, the test vector gives the value for msg, u, Q0, Q1, and the output point P.

NIST P-256

P256_XMD:SHA-256_SSWU_RO_

P256_XMD:SHA-256_SSWU_NU_

NIST P-384

P384_XMD:SHA-512_SSWU_RO_

P384_XMD:SHA-512_SSWU_NU_

NIST P-521

P521_XMD:SHA-512_SSWU_RO_

P521_XMD:SHA-512_SSWU_NU_

curve25519

curve25519_XMD:SHA-512_ELL2_RO_

curve25519_XMD:SHA-512_ELL2_NU_

edwards25519

edwards25519_XMD:SHA-512_ELL2_RO_

edwards25519_XMD:SHA-512_ELL2_NU_

curve448

curve448_XMD:SHA-512_ELL2_RO_

curve448_XMD:SHA-512_ELL2_NU_

edwards448

edwards448_XMD:SHA-512_ELL2_RO_

edwards448_XMD:SHA-512_ELL2_NU_

secp256k1

secp256k1_XMD:SHA-256_SSWU_RO_

secp256k1_XMD:SHA-256_SSWU_NU_

BLS12-381 G1

BLS12381G1_XMD:SHA-256_SSWU_RO_

BLS12381G1_XMD:SHA-256_SSWU_NU_

BLS12-381 G2

BLS12381G2_XMD:SHA-256_SSWU_RO_

BLS12381G2_XMD:SHA-256_SSWU_NU_

Expand test vectors This section gives test vectors for expand_message variants specified in . The test vectors in this section were generated using code that is available from . Each test vector in this section lists the expand_message name, hash function, and DST, along with a series of tuples of the function inputs (msg and len_in_bytes), output (uniform_bytes), and intermediate values (dst_prime and msg_prime). DST and msg are represented as ASCII strings. Intermediate and output values are represented as byte strings in hexadecimal.

expand_message_xmd(SHA-256)

expand_message_xmd(SHA-512)

expand_message_xof(SHAKE-128)