Hashing to Elliptic Curves Cloudflare, Inc.
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, Inc.
101 Townsend St San Francisco United States of America nick@cloudflare.com
Stanford University
rsw@cs.stanford.edu
Cloudflare, Inc.
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. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Discussion Venues Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .
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, where the hashing procedure provides collision resistance and does not reveal the discrete logarithm of the output point. 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. This document represents the consensus of the Crypto Forum Research Group (CFRG).
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. (Note that all choices of basis are isomorphic, but certain choices may result in a more efficient implementation; this document does not make any particular assumptions about choice of basis.) 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 of order n, meaning that the group has n distinct elements. (This document uses additive notation for the elliptic curve group operation.) Elements of an elliptic curve group are points with affine coordinates (x, y) satisfying the curve equation, where x and y are elements of F. In addition, all elliptic curve groups have a distinguished element, the identity point, which acts as the identity element for the group operation. On certain curves (including Weierstrass and Montgomery curves), the identity point cannot be represented as an (x, y) coordinate pair. 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: Summary of symbols and their definitions.
Symbol Meaning Relevance
F,q,p A 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. See for further discussion.
Random oracle encodings A random-oracle encoding satisfies a strong property: it can be proved indifferentiable from a random oracle under a suitable assumption. Both constructions described in are indifferentiable from random oracles when instantiated following the guidelines in this document. The constructions differ in their output distributions: one gives a uniformly random point on the curve, the other gives a point sampled from a nonuniform distribution. A random-oracle encoding with a uniform output distribution is suitable for use in many cryptographic protocols proven secure in the random oracle model. See for further discussion.
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 associated with that protocol (including queries made by adversaries) . 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, meaning that it is safe to treat RO1 and RO2 as independent oracles. In general, domain separation requires defining a distinct injective encoding for each oracle being simulated. In the above example, "RO1" and "RO2" have the same length and thus satisfy this requirement when used as prefixes. The algorithms specified in this document take a different approach to ensuring injectivity; see and for more details.
Encoding byte strings to elliptic curves This section presents a general framework and interface for encoding byte strings to points on an elliptic curve. The constructions in this section rely on three basic functions:
  • The function hash_to_field hashes arbitrary-length byte strings to a list of one or more elements of a finite field F; its implementation is defined in . hash_to_field(msg, count) 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: defined in Section 5.
  • The function map_to_curve 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. map_to_curve(u) Input: u, an element of field F. Output: Q, a point on the elliptic curve E. Steps: defined in Section 6.
  • The function clear_cofactor sends any point on the curve E to the subgroup G of E. describes methods to perform this operation. clear_cofactor(Q) Input: Q, a point on the elliptic curve E. Output: P, a point in G. Steps: defined in Section 7.
The two encodings () defined in this section have the same interface and are both random-oracle encodings (). Both are implemented as a composition of the three basic functions above. The difference between the two is that their outputs are sampled from different distributions:
  • encode_to_curve is a nonuniform encoding from byte strings to points in G. That is, the distribution of its output is not uniformly random in G: the set of possible outputs of encode_to_curve is only a fraction of the points in G, and some points in this set are more likely to be output than others. gives a more precise definition of encode_to_curve's output distribution. encode_to_curve(msg) Input: msg, an arbitrary-length byte string. Output: P, a point in G. Steps: 1. u = hash_to_field(msg, 1) 2. Q = map_to_curve(u[0]) 3. P = clear_cofactor(Q) 4. return P
  • hash_to_curve is a uniform encoding from byte strings to points in G. That is, the distribution of its output is statistically close to uniform in G. This function is suitable for most applications requiring a random oracle returning points in G, when instantiated with any of the map_to_curve functions described in . See for further discussion. hash_to_curve(msg) Input: msg, an arbitrary-length byte string. Output: P, a point in G. Steps: 1. u = hash_to_field(msg, 2) 2. Q0 = map_to_curve(u[0]) 3. Q1 = map_to_curve(u[1]) 4. R = Q0 + Q1 # Point addition 5. P = clear_cofactor(R) 6. return P
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, each for a different curve. 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. The example tags given above are assumed to be ASCII-encoded byte strings without null termination, which is the RECOMMENDED format. Other encodings can be used, but in all cases the encoding as a sequence of bytes MUST be specified unambiguously.
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: in brief, this means that execution time and memory access patterns SHOULD NOT depend on the values of secret inputs, intermediate values, or outputs. For such constant-time implementations, all arithmetic, comparisons, and assignments MUST also 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 is_square(x) := { True, if x^((q - 1) / 2) is 0 or 1 in F; { False, otherwise. 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 (except when x = 0). 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. A straightforward way to implement inv0 in constant time is to compute inv0(x) := x^(q - 2). Notice that on input 0, the output is 0 as required. Certain fields may allow faster inversion methods; detailed discussion of such methods is beyond the scope of this document.
  • I2OSP and OS2IP: These functions are used to convert a byte string to and from a non-negative integer as described in . (Note that these functions operate on byte strings in big-endian byte order.)
  • 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). The definition of the sgn0 function for extension fields relies on the polynomial basis or vector representation of field elements, and iterates over the entire vector representation of the input element. As a result, sgn0 depends on the primitive polynomial used to define the polynomial basis; see for more information about this basis, and see for a discussion of representing elements of extension fields as vectors. sgn0(x) Parameters: - F, a finite field of characteristic p and order q = p^m. - p, the characteristic of F (see immediately above). - m, the extension degree of F, m >= 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 When m == 1, sgn0 can be significantly simplified: sgn0_m_eq_1(x) Input: x, an element of GF(p). Output: 0 or 1. Steps: 1. return x mod 2 The case m == 2 is only slightly more complicated: sgn0_m_eq_2(x) Input: x, an element of GF(p^2). Output: 0 or 1. Steps: 1. sign_0 = x_0 mod 2 2. zero_0 = x_0 == 0 3. sign_1 = x_1 mod 2 4. s = sign_0 OR (zero_0 AND sign_1) # Avoid short-circuit logic ops 5. return s
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 extendable-output functions such as SHAKE128 . Security considerations for each expand_message variant are discussed below (, ). Implementors MUST NOT use rejection sampling to generate a uniformly random element of F, to ensure that the hash_to_field function is amenable to constant-time implementation. 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. This means that any hash_to_field function based on rejection sampling would be incompatible with constant-time implementation. The hash_to_field function is also suitable for securely hashing to scalars. For example, when hashing to the scalar field for an elliptic curve (sub)group with prime order r, it suffices to instantiate hash_to_field with target field GF(r).
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.
Efficiency considerations in extension fields The hash_to_field function described in this section is inefficient for certain extension fields. Specifically, when hashing to an element of the extension field GF(p^m), hash_to_field requires expanding msg into m * L bytes (for L as defined above). For extension fields where log2(p) is significantly smaller than the security level k, this approach is inefficient: it requires expand_message to output roughly m * log2(p) + m * k bits, whereas m * log2(p) + k bytes suffices to generate an element of GF(p^m) with bias at most 2^-k. In such cases, an applications MAY use an alternative hash_to_field function, provided it meets the following security requirements:
  • The function MUST output field element(s) that are uniformly random except with bias at most 2^-k.
  • The function MUST NOT use rejection sampling.
  • The function SHOULD be amenable to straight line implementations.
For example, Pornin describes a method for hashing to GF(9767^19) that meets these requirements while using fewer output bits from expand_message than hash_to_field would for that field.
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. Note that hash_to_field may fail (abort) if expand_message fails. hash_to_field(msg, count) Parameters: - DST, a domain separation tag (see Section 3.1). - F, a finite field of characteristic p and order q = p^m. - p, the characteristic of F (see immediately above). - m, the extension degree of F, m >= 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 Section 5.4). 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 extendable-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, and b MUST be divisible by 8. The first requirement ensures k-bit collision resistance; the second ensures uniformity of expand_message_xmd's output.
  • 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 hash function H is assumed to work by repeatedly ingesting fixed-length blocks of data. The length in bits of these blocks is called the input block size (s). As examples, s = 1024 for SHA-512 and s = 576 for SHA3-512 . For correctness, H requires b <= s. The following procedure implements expand_message_xmd. expand_message_xmd(msg, DST, len_in_bytes) Parameters: - H, a hash function (see requirements above). - b_in_bytes, b / 8 for b the output size of H in bits. For example, for b = 256, b_in_bytes = 32. - s_in_bytes, the input block size of H, measured in bytes (see discussion above). For example, for SHA-256, s_in_bytes = 64. Input: - msg, a byte string. - DST, a byte string of at most 255 bytes. See below for information on using longer DSTs. - len_in_bytes, the length of the requested output in bytes, not greater than the lesser of (255 * b_in_bytes) or 2^16-1. Output: - uniform_bytes, a byte string. Steps: 1. ell = ceil(len_in_bytes / b_in_bytes) 2. ABORT if ell > 255 or len_in_bytes > 65535 or len(DST) > 255 3. DST_prime = DST || I2OSP(len(DST), 1) 4. Z_pad = I2OSP(0, s_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 (step 6) is prefixed to msg before 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 extendable-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, SHAKE128 would be an appropriate choice. The following procedure implements expand_message_xof. expand_message_xof(msg, DST, len_in_bytes) Parameters: - H(m, d), an extendable-output function that processes input message m and returns d bytes. Input: - msg, a byte string. - DST, a byte string of at most 255 bytes. See below for information on using longer DSTs. - len_in_bytes, the length of the requested output in bytes. Output: - uniform_bytes, a byte string. Steps: 1. ABORT if len_in_bytes > 65535 or len(DST) > 255 2. DST_prime = DST || I2OSP(len(DST), 1) 3. msg_prime = msg || I2OSP(len_in_bytes, 2) || DST_prime 4. uniform_bytes = H(msg_prime, len_in_bytes) 5. return uniform_bytes
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 DST = H("H2C-OVERSIZE-DST-" || a_very_long_DST)
  • For expand_message_xof using extendable-output function H, DST is computed as DST = H("H2C-OVERSIZE-DST-" || a_very_long_DST, ceil(2 * k / 8))
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 added either as a prefix or a suffix of the input to each invocation of H. Adding DST as a suffix 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 uniform 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: (x, y) = map_to_curve(u) 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, however, that the point (x, y) is not a uniformly random point.
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 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 y^2 = g(x) = x^3 + A * x + B 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: 1. tv1 = u^2 * g(Z) 2. tv2 = 1 + tv1 3. tv1 = 1 - tv1 4. tv3 = inv0(tv1 * tv2) 5. tv4 = sqrt(-g(Z) * (3 * Z^2 + 4 * A)) # can be precomputed 6. If sgn0(tv4) == 1, set tv4 = -tv4 # sgn0(tv4) MUST equal 0 7. tv5 = u * tv1 * tv3 * tv4 8. tv6 = -4 * g(Z) / (3 * Z^2 + 4 * A) # can be precomputed 9. x1 = -Z / 2 - tv5 10. x2 = -Z / 2 + tv5 11. x3 = Z + tv6 * (tv2^2 * tv3)^2 12. If is_square(g(x1)), set x = x1 and y = sqrt(g(x1)) 13. Else If is_square(g(x2)), set x = x2 and y = sqrt(g(x2)) 14. Else set x = x3 and y = sqrt(g(x3)) 15. If sgn0(u) != sgn0(y), set y = -y 16. return (x, y) 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: 1. tv1 = inv0(Z^2 * u^4 + Z * u^2) 2. x1 = (-B / A) * (1 + tv1) 3. If tv1 == 0, set x1 = B / (Z * A) 4. gx1 = x1^3 + A * x1 + B 5. x2 = Z * u^2 * x1 6. gx2 = x2^3 + A * x2 + B 7. If is_square(gx1), set x = x1 and y = sqrt(gx1) 8. Else set x = x2 and y = sqrt(gx2) 9. If sgn0(u) != sgn0(y), set y = -y 10. return (x, y) gives a general and optimized straight-line implementation of this mapping. 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 y'^2 = g'(x') = x'^3 + A' * x' + B' 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: 1. (x', y') = map_to_curve_simple_swu(u) # (x', y') is on E' 2. (x, y) = iso_map(x', y') # (x, y) is on E 3. return (x, y) 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 K * t^2 = s^3 + J * s^2 + s
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: 1. x1 = -(J / K) * inv0(1 + Z * u^2) 2. If x1 == 0, set x1 = -(J / K) 3. gx1 = x1^3 + (J / K) * x1^2 + x1 / K^2 4. x2 = -x1 - (J / K) 5. gx2 = x2^3 + (J / K) * x2^2 + x2 / K^2 6. If is_square(gx1), set x = x1, y = sqrt(gx1) with sgn0(y) == 1. 7. Else set x = x2, y = sqrt(gx2) with sgn0(y) == 0. 8. s = x * K 9. t = y * K 10. return (s, t) 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 a * v^2 + w^2 = 1 + d * v^2 * w^2 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.) map_to_curve_elligator2_edwards(u) Input: u, an element of F. Output: (v, w), a point on E. 1. (s, t) = map_to_curve_elligator2(u) # (s, t) is on M 2. (v, w) = rational_map(s, t) # (v, w) is on E 3. return (v, w)
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, clear_cofactor(P) := h_eff * P 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 uniformly random 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 uniform (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. If m > 1, the suite MUST also specify the polynomial basis used to represent extension field elements.
  • 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 that outputs points with a uniform distribution 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 uniform encoding for security. Suites for hashing to elliptic curves.
E Suites Section
NIST P-256 P256_XMD:SHA-256_SSWU_RO_ P256_XMD:SHA-256_SSWU_NU_
NIST P-384 P384_XMD:SHA-384_SSWU_RO_ P384_XMD:SHA-384_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_XOF:SHAKE256_ELL2_RO_ curve448_XOF:SHAKE256_ELL2_NU_
edwards448 edwards448_XOF:SHAKE256_ELL2_RO_ edwards448_XOF:SHAKE256_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-384_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-384
  • L: 72
  • f: Simplified SWU method ()
  • Z: -12
  • h_eff: 1
P384_XMD:SHA-384_SSWU_NU_ is identical to P384_XMD:SHA-384_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 . Note that these ciphersuites SHOULD NOT be used when hashing to ristretto255 . See for information on how to hash to that group. 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 . Note that these ciphersuites SHOULD NOT be used when hashing to decaf448 . See for information on how to hash to that group. curve448_XOF:SHAKE256_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_xof ()
  • H: SHAKE256
  • L: 84
  • f: Elligator 2 method ()
  • Z: -1
  • h_eff: 4
edwards448_XOF:SHAKE256_ELL2_RO_ is identical to curve448_XOF:SHAKE256_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_XOF:SHAKE256_ELL2_NU_ is identical to curve448_XOF:SHAKE256_ELL2_RO_, except that the encoding type is encode_to_curve (). edwards448_XOF:SHAKE256_ELL2_NU_ is identical to edwards448_XOF:SHAKE256_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 SHAKE128, HASH_ID is "XOF:SHAKE128".
    2. For expand_message_xmd () with SHA3-256, HASH_ID is "XMD:SHA3-256".
    Suites that use an alternative hash_to_field function that meets the requirements in MUST indicate this by appending a tag identifying that function to the HASH_ID field, separated by a colon (":", ASCII 0x3A).
  • 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 uniform encoding 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 uniform encoding. Both encodings given in can output the identity element of the group G. The probability that either encoding function outputs the identity element is roughly 1/r for a random input, which is negligible for cryptographically useful elliptic curves. Further, it is computationally infeasible to find an input to either encoding function whose corresponding output is the identity element. (Both of these properties hold when the encoding functions are instantiated with a hash_to_field function that follows all guidelines in .) Protocols that use these encoding functions SHOULD NOT add a special case to detect and "fix" the identity element. 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 uniformly random 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 , scrypt , or Argon2 ) 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 depend on the application.
encode_to_curve: output distribution and indifferentiability The encode_to_curve function () returns points sampled from a distribution that is statistically far from uniform. This distribution is bounded roughly as follows: first, it includes at least one eighth of the points in G, and second, the probability of points in the distribution varies by at most a factor of four. These bounds hold when encode_to_curve is instantiated with any of the map_to_curve functions in . The bounds above are derived from several works in the literature. Specifically:
  • Shallue and van de Woestijne and Fouque and Tibouchi derive bounds on the Shallue-van de Woestijne mapping ().
  • Fouque and Tibouchi and Tibouchi derive bounds for the Simplified SWU mapping (, ).
  • Bernstein et al. derive bounds for the Elligator 2 mapping (, ).
Indifferentiability of encode_to_curve follows from an argument similar to the one given by Brier et al. ; we briefly sketch. Consider an ideal random oracle Hc() that samples from the distribution induced by the map_to_curve function called by encode_to_curve, and assume for simplicity that the target elliptic curve has cofactor 1 (a similar argument applies for non-unity cofactors). Indifferentiability holds just if it is possible to efficiently simulate the "inner" random oracle in encode_to_curve, namely, hash_to_field. The simulator works as follows: on a fresh query msg, the simulator queries Hc(msg) and receives a point P in the image of map_to_curve (if msg is the same as a prior query, the simulator just returns the value it gave in response to that query). The simulator then computes the possible preimages of P under map_to_curve, i.e., elements u of F such that map_to_curve(u) == P (Tibouchi shows that this can be done efficiently for the Shallue-van de Woestijne and Simplified SWU maps, and Bernstein et al. show the same for Elligator 2). The simulator selects one such preimage at random and returns this value as the simulated output of the "inner" random oracle. By hypothesis, Hc() samples from the distribution induced by map_to_curve on a uniformly random input element of F, so this value is uniformly random and induces the correct point P when passed through map_to_curve.
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 prefixing the message with one block of 0-bytes plus 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 extendable-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 adding a one-byte prefix that encodes 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 adding a one-byte prefix that encodes 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, Daniel Bourdrez, Frank Denis, Sean Devlin, Justin Drake, Bjoern Haase, Mike Hamburg, Dan Harkins, Daira Hopwood, Thomas Icart, Andy Polyakov, Thomas Pornin, Mamy Ratsimbazafy, Michael Scott, Filippo Valsorda, and Mathy Vanhoef for helpful reviews and 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 RFC 7748, Errata ID 4730 Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. PKCS #1: RSA Cryptography Specifications Version 2.2 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. Elliptic Curves for Security 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-Friendly Curves Infours NTT NTT Stanford University Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using 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 the 100-bit security level due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and classify them in the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. Informative References BLS12-381: New zk-SNARK Elliptic Curve Construction Electric Coin Company Random oracles are practical: a paradigm for designing efficient protocols UC San Diego UC Davis SEC 1: Elliptic Curve Cryptography Standards for Efficient Cryptography Group (SECG) SEC 2: Recommended Elliptic Curve Domain Parameters Standards for Efficient Cryptography Group (SECG) Secure Hash Standard (SHS) National Institute of Standards and Technology (NIST) FIPS Publication 186-4: Digital Signature Standard National Institute of Standards and Technology (NIST) SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions National Institute of Standards and Technology (NIST) On the Indifferentiability of the Sponge Construction STMicroelectronics STMicroelectronics NXP Semiconductors STMicroelectronics Merkle-Damgaard Revisited: How to Construct a Hash Function University of Luxembourg New York University University of Luxembourg New York University BLAKE2X How to Hash into Elliptic Curves Sagem Securite and Universite du Luxembourg Twisted Edwards curves 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 The geometry of flex tangents to a cubic curve and its parameterizations Universite Bordeaux Universite de Rennes Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd New York University Abu Dhabi Tel Aviv University and KU Leuven Hashing into Hessian curves Macquarie Universit On hashing into elliptic curves Macquarie Universit Macquarie Universit University of Texas Estimating the size of the image of deterministic hash functions to elliptic curves. Ecole Normale Superieure and INRIA Rennes NTT Secure Platform Laboratories Indifferentiable Hashing to Barreto-Naehrig Curves Ecole Normale Superieure and INRIA Rennes NTT Secure Platform Laboratories Injective encodings to elliptic curves Ecole Normale Superieure and INRIA Rennes Sorbonne Universite NTT Secure Platform Laboratories Encoding points on hyperelliptic curves over finite fields in deterministic polynomial time Universite de Rennes Universite de Rennes Universite Pierre et Marie Curie Square Root Computation over Even Extension Fields ISFA, Universite Claude Bernard Lyon 1, Villeurbanne, France CINVESTAV-IPN, San Pedro Zacatenco, Mexico City, Mexico. Pairing-Friendly Elliptic Curves of Prime Order Escola Politecnica, Universidade de Sao Paulo, Sao Paulo, Brazil Lehrstuhl fur Theoretische Informationstechnik, Rheinisch-Westfalische Technische Hochschule Aachen, Aachen, Germany Binary Elligator squared Institute of Computing, University of Campinas Universite de Rennes 1 and Institut Universitaire de France ENS Rennes NTT Secure Platform Laboratories INRIA Elligator squared: Uniform points on elliptic curves of prime order as uniform random strings NTT Secure Platform Laboratories Improved elliptic curve hashing and point representation NTT Secure Platform Laboratories NTT Secure Platform Laboratories Identity-based encryption from the Weil pairing Stanford University UC Davis Short signatures from the Weil pairing Stanford University Stanford University Stanford University Constructing Elliptic Curves with Prescribed Embedding Degrees Universidade de Sao Paulo, Brazil Stanford University Dublin City University, Ireland Encrypted key exchange: Password-based protocols secure against dictionary attacks AT&T Bell Laboratories AT&T Bell Laboratories Provably secure password-authenticated key exchange using Diffie-Hellman MIT Laboratory for Computer Science Bell Laboratories, Lucent Technologies Bell Laboratories, Lucent Technologies Strong password-only authenticated key exchange Integrity Sciences, Inc. Westboro, MA. Hashing to Elliptic Curves - GitHub repository zkcrypto/jubjub - fq.rs Implementing Elligator for Curve25519 Fast Hashing to G2 on Pairing-Friendly Curves 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. Fast Hashing to G2 on Pairing-Friendly Curves Computer Science Department, CINVESTAV-IPN. Mexico Dept. Combinatorics & Optimization, University of Waterloo, Canada Computer Science Department, CINVESTAV-IPN. Mexico Efficient hash maps to G2 on BLS curves University of Bergen, Norway and MIRACL Labs, London, England University of Trento, Italy Elligator: elliptic-curve points indistinguishable from uniform random strings 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 Quantum circuits for the CSIDH: optimizing quantum evaluation of isogenies 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 On equations y^2 = x^n + k in a finite field. Department of Mathemetics, University of Warsaw Department of Mathematics, University of Warsaw Points on elliptic curves over finite fields Department of Mathematics, University of Warsaw Construction of rational points on elliptic curves over finite fields Mathematics Department, University of Wisconsin-Madison. Madison, USA. Mathematisch Instituut, Universiteit Leiden. Leiden, The Netherlands. Rational points on certain hyperelliptic curves over finite fields Institute of Mathematics, Jagiellonian University. Poland Efficient Indifferentiable Hashing into Ordinary Elliptic Curves Ingenico Universite du Luxembourg Universite du Luxembourg TELECOM-ParisTech TELECOM-ParisTech Universite du Luxembourg, Ecole normale superieure Elliptic curves: Number theory and cryptography A Course in Computational Algebraic Number Theory Handbook of Elliptic and Hyperelliptic Curve Cryptography Handbook of Applied Cryptography Fast and simple constant-time hashing to the BLS12-381 elliptic curve Stanford University Stanford University Indifferentiable deterministic hashing to elliptic and hyperelliptic curves Macquarie Universit Ecole normale superieure Macquarie Universit Ecole normale superieure University of Texas Indifferentiability, impossibility results on reductions, and applications to the random oracle methodology ETH Zurich ETH Zurich ETH Zurich Verifiable Random Functions MIT Laboratory for Computer Science Harvard University Department of Applied Science MIT Laboratory for Computer Science Number-theoretic constructions of efficient pseudo-random functions Weizmann Institute Weizmann Institute Elliptic Curves Over Finite Fields and the Computation of Square Roots mod p SageMath, the Sage Mathematics Software System The Sage Developers A Mechanised Proof of the WireGuard Virtual Private Network Protocol INRIA Paris INRIA Paris INRIA Paris Complete addition formulas for prime order elliptic curves Radboud University Microsoft Research Radboud University Careful with Composition: Limitations of the Indifferentiability Framework University of Wisconsin-Madison UC San Diego Portland State University An explicit, generic parameterization for the Shallue--van de Woestijne map Stanford University IEEE Standard Specification for Password-Based Public-Key Cryptography Techniques IEEE Computer Society IEEE Standard Specifications for Public-Key Cryptography---Amendment 1: Additional Techniques IEEE Computer Society Mersenne twister: A 623-dimensionally equidistributed uniform pseudo-random number generator Efficient Elliptic Curve Operations On Microcontrollers With Finite Field Extensions NCC Group Indifferentiable hashing from Elligator 2 Rambus Inc BLS Signatures Stanford University University of Waterloo Stanford University NTT Research and ENS Algorand 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. Verifiable Random Functions (VRFs) Boston University Boston University and Algorand Hong Kong University of Science and Technology NS1 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 the 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 based on RSA and Elliptic Curves that are secure in the cryptographic random oracle model. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups Brave Software Cloudflare, Inc. Cloudflare, Inc. Cloudflare, Inc. An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between client and server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF secret key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF secret key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially-oblivious, called a POPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF instantiated within standard prime-order groups, including elliptic curves. The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) 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). The ristretto255 and decaf448 Groups This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448. PKCS #5: Password-Based Cryptography Specification Version 2.0 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. The scrypt Password-Based Key Derivation Function 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. Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications University of Luxembourg University of Luxembourg ABDK Consulting SJD AB This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. HMAC: Keyed-Hashing for Message Authentication 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 HMAC-based Extract-and-Expand Key Derivation Function (HKDF) 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.
Hashing to ristretto255 ristretto255 provides a prime-order group based on Curve25519 . This section describes hash_to_ristretto255, which implements a random-oracle encoding to this group that has a uniform output distribution () and the same security properties and interface as the hash_to_curve function (). The ristretto255 API defines a one-way map (, Section 4.3.4); this section refers to that map as ristretto255_map. The hash_to_ristretto255 function MUST be instantiated with an expand_message function that conforms to the requirements given in . In addition, it MUST use a domain separation tag constructed as described in , and all domain separation recommendations given in apply when implementing protocols that use hash_to_ristretto255. hash_to_ristretto255(msg) Parameters: - DST, a domain separation tag (see discussion above). - expand_message, a function that expands a byte string and domain separation tag into a uniformly random byte string (see discussion above). - ristretto255_map, the one-way map from the ristretto255 API. Input: msg, an arbitrary-length byte string. Output: P, an element of the ristretto255 group. Steps: 1. uniform_bytes = expand_message(msg, DST, 64) 2. P = ristretto255_map(uniform_bytes) 3. return P Since hash_to_ristretto255 is not a hash-to-curve suite, it does not have a Suite ID. If a similar identifier is needed, it MUST be constructed following the guidelines in , with the following parameters:
  • CURVE_ID: "ristretto255"
  • HASH_ID: as described in
  • MAP_ID: "R255MAP"
  • ENC_VAR: "RO"
For example, if expand_message is expand_message_xmd using SHA-512, the REQUIRED identifier is:
Hashing to decaf448 Similar to ristretto255, decaf448 provides a prime-order group based on Curve448 . This section describes hash_to_decaf448, which implements a random-oracle encoding to this group that has a uniform output distribution () and the same security properties and interface as the hash_to_curve function (). The decaf448 API defines a one-way map (, Section 5.3.4); this section refers to that map as decaf448_map. The hash_to_decaf448 function MUST be instantiated with an expand_message function that conforms to the requirements given in . In addition, it MUST use a domain separation tag constructed as described in , and all domain separation recommendations given in apply when implementing protocols that use hash_to_decaf448. hash_to_decaf448(msg) Parameters: - DST, a domain separation tag (see discussion above). - expand_message, a function that expands a byte string and domain separation tag into a uniformly random byte string (see discussion above). - decaf448_map, the one-way map from the decaf448 API. Input: msg, an arbitrary-length byte string. Output: P, an element of the decaf448 group. Steps: 1. uniform_bytes = expand_message(msg, DST, 112) 2. P = decaf448_map(uniform_bytes) 3. return P Since hash_to_decaf448 is not a hash-to-curve suite, it does not have a Suite ID. If a similar identifier is needed, it MUST be constructed following the guidelines in , with the following parameters:
  • CURVE_ID: "decaf448"
  • HASH_ID: as described in
  • MAP_ID: "D448MAP"
  • ENC_VAR: "RO"
For example, if expand_message is expand_message_xof using SHAKE256, the REQUIRED identifier is:
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 a * v^2 + w^2 = 1 + d * v^2 * w^2 is birationally equivalent to the Montgomery curve K * t^2 = s^3 + J * s^2 + s 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. edw_to_monty_generic(s, t) Input: (s, t), a point on the curve K * t^2 = s^3 + J * s^2 + s. Output: (v, w), a point on an equivalent twisted Edwards curve. 1. tv1 = s + 1 2. tv2 = tv1 * t # (s + 1) * t 3. tv2 = inv0(tv2) # 1 / ((s + 1) * t) 4. v = tv2 * tv1 # 1 / t 5. v = v * s # s / t 6. w = tv2 * t # 1 / (s + 1) 7. tv1 = s - 1 8. w = w * tv1 # (s - 1) / (s + 1) 9. e = tv2 == 0 10. w = CMOV(w, 1, e) # handle exceptional case 11. return (v, w) 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 K * t^2 = s^3 + J * s^2 + s to the point (x, y) on the equivalent Weierstrass curve y^2 = x^3 + A * x + B 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 further 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. Note that the constant c3 below MUST be chosen such that sgn0(c3) = 0. In other words, if the square-root computation returns a value cx such that sgn0(cx) = 1, set c3 = -cx; otherwise, set c3 = cx. map_to_curve_svdw(u) Input: u, an element of F. Output: (x, y), a point on E. Constants: 1. c1 = g(Z) 2. c2 = -Z / 2 3. c3 = sqrt(-g(Z) * (3 * Z^2 + 4 * A)) # sgn0(c3) MUST equal 0 4. c4 = -4 * g(Z) / (3 * Z^2 + 4 * A) Steps: 1. tv1 = u^2 2. tv1 = tv1 * c1 3. tv2 = 1 + tv1 4. tv1 = 1 - tv1 5. tv3 = tv1 * tv2 6. tv3 = inv0(tv3) 7. tv4 = u * tv1 8. tv4 = tv4 * tv3 9. tv4 = tv4 * c3 10. x1 = c2 - tv4 11. gx1 = x1^2 12. gx1 = gx1 + A 13. gx1 = gx1 * x1 14. gx1 = gx1 + B 15. e1 = is_square(gx1) 16. x2 = c2 + tv4 17. gx2 = x2^2 18. gx2 = gx2 + A 19. gx2 = gx2 * x2 20. gx2 = gx2 + B 21. e2 = is_square(gx2) AND NOT e1 # Avoid short-circuit logic ops 22. x3 = tv2^2 23. x3 = x3 * tv3 24. x3 = x3^2 25. x3 = x3 * c4 26. x3 = x3 + Z 27. x = CMOV(x3, x1, e1) # x = x1 if gx1 is square, else x = x3 28. x = CMOV(x, x2, e2) # x = x2 if gx2 is square and gx1 is not 29. gx = x^2 30. gx = gx + A 31. gx = gx * x 32. gx = gx + B 33. y = sqrt(gx) 34. e3 = sgn0(u) == sgn0(y) 35. y = CMOV(-y, y, e3) # Select correct sign of y 36. return (x, y)
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. This optimized, straight-line procedure applies to any base field. The sqrt_ratio subroutine is defined in . map_to_curve_simple_swu(u) Input: u, an element of F. Output: (x, y), a point on E. Steps: 1. tv1 = u^2 2. tv1 = Z * tv1 3. tv2 = tv1^2 4. tv2 = tv2 + tv1 5. tv3 = tv2 + 1 6. tv3 = B * tv3 7. tv4 = CMOV(Z, -tv2, tv2 != 0) 8. tv4 = A * tv4 9. tv2 = tv3^2 10. tv6 = tv4^2 11. tv5 = A * tv6 12. tv2 = tv2 + tv5 13. tv2 = tv2 * tv3 14. tv6 = tv6 * tv4 15. tv5 = B * tv6 16. tv2 = tv2 + tv5 17. x = tv1 * tv3 18. (is_gx1_square, y1) = sqrt_ratio(tv2, tv6) 19. y = tv1 * u 20. y = y * y1 21. x = CMOV(x, tv3, is_gx1_square) 22. y = CMOV(y, y1, is_gx1_square) 23. e1 = sgn0(u) == sgn0(y) 24. y = CMOV(-y, y, e1) 25. x = x / tv4 26. return (x, y)
sqrt_ratio subroutines This section defines three variants of the sqrt_ratio subroutine used by the above procedure. The first variant can be used with any field; the others are optimized versions for specific fields. The routines given in this section depend on the constant Z from the simplified SWU map. For correctness, sqrt_ratio and map_to_curve_simple_swu MUST use the same value for Z.
sqrt_ratio for any field sqrt_ratio(u, v) Parameters: - F, a finite field of characteristic p and order q = p^m. - Z, the constant from the simplified SWU map. Input: u and v, elements of F, where v != 0. Output: (b, y), where b = True and y = sqrt(u / v) if (u / v) is square in F, and b = False and y = sqrt(Z * (u / v)) otherwise. Constants: 1. c1, the largest integer such that 2^c1 divides q - 1. 2. c2 = (q - 1) / (2^c1) # Integer arithmetic 3. c3 = (c2 - 1) / 2 # Integer arithmetic 4. c4 = 2^c1 - 1 # Integer arithmetic 5. c5 = 2^(c1 - 1) # Integer arithmetic 6. c6 = Z^c2 7. c7 = Z^((c2 + 1) / 2) Procedure: 1. tv1 = c6 2. tv2 = v^c4 3. tv3 = tv2^2 4. tv3 = tv3 * v 5. tv5 = u * tv3 6. tv5 = tv5^c3 7. tv5 = tv5 * tv2 8. tv2 = tv5 * v 9. tv3 = tv5 * u 10. tv4 = tv3 * tv2 11. tv5 = tv4^c5 12. isQR = tv5 == 1 13. tv2 = tv3 * c7 14. tv5 = tv4 * tv1 15. tv3 = CMOV(tv2, tv3, isQR) 16. tv4 = CMOV(tv5, tv4, isQR) 17. for i in (c1, c1 - 1, ..., 2): 18. tv5 = i - 2 19. tv5 = 2^tv5 20. tv5 = tv4^tv5 21. e1 = tv5 == 1 22. tv2 = tv3 * tv1 23. tv1 = tv1 * tv1 24. tv5 = tv4 * tv1 25. tv3 = CMOV(tv2, tv3, e1) 26. tv4 = CMOV(tv5, tv4, e1) 27. return (isQR, tv3)
optimized sqrt_ratio for q = 3 mod 4 sqrt_ratio_3mod4(u, v) Parameters: - F, a finite field of characteristic p and order q = p^m, where q = 3 mod 4. - Z, the constant from the simplified SWU map. Input: u and v, elements of F, where v != 0. Output: (b, y), where b = True and y = sqrt(u / v) if (u / v) is square in F, and b = False and y = sqrt(Z * (u / v)) otherwise. Constants: 1. c1 = (q - 3) / 4 # Integer arithmetic 2. c2 = sqrt(-Z) Procedure: 1. tv1 = v^2 2. tv2 = u * v 3. tv1 = tv1 * tv2 4. y1 = tv1^c1 5. y1 = y1 * tv2 6. y2 = y1 * c2 7. tv3 = y1^2 8. tv3 = tv3 * v 9. isQR = tv3 == u 10. y = CMOV(y2, y1, isQR) 11. return (isQR, y)
optimized sqrt_ratio for q = 5 mod 8 sqrt_ratio_5mod8(u, v) Parameters: - F, a finite field of characteristic p and order q = p^m, where q = 5 mod 8. - Z, the constant from the simplified SWU map. Input: u and v, elements of F, where v != 0. Output: (b, y), where b = True and y = sqrt(u / v) if (u / v) is square in F, and b = False and y = sqrt(Z * (u / v)) otherwise. Constants: 1. c1 = (q - 5) / 8 2. c2 = sqrt(-1) 3. c3 = sqrt(Z / c2) Steps: 1. tv1 = v^2 2. tv2 = tv1 * v 3. tv1 = tv1^2 4. tv2 = tv2 * u 5. tv1 = tv1 * tv2 6. y1 = tv1^c1 7. y1 = y1 * tv2 8. tv1 = y1 * c2 9. tv2 = tv1^2 10. tv2 = tv2 * v 11. e1 = tv2 == u 12. y1 = CMOV(y1, tv1, e1) 13. tv2 = y1^2 14. tv2 = tv2 * v 15. isQR = tv2 == u 16. y2 = y1 * c3 17. tv1 = y2 * c2 18. tv2 = tv1^2 19. tv2 = tv2 * v 20. tv3 = Z * u 21. e2 = tv2 == tv3 22. y2 = CMOV(y2, tv1, e2) 23. y = CMOV(y2, y1, isQR) 24. return (isQR, y)
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 . map_to_curve_elligator2(u) Input: u, an element of F. Output: (s, t), a point on M. Constants: 1. c1 = J / K 2. c2 = 1 / K^2 Steps: 1. tv1 = u^2 2. tv1 = Z * tv1 # Z * u^2 3. e1 = tv1 == -1 # exceptional case: Z * u^2 == -1 4. tv1 = CMOV(tv1, 0, e1) # if tv1 == -1, set tv1 = 0 5. x1 = tv1 + 1 6. x1 = inv0(x1) 7. x1 = -c1 * x1 # x1 = -(J / K) / (1 + Z * u^2) 8. gx1 = x1 + c1 9. gx1 = gx1 * x1 10. gx1 = gx1 + c2 11. gx1 = gx1 * x1 # gx1 = x1^3 + (J / K) * x1^2 + x1 / K^2 12. x2 = -x1 - c1 13. gx2 = tv1 * gx1 14. e2 = is_square(gx1) # If is_square(gx1) 15. x = CMOV(x2, x1, e2) # then x = x1, else x = x2 16. y2 = CMOV(gx2, gx1, e2) # then y2 = gx1, else y2 = gx2 17. y = sqrt(y2) 18. e3 = sgn0(y) == 1 19. y = CMOV(y, -y, e2 XOR e3) # fix sign of y 20. s = x * K 21. t = y * K 22. return (s, t)
Curve-specific 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: (xn, xd, yn, yd) = map_to_curve(u) 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. Projective coordinates are also useful when implementing random oracle encodings (). One reason is that, in general, point addition is faster using projective coordinates. Another reason is that, for Weierstrass curves, projective coordinates allow using complete addition formulas . This is especially convenient when implementing a constant-time encoding, because it eliminates the need for a special case when Q0 == Q1, which incomplete addition formulas usually do not handle. 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).
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). map_to_curve_elligator2_curve25519(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on curve25519. Constants: 1. c1 = (q + 3) / 8 # Integer arithmetic 2. c2 = 2^c1 3. c3 = sqrt(-1) 4. c4 = (q - 5) / 8 # Integer arithmetic Steps: 1. tv1 = u^2 2. tv1 = 2 * tv1 3. xd = tv1 + 1 # Nonzero: -1 is square (mod p), tv1 is not 4. x1n = -J # x1 = x1n / xd = -J / (1 + 2 * u^2) 5. tv2 = xd^2 6. gxd = tv2 * xd # gxd = xd^3 7. gx1 = J * tv1 # x1n + J * xd 8. gx1 = gx1 * x1n # x1n^2 + J * x1n * xd 9. gx1 = gx1 + tv2 # x1n^2 + J * x1n * xd + xd^2 10. gx1 = gx1 * x1n # x1n^3 + J * x1n^2 * xd + x1n * xd^2 11. tv3 = gxd^2 12. tv2 = tv3^2 # gxd^4 13. tv3 = tv3 * gxd # gxd^3 14. tv3 = tv3 * gx1 # gx1 * gxd^3 15. tv2 = tv2 * tv3 # gx1 * gxd^7 16. y11 = tv2^c4 # (gx1 * gxd^7)^((p - 5) / 8) 17. y11 = y11 * tv3 # gx1 * gxd^3 * (gx1 * gxd^7)^((p - 5) / 8) 18. y12 = y11 * c3 19. tv2 = y11^2 20. tv2 = tv2 * gxd 21. e1 = tv2 == gx1 22. y1 = CMOV(y12, y11, e1) # If g(x1) is square, this is its sqrt 23. x2n = x1n * tv1 # x2 = x2n / xd = 2 * u^2 * x1n / xd 24. y21 = y11 * u 25. y21 = y21 * c2 26. y22 = y21 * c3 27. gx2 = gx1 * tv1 # g(x2) = gx2 / gxd = 2 * u^2 * g(x1) 28. tv2 = y21^2 29. tv2 = tv2 * gxd 30. e2 = tv2 == gx2 31. y2 = CMOV(y22, y21, e2) # If g(x2) is square, this is its sqrt 32. tv2 = y1^2 33. tv2 = tv2 * gxd 34. e3 = tv2 == gx1 35. xn = CMOV(x2n, x1n, e3) # If e3, x = x1, else x = x2 36. y = CMOV(y2, y1, e3) # If e3, y = y1, else y = y2 37. e4 = sgn0(y) == 1 # Fix sign of y 38. y = CMOV(y, -y, e3 XOR e4) 39. return (xn, xd, y, 1)
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 ). map_to_curve_elligator2_edwards25519(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on edwards25519. Constants: 1. c1 = sqrt(-486664) # sgn0(c1) MUST equal 0 Steps: 1. (xMn, xMd, yMn, yMd) = map_to_curve_elligator2_curve25519(u) 2. xn = xMn * yMd 3. xn = xn * c1 4. xd = xMd * yMn # xn / xd = c1 * xM / yM 5. yn = xMn - xMd 6. yd = xMn + xMd # (n / d - 1) / (n / d + 1) = (n - d) / (n + d) 7. tv1 = xd * yd 8. e = tv1 == 0 9. xn = CMOV(xn, 0, e) 10. xd = CMOV(xd, 1, e) 11. yn = CMOV(yn, 1, e) 12. yd = CMOV(yd, 1, e) 13. return (xn, xd, yn, yd)
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). map_to_curve_elligator2_curve448(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on curve448. Constants: 1. c1 = (q - 3) / 4 # Integer arithmetic Steps: 1. tv1 = u^2 2. e1 = tv1 == 1 3. tv1 = CMOV(tv1, 0, e1) # If Z * u^2 == -1, set tv1 = 0 4. xd = 1 - tv1 5. x1n = -J 6. tv2 = xd^2 7. gxd = tv2 * xd # gxd = xd^3 8. gx1 = -J * tv1 # x1n + J * xd 9. gx1 = gx1 * x1n # x1n^2 + J * x1n * xd 10. gx1 = gx1 + tv2 # x1n^2 + J * x1n * xd + xd^2 11. gx1 = gx1 * x1n # x1n^3 + J * x1n^2 * xd + x1n * xd^2 12. tv3 = gxd^2 13. tv2 = gx1 * gxd # gx1 * gxd 14. tv3 = tv3 * tv2 # gx1 * gxd^3 15. y1 = tv3^c1 # (gx1 * gxd^3)^((p - 3) / 4) 16. y1 = y1 * tv2 # gx1 * gxd * (gx1 * gxd^3)^((p - 3) / 4) 17. x2n = -tv1 * x1n # x2 = x2n / xd = -1 * u^2 * x1n / xd 18. y2 = y1 * u 19. y2 = CMOV(y2, 0, e1) 20. tv2 = y1^2 21. tv2 = tv2 * gxd 22. e2 = tv2 == gx1 23. xn = CMOV(x2n, x1n, e2) # If e2, x = x1, else x = x2 24. y = CMOV(y2, y1, e2) # If e2, y = y1, else y = y2 25. e3 = sgn0(y) == 1 # Fix sign of y 26. y = CMOV(y, -y, e2 XOR e3) 27. return (xn, xd, y, 1)
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 . map_to_curve_elligator2_edwards448(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on edwards448. Steps: 1. (xn, xd, yn, yd) = map_to_curve_elligator2_curve448(u) 2. xn2 = xn^2 3. xd2 = xd^2 4. xd4 = xd2^2 5. yn2 = yn^2 6. yd2 = yd^2 7. xEn = xn2 - xd2 8. tv2 = xEn - xd2 9. xEn = xEn * xd2 10. xEn = xEn * yd 11. xEn = xEn * yn 12. xEn = xEn * 4 13. tv2 = tv2 * xn2 14. tv2 = tv2 * yd2 15. tv3 = 4 * yn2 16. tv1 = tv3 + yd2 17. tv1 = tv1 * xd4 18. xEd = tv1 + tv2 19. tv2 = tv2 * xn 20. tv4 = xn * xd4 21. yEn = tv3 - yd2 22. yEn = yEn * tv4 23. yEn = yEn - tv2 24. tv1 = xn2 + xd2 25. tv1 = tv1 * xd2 26. tv1 = tv1 * xd 27. tv1 = tv1 * yn2 28. tv1 = -2 * tv1 29. yEd = tv2 + tv1 30. tv4 = tv4 * yd2 31. yEd = yEd + tv4 32. tv1 = xEd * yEd 33. e = tv1 == 0 34. xEn = CMOV(xEn, 0, e) 35. xEd = CMOV(xEd, 1, e) 36. yEn = CMOV(yEn, 1, e) 37. yEd = CMOV(yEd, 1, e) 38. return (xEn, xEd, yEn, yEd)
Montgomery curves with q = 3 (mod 4) The following is a straight-line implementation of Elligator 2 that applies to any Montgomery curve defined over GF(q) where q = 3 (mod 4). For curves where K = 1, the implementation given in gives identical results with slightly reduced cost. map_to_curve_elligator2_3mod4(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on the target curve. Constants: 1. c1 = (q - 3) / 4 # Integer arithmetic 2. c2 = K^2 Steps: 1. tv1 = u^2 2. e1 = tv1 == 1 3. tv1 = CMOV(tv1, 0, e1) # If Z * u^2 == -1, set tv1 = 0 4. xd = 1 - tv1 5. xd = xd * K 6. x1n = -J # x1 = x1n / xd = -J / (K * (1 + 2 * u^2)) 7. tv2 = xd^2 8. gxd = tv2 * xd 9. gxd = gxd * c2 # gxd = xd^3 * K^2 10. gx1 = x1n * K 11. tv3 = xd * J 12. tv3 = gx1 + tv3 # x1n * K + xd * J 13. gx1 = gx1 * tv3 # K^2 * x1n^2 + J * K * x1n * xd 14. gx1 = gx1 + tv2 # K^2 * x1n^2 + J * K * x1n * xd + xd^2 15. gx1 = gx1 * x1n # K^2 * x1n^3 + J * K * x1n^2 * xd + x1n * xd^2 16. tv3 = gxd^2 17. tv2 = gx1 * gxd # gx1 * gxd 18. tv3 = tv3 * tv2 # gx1 * gxd^3 19. y1 = tv3^c1 # (gx1 * gxd^3)^((q - 3) / 4) 20. y1 = y1 * tv2 # gx1 * gxd * (gx1 * gxd^3)^((q - 3) / 4) 21. x2n = -tv1 * x1n # x2 = x2n / xd = -1 * u^2 * x1n / xd 22. y2 = y1 * u 23. y2 = CMOV(y2, 0, e1) 24. tv2 = y1^2 25. tv2 = tv2 * gxd 26. e2 = tv2 == gx1 27. xn = CMOV(x2n, x1n, e2) # If e2, x = x1, else x = x2 28. xn = xn * K 29. y = CMOV(y2, y1, e2) # If e2, y = y1, else y = y2 30. e3 = sgn0(y) == 1 # Fix sign of y 31. y = CMOV(y, -y, e2 XOR e3) 32. y = y * K 33. return (xn, xd, y, 1)
Montgomery curves with q = 5 (mod 8) The following is a straight-line implementation of Elligator 2 that applies to any Montgomery curve defined over GF(q) where q = 5 (mod 8). For curves where K = 1, the implementation given in gives identical results with slightly reduced cost. map_to_curve_elligator2_5mod8(u) Input: u, an element of F. Output: (xn, xd, yn, yd) such that (xn / xd, yn / yd) is a point on the target curve. Constants: 1. c1 = (q + 3) / 8 # Integer arithmetic 2. c2 = 2^c1 3. c3 = sqrt(-1) 4. c4 = (q - 5) / 8 # Integer arithmetic 5. c5 = K^2 Steps: 1. tv1 = u^2 2. tv1 = 2 * tv1 3. xd = tv1 + 1 # Nonzero: -1 is square (mod p), tv1 is not 4. xd = xd * K 5. x1n = -J # x1 = x1n / xd = -J / (K * (1 + 2 * u^2)) 6. tv2 = xd^2 7. gxd = tv2 * xd 8. gxd = gxd * c5 # gxd = xd^3 * K^2 9. gx1 = x1n * K 10. tv3 = xd * J 11. tv3 = gx1 + tv3 # x1n * K + xd * J 12. gx1 = gx1 * tv3 # K^2 * x1n^2 + J * K * x1n * xd 13. gx1 = gx1 + tv2 # K^2 * x1n^2 + J * K * x1n * xd + xd^2 14. gx1 = gx1 * x1n # K^2 * x1n^3 + J * K * x1n^2 * xd + x1n * xd^2 15. tv3 = gxd^2 16. tv2 = tv3^2 # gxd^4 17. tv3 = tv3 * gxd # gxd^3 18. tv3 = tv3 * gx1 # gx1 * gxd^3 19. tv2 = tv2 * tv3 # gx1 * gxd^7 20. y11 = tv2^c4 # (gx1 * gxd^7)^((q - 5) / 8) 21. y11 = y11 * tv3 # gx1 * gxd^3 * (gx1 * gxd^7)^((q - 5) / 8) 22. y12 = y11 * c3 23. tv2 = y11^2 24. tv2 = tv2 * gxd 25. e1 = tv2 == gx1 26. y1 = CMOV(y12, y11, e1) # If g(x1) is square, this is its sqrt 27. x2n = x1n * tv1 # x2 = x2n / xd = 2 * u^2 * x1n / xd 28. y21 = y11 * u 29. y21 = y21 * c2 30. y22 = y21 * c3 31. gx2 = gx1 * tv1 # g(x2) = gx2 / gxd = 2 * u^2 * g(x1) 32. tv2 = y21^2 33. tv2 = tv2 * gxd 34. e2 = tv2 == gx2 35. y2 = CMOV(y22, y21, e2) # If g(x2) is square, this is its sqrt 36. tv2 = y1^2 37. tv2 = tv2 * gxd 38. e3 = tv2 == gx1 39. xn = CMOV(x2n, x1n, e3) # If e3, x = x1, else x = x2 40. xn = xn * K 41. y = CMOV(y2, y1, e3) # If e3, y = y1, else y = y2 42. e4 = sgn0(y) == 1 # Fix sign of y 43. y = CMOV(y, -y, e3 XOR e4) 44. y = y * K 45. return (xn, xd, y, 1)
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 .) frobenius(x) Input: x, an element of GF(p^2). Output: a, an element of GF(p^2). Notation: x = x0 + I * x1, where x0 and x1 are elements of GF(p). Steps: 1. a = x0 - I * x1 2. return a The following function computes the endomorphism psi for points on the elliptic curve E defined in . psi(xn, xd, yn, yd) Input: P, a point (xn / xd, yn / yd) on the curve E (see above). Output: Q, a point on the same curve. Constants: 1. c1 = 1 / (1 + I)^((p - 1) / 3) # in GF(p^2) 2. c2 = 1 / (1 + I)^((p - 1) / 2) # in GF(p^2) Steps: 1. qxn = c1 * frobenius(xn) 2. qxd = frobenius(xd) 3. qyn = c2 * frobenius(yn) 4. qyd = frobenius(yd) 5. return (qxn, qxd, qyn, qyd) The following function efficiently computes psi(psi(P)). psi2(xn, xd, yn, yd) Input: P, a point (xn / xd, yn / yd) on the curve E (see above). Output: Q, a point on the same curve. Constants: 1. c1 = 1 / 2^((p - 1) / 3) # in GF(p^2) Steps: 1. qxn = c1 * xn 2. qyn = -yn 3. return (qxn, xd, qyn, yd) 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 * P, where h_eff is the parameter given in . clear_cofactor_bls12381_g2(P) Input: P, a point (xn / xd, yn / yd) on the curve E (see above). Output: Q, a point in the subgroup G2 of BLS12-381. Constants: 1. c1 = -15132376222941642752 # the BLS parameter for BLS12-381 # i.e., -0xd201000000010000 Notation: in this procedure, + and - represent elliptic curve point addition and subtraction, respectively, and * represents scalar multiplication. Steps: 1. t1 = c1 * P 2. t2 = psi(P) 3. t3 = 2 * P 4. t3 = psi2(t3) 5. t3 = t3 - t2 6. t2 = t1 + t2 7. t2 = c1 * t2 8. t3 = t3 + t2 9. t3 = t3 - t1 10. Q = t3 - P 11. return Q
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 (). # Arguments: # - F, a field object, e.g., F = GF(2^521 - 1) # - A and B, the coefficients of the curve y^2 = x^3 + A * x + B def find_z_svdw(F, A, B, init_ctr=1): g = lambda x: F(x)^3 + F(A) * F(x) + F(B) h = lambda Z: -(F(3) * Z^2 + F(4) * A) / (F(4) * g(Z)) # NOTE: if init_ctr=1 fails to find Z, try setting it to F.gen() ctr = init_ctr while True: for Z_cand in (F(ctr), F(-ctr)): # Criterion 1: # g(Z) != 0 in F. if g(Z_cand) == F(0): continue # Criterion 2: # -(3 * Z^2 + 4 * A) / (4 * g(Z)) != 0 in F. if h(Z_cand) == F(0): continue # Criterion 3: # -(3 * Z^2 + 4 * A) / (4 * g(Z)) is square in F. if not is_square(h(Z_cand)): continue # Criterion 4: # At least one of g(Z) and g(-Z / 2) is square in F. if is_square(g(Z_cand)) or is_square(g(-Z_cand / F(2))): return Z_cand ctr += 1
Finding Z for Simplified SWU The below function outputs an appropriate Z for the Simplified SWU map (). # Arguments: # - F, a field object, e.g., F = GF(2^521 - 1) # - A and B, the coefficients of the curve y^2 = x^3 + A * x + B def find_z_sswu(F, A, B): R.<xx> = 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)): # Criterion 1: Z is non-square in F. if is_square(Z_cand): continue # Criterion 2: Z != -1 in F. if Z_cand == F(-1): continue # Criterion 3: g(x) - Z is irreducible over F. if not (g - Z_cand).is_irreducible(): continue # Criterion 4: g(B / (Z * A)) is square in F. if is_square(g(B / (Z_cand * A))): return Z_cand ctr += 1
Finding Z for Elligator 2 The below function outputs an appropriate Z for the Elligator 2 map (). # Argument: # - F, a field object, e.g., F = GF(2^255 - 19) def find_z_ell2(F): ctr = F.gen() while True: for Z_cand in (F(ctr), F(-ctr)): # Z must be a non-square in F. if is_square(Z_cand): continue return Z_cand ctr += 1
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).
sqrt for q = 3 (mod 4) sqrt_3mod4(x) Parameters: - F, a finite field of characteristic p and order q = p^m. Input: x, an element of F. Output: z, an element of F such that (z^2) == x, if x is square in F. Constants: 1. c1 = (q + 1) / 4 # Integer arithmetic Procedure: 1. return x^c1
sqrt for q = 5 (mod 8) sqrt_5mod8(x) Parameters: - F, a finite field of characteristic p and order q = p^m. Input: x, an element of F. Output: z, an element of F such that (z^2) == x, if x is square in F. Constants: 1. c1 = sqrt(-1) in F, i.e., (c1^2) == -1 in F 2. c2 = (q + 3) / 8 # Integer arithmetic Procedure: 1. tv1 = x^c2 2. tv2 = tv1 * c1 3. e = (tv1^2) == x 4. z = CMOV(tv2, tv1, e) 5. return z
sqrt for q = 9 (mod 16) sqrt_9mod16(x) Parameters: - F, a finite field of characteristic p and order q = p^m. Input: x, an element of F. Output: z, an element of F such that (z^2) == x, if x is square in F. Constants: 1. c1 = sqrt(-1) in F, i.e., (c1^2) == -1 in F 2. c2 = sqrt(c1) in F, i.e., (c2^2) == c1 in F 3. c3 = sqrt(-c1) in F, i.e., (c3^2) == -c1 in F 4. c4 = (q + 7) / 16 # Integer arithmetic Procedure: 1. tv1 = x^c4 2. tv2 = c1 * tv1 3. tv3 = c2 * tv1 4. tv4 = c3 * tv1 5. e1 = (tv2^2) == x 6. e2 = (tv3^2) == x 7. tv1 = CMOV(tv1, tv2, e1) # Select tv2 if (tv2^2) == x 8. tv2 = CMOV(tv4, tv3, e2) # Select tv3 if (tv3^2) == x 9. e3 = (tv2^2) == x 10. z = CMOV(tv1, tv2, e3) # Select the sqrt from tv1 and tv2 11. return z
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. sqrt_ts_ct(x) Parameters: - F, a finite field of characteristic p and order q = p^m. Input x, an element of F. Output: z, an element of F such that z^2 == x, if x is square in F. Constants: 1. c1, the largest integer such that 2^c1 divides q - 1. 2. c2 = (q - 1) / (2^c1) # Integer arithmetic 3. c3 = (c2 - 1) / 2 # Integer arithmetic 4. c4, a non-square value in F 5. c5 = c4^c2 in F Procedure: 1. z = x^c3 2. t = z * z 3. t = t * x 4. z = z * x 5. b = t 6. c = c5 7. for i in (c1, c1 - 1, ..., 2): 8. for j in (1, 2, ..., i - 2): 9. b = b * b 10. e = b == 1 11. zt = z * c 12. z = CMOV(zt, z, e) 13. c = c * c 14. tt = t * c 15. t = CMOV(tt, t, e) 16. b = t 17. return z
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 extension fields; see, e.g., for more information. is_square(x) Parameters: - F, an extension field of characteristic p and order q = p^2 with basis (1, I). Input: x, an element of F. Output: True if x is square in F, and False otherwise. Constants: 1. c1 = (p - 1) / 2 # Integer arithmetic Procedure: 1. tv1 = x_1^2 2. tv2 = I * x_2 3. tv2 = tv2^2 4. tv1 = tv1 - tv2 5. tv1 = tv1^c1 6. e1 = tv1 != -1 # Note: -1 in F 7. return e1
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-384_SSWU_RO_
P384_XMD:SHA-384_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_XOF:SHAKE256_ELL2_RO_
curve448_XOF:SHAKE256_ELL2_NU_
edwards448
edwards448_XOF:SHAKE256_ELL2_RO_
edwards448_XOF:SHAKE256_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-256) (long DST)
expand_message_xmd(SHA-512)
expand_message_xof(SHAKE128)
expand_message_xof(SHAKE128) (long DST)
expand_message_xof(SHAKE256)