Hashing to Elliptic CurvesCloudflare101 Townsend StSan FranciscoUnited States of Americaarmfazh@cloudflare.comCornell Tech2 West Loop RdNew York, New York 10044United States of Americasam.scott@cornell.eduCloudflare101 Townsend StSan FranciscoUnited States of Americanick@cloudflare.comStanford Universityrsw@cs.stanford.eduApple Inc.One Apple Park WayCupertino, California 95014United States of Americacawood@apple.comInternet-DraftThis document specifies a number of algorithms that may be used to encode or hash an
arbitrary string to a point on an elliptic curve.Many cryptographic protocols require a procedure that encodes an arbitrary input,
e.g., a password, to a point on an elliptic curve. This procedure is known
as hashing to an elliptic curve. Prominent examples of cryptosystems that
hash to elliptic curves include Simple Password Exponential Key Exchange
, Password Authenticated Key Exchange , Identity-Based
Encryption and Boneh-Lynn-Shacham signatures .Unfortunately for implementors, the precise hash function that is suitable for a
given scheme is not necessarily included in the description of the protocol.
Compounding this problem is the need to pick a suitable curve for the specific
protocol.This document aims to bridge this gap by providing a thorough 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.This document does not cover rejection sampling methods, sometimes known
as “try-and-increment” or “hunt-and-peck,” because the goal is to describe
algorithms that can plausibly be made constant time. Use of these rejection
methods is NOT RECOMMENDED, because they have been a perennial cause of
side-channel vulnerabilities.This document is intended for use by both implementors and protocol designers.For implementors, the necessary and sufficient level of specification is
a hash-to-curve suite, which fixes all of the parameters listed in ,
plus a domain separation tag ().
Starting from working operations on the target elliptic curve and its base field,
a hash-to-curve suite requires implementing the specified encoding function (),
its constituent subroutines (, , ), and
a few utility functions ().Correspondingly, designers specifying a protocol that requires hashing to an elliptic curve
should either choose an existing hash-to-curve suite or specify a new one (see ).
In addition, designers should choose a domain separation tag following the guidelines in
.The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in .The following is a brief definition of elliptic curves, with an emphasis on
important parameters and their relation to hashing to curves.
For further reference on elliptic curves, consult or .Let F be the finite field GF(q) of prime characteristic p > 3.
(This document does not consider elliptic curves over fields of characteristic 2 or 3.)
In most cases F is a prime field, so q = p.
Otherwise, F is an extension field, so q = p^m for an integer m > 1.
This document writes elements of extension fields
in a primitive element or polynomial basis, i.e., as a vector
of m elements of GF(p) written in ascending order by degree.
The entries of this vector are indexed in ascending order starting from 1,
i.e., x = (x_1, x_2, …, x_m).
For example, if q = p^2 and the primitive element basis is (1, I),
then x = (a, b) corresponds to the element a + b * I, where
x_1 = a and x_2 = b.An elliptic curve E is specified by an equation in two variables and a
finite field F. An elliptic curve equation takes one of several standard forms,
including (but not limited to) Weierstrass, Montgomery, and Edwards.The curve E induces an algebraic group whose elements are those points
with coordinates (x, y) satisfying the curve equation, and where x and y
are elements of F.
This group has order n, meaning that there are n distinct points.
This document uses additive notation for the elliptic curve group operation.For security reasons, groups of prime order MUST be used. Elliptic curves
induce subgroups of prime order. Let G be 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, and/or the parameters of the curve. For each
algorithm presented, this document lists the relevant restrictions.Summary of quantities:SymbolMeaningRelevanceF,q,pFinite field F of characteristic p and #F = q = p^m.For prime fields, q = p; otherwise, q = p^m and m>1.EElliptic curve.E is specified by an equation and a field F.nNumber of points on the elliptic curve E.n = h * r, for h and r defined below.GA subgroup of the elliptic curve.Destination group to which byte strings are encoded.rOrder of G.This number MUST be prime.hCofactor, h >= 1.An integer satisfying n = h * r.In this section, we define important terms used in the rest of this document.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 it 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 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 string.
Encodings can be deterministic or probabilistic.
Deterministic encodings are preferred for security, because probabilistic
ones are more likely to leak information through side channels.This document constructs deterministic encodings by composing a hash function H
with a deterministic mapping.
In particular, H 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 the hash function H takes arbitrary 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 H 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 hash function used by all encodings specified in this document ()
is not invertible; thus, the encodings are also not invertible.Two different types of encodings are possible: nonuniform encodings,
whose output distribution is not uniformly random, and random oracle encodings,
whose output distribution is indistinguishable from uniformly random.
Some protocols require a random oracle for security, while others can
be securely instantiated with a nonuniform encoding.
When the required encoding is not clear, applications SHOULD use a random oracle.Care is required when constructing a random oracle from a mapping function.
A simple but insecure approach is to use the output of a cryptographically
secure hash function H as the input to the mapping.
Because in general the mapping is not surjective, the output of this
construction is distinguishable from uniformly random, i.e., it does
not behave like a random oracle.Brier et al. describe two generic methods for constructing
random oracle encodings.
Farashahi et al. and Tibouchi and Kim refine the analysis
of one of these constructions.
That construction is described in .(In more detail: both constructions are
indifferentiable from a random oracle when instantiated
with appropriate hash functions modeled as random oracles.
See for further discussion.)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 reverse 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.Cryptographic protocols that use random oracles are often analyzed
under the assumption that random oracles answer only queries generated
by that protocol.
In practice, this assumption does not hold if two protocols query the
same random oracle.
Concretely, consider protocols P1 and P2 that query 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 approach to 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 defineIn this example, “RO1” and “RO2” are called domain separation tags;
they ensure that queries to RO1 and RO2 cannot result in identical
queries to RO.
Thus, it is safe to treat RO1 and RO2 as independent oracles.This section presents a general framework for encoding byte strings to points
on an elliptic curve. To construct these encodings, we rely on three basic
functions:The function hash_to_field, {0, 1}^* x {0, 1, 2} -> F, hashes arbitrary-length byte strings
to elements of a finite field; its implementation is defined in
.The function map_to_curve, F -> E, calculates a point on the elliptic curve E
from an element of the finite field F over which E is defined.
describes mappings for a range of curve families.The function clear_cofactor, E -> G, sends any point on the curve E to
the subgroup G of E. describes methods to perform
this operation.We describe two high-level encoding functions ().
Although these functions have the same interface, the
distributions of their outputs are different.Nonuniform encoding (encode_to_curve). This function encodes byte strings to points in G.
The distribution of the output is not uniformly random in G.Random oracle encoding (hash_to_curve). This function encodes byte strings to points in G.
This function is suitable for applications requiring a random oracle returning points in G,
provided that map_to_curve is “well distributed” (, Def. 1).
All of the map_to_curve functions defined in meet this requirement.Instances of these functions are given in , which defines a list of
suites that specify a full set of parameters matching elliptic curves and
algorithms.All uses of the encoding functions defined in this document MUST include
domain separation () to avoid interfering with
other uses of similar functionality.Protocols that instantiate multiple, independent hash functions based on
either hash_to_curve or encode_to_curve MUST enforce domain separation
between those hash functions.
This requirement applies both in the case of multiple hashes to the same
curve and in the case of multiple hashes to different curves.
(This is because the 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.
Care is required when selecting and using a domain separation tag.
The following requirements apply:Tags MUST be supplied as the DST parameter to hash_to_field, as
described in .Tags MUST begin with a fixed protocol identification string.
This identification string should be unique to the protocol.Tags SHOULD include a protocol version number.For protocols 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.For protocols 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 protocol named Quux
that defines several different ciphersuites.
A reasonable choice of tag is “QUUX-V<xx>-CS<yy>”, where <xx> and <yy>
are two-digit numbers indicating the version and ciphersuite, respectively.As another example, consider a fictional protocol named Baz that requires
two independent random oracles, where one oracle outputs points on the curve
E1 and the other outputs points on the curve E2.
Reasonable choices of tags for the E1 and E2 oracles are
“BAZ-V<xx>-CS<yy>-E1” and “BAZ-V<xx>-CS<yy>-E2”, respectively,
where <xx> and <yy> are as described above.Algorithms in this document make use of utility functions described below.For security reasons, all field operations, comparisons, and assignments
MUST be implemented in constant time (i.e., execution time MUST NOT depend
on the values of the inputs), and without branching.
Guidance on implementing these low-level operations in constant time is
beyond the scope of this document.CMOV(a, b, c): If c is False, CMOV returns a, otherwise it returns b.
To prevent against timing attacks, this operation must run in constant
time, without revealing the value of c.
Commonly, implementations assume that the selector c is 1 for True or
0 for False. In this case, given a bit string C, the desired selector c can
be computed by OR-ing all bits of C together. The resulting selector will be
either 0 if all bits of C are zero, or 1 if at least one bit of C is 1.is_square(x): This function returns True whenever the value x is a
square in the field F. Due to Euler’s criterion, this function can be
calculated in constant time assqrt(x): The sqrt operation is a multi-valued function, i.e. there exist
two roots of x in the field F whenever x is square.
To maintain compatibility across implementations while allowing implementors
leeway for optimizations, this document does not require sqrt() to return a
particular value. Instead, as explained in , any higher-level
function that computes square roots also specifies how to determine the sign
of the result.
The preferred way of computing square roots is to fix a deterministic
algorithm particular to F. We give several algorithms in .
Regardless of the method chosen, the sqrt function should be implemented
in a way that resists timing side channels, i.e., in constant time.sgn0(x): This function returns either +1 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.
This function may be implemented in multiple ways; defines two variants.
Throughout the document, sgn0 is used generically to mean either of these variants.
Each suite in specifies the sgn0 variant to be used.inv0(x): This function returns the multiplicative inverse of x in F,
extended to all of F by fixing inv0(0) == 0.
To implement inv0 in constant time, compute inv0(x) := x^(q - 2).
Notice on input 0, the output is 0 as required.I2OSP and OS2IP: These functions are used to convert a byte string to
and from a non-negative integer as described in .a || b: denotes the concatenation of strings a and b.substr(str, sstart, slen): for a byte string str, this function returns
the slen-byte substring starting at position sstart; 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.This section defines two ways of determining the “sign” of an element of F.
The variant that should be used is a matter of convention.
Other sgn0 variants are possible, but the two given below cover
commonly used notions of sign.It is RECOMMENDED to select the variant that matches the point decompression
method of the target curve.
In particular, since point decompression requires computing a square root
and then choosing the sign of the resulting point, all decompression methods
specify, implicitly or explicitly, a method for determining the sign of an
element of F.
It is convenient for hash-to-curve and decompression to agree on a notion of
sign, since this may permit simpler implementations.See for a discussion of representing elements of extension fields
as vectors; this representation is used in both of the sgn0 variants below.Note that any valid sgn0 function for extension fields must iterate over
the entire vector representation of the input element.
To see why, imagine a function sgn0* that ignores the final entry in its
input vector, and consider a field element x = (0, x_2).
Since sgn0* ignores x_2, sgn0*(x) == sgn0*(-x), which is incorrect
when x_2 != 0.
The same argument applies to all entries of any x, establishing the claim.The following sgn0 variant is defined such that sgn0_be(x) = -1
just when the big-endian encoding of x is lexically greater than
the encoding of -x.This variant SHOULD be used when points on the target elliptic curve
are serialized using the SORT compression method given in
IEEE 1363a-2004 , Section 5.5.6.1.2, and other similar methods.The following sgn0 variant is defined such that sgn0_le(x) = -1
just when x != 0 and the parity of the least significant nonzero
entry of the vector representation of x is 1.This variant SHOULD be used when points on the target elliptic curve are serialized
using any of the following methods:the LSB compression method given in IEEE 1363a-2004 , Section 5.5.6.1.1,the method given in Section 2.3.3, orthe method given in ANSI X9.62-1998 , Section 4.2.1.This variant is also compatible with the compression method specified for the
Ed25519 and Ed448 elliptic curves .The hash_to_field function hashes a byte string msg of any 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 pseudorandom byte string, and then interprets this pseudorandom
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 one
appropriate for extensible-output functions like SHAKE-128 .
Security considerations for each expand_message variant are discussed
below (, ).Implementors MUST NOT use rejection sampling to generate a uniformly
random element of F.
The reason is that rejection sampling procedures are difficult to implement
in constant time, and later well-meaning “optimizations” may silently render
an implementation non-constant-time.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 pseudorandom integers whose
length is at least ceil(log2(p)) + k bits.
Reducing such integers mod p gives bias at most 2^-k for any p; this bias
is appropriate when targeting k-bit security.
To obtain such integers, hash_to_field uses expand_message to obtain
L pseudorandom bytes, where L = ceil((ceil(log2(p)) + k) / 8); this
byte string is 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.The following procedure implements hash_to_field.The expand_message parameter to this function MUST conform to the requirements
given below (). discusses requirements for domain separation and
recommendations for choosing DST, the domain separation tag.
This is the REQUIRED method for applying domain separation.expand_message is a function that generates a pseudorandom byte string.
It takes three arguments:msg, a byte string containing the message to hash,DST, a byte string that acts as a domain separation tag, andlen_in_bytes, the number of bytes to be generated.This document defines two variants of expand_message:expand_message_xmd () is appropriate for use
with a wide range of hash functions, including SHA-2 , SHA-3
, BLAKE2 , and others.expand_message_xof () is appropriate for use
with extensible-output functions (XOFs) including functions in the SHAKE
or BLAKE2X families.These variants should suffice for the vast majority of use cases, but other
variants are possible; discusses requirements.The expand_message variants defined in this section accept domain separation
tags of at most 255 bytes.
If a domain separation tag longer than 255 bytes must be used (e.g., because
of requirements imposed by an invoking protocol), implementors MUST compute
a short domain separation tag by hashing, as follows:Here, a_very_long_DST is the DST whose length is greater than 255 bytes,
“H2C-OVERSIZE-DST-“ is an ASCII string literal, and the hash function H MUST
meet the criteria given in .The expand_message_xmd function produces a pseudorandom byte string using
a cryptographic hash function H that outputs b bits.
For security, H must meet the following requirements:The number of bits output by H MUST be b >= 2 * k, for k the target
security level in bits. This ensures k-bit collision resistance.H MAY be a Merkle-Damgaard hash function like SHA-2.
In this case, security holds when the underlying compression function is
modeled as a random oracle .
(See for discussion.)H MAY be a sponge-based hash function like SHA-3 or BLAKE2.
In this case, security holds when the inner function is modeled as a
random transformation or as a random permutation .Otherwise, H MUST be a hash function that has been proved indifferentiable
from a random oracle under a widely accepted cryptographic assumption.SHA-2 and SHA-3 are typical and RECOMMENDED choices.
As an example, for the 128-bit security level, b >= 256 bits and either SHA-256 or
SHA3-256 would be an appropriate choice.The following procedure implements expand_message_xmd.Note that the string Z_pad is prepended to msg when computing b_0 (step 6).
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; and then, when computing b_0, initialize H using the saved state.
Further details are beyond the scope of this document.The expand_message_xof function produces a pseudorandom byte string
using an extensible-output function (XOF) H.
For security, H must meet the following criteria:The collision resistance of H MUST be at least k bits.H MUST be an XOF that has been proved indifferentiable from a random oracle
under a reasonable cryptographic assumption.The SHAKE XOF family is a typical and RECOMMENDED choice.
As an example, for 128-bit security, SHAKE-128 would be an appropriate choice.The following procedure implements expand_message_xof.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.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 any form of rejection sampling.MUST give independent values for distinct (msg, DST, length) inputs.
Meeting this requirement is slightly subtle.
As a simplified example, hashing the concatenation 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 prefix-free encoding of DST
to avoid this issue.MUST use the domain separation tag DST to ensure that invocations of
cryptographic primitives inside of expand_message are domain separated
from invocations outside of expand_message.
For example, if the expand_message variant uses a hash function H, an encoding
of DST MUST be either prepended or appended to the input to each invocation
of H (appending is the RECOMMENDED approach).SHOULD read msg exactly once, for efficiency when msg is long.In addition, an expand_message variant MUST specify a unique EXP_TAG
that identifies that variant in a Suite ID.
See for more information.The mappings in this section are suitable for constructing either nonuniform
or random oracle encodings using the constructions of .
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.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.The generic interface shared by all mappings in this section is as follows:The input u and outputs x and y are elements of the field F.
The coordinates (x, y) specify a point on an elliptic curve defined over F.
Note that the point (x, y) is not a uniformly random point. If uniformity
is required for security, the random oracle construction of MUST be
used instead.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.In general, elliptic curves have equations of the form y^2 = g(x).
Most of 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 results in an ambiguity
regarding the sign of y.To resolve this ambiguity, the mappings in this section specify
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 to optimize
their square-root implementations.Mappings may have have exceptional cases, i.e., inputs u
on which the mapping is undefined. These cases must be handled
carefully, especially for constant-time implementations.For each mapping in this section, we discuss the exceptional cases and show
how to handle them in constant time. Note that all implementations SHOULD use
inv0 () to compute multiplicative inverses, to avoid exceptional
cases that result from attempting to compute the inverse of 0.The mappings in this section apply to a target curve E defined by the equationwhere 4 * A^3 + 27 * B^2 != 0.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, an element of F meeting the below criteria.
gives a Sage script that outputs the RECOMMENDED Z. g(Z) != 0 in F.-(3 * Z^2 + 4 * A) / (4 * g(Z)) != 0 in F.-(3 * Z^2 + 4 * A) / (4 * g(Z)) is square in F.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.
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:The following procedure implements the Shallue and van de Woestijne method in a
straight-line fashion.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: Z is non-square in F,Z != -1 in F,the polynomial g(x) - Z is irreducible over F, andg(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:The following procedure implements the simplified SWU mapping in a straight-line fashion.
gives an optimized straight-line procedure for P-256 .
For more information on optimizing this mapping, see
Section 4 or the example code found at .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 equationthat is isogenous to E and has A’ != 0 and B’ != 0.
(One might do this, for example, using ; for details, see , Appendix A.)
This isogeny defines a map iso_map(x’, y’) that 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 ESign 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 MUST return the identity point on E.Operations:See or , Section 4.3 for details on implementing the isogeny map.The mapping defined in this section applies to a target curve M defined by the equationPreconditions: 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: Inputs u and -u give the same s-coordinate.
Thus, we set sgn0(t) == sgn0(u).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:The following procedure implements Elligator 2 in a straight-line fashion.
gives optimized straight-line procedures for curve25519 and
curve448 .Twisted Edwards curves (a class of curves that includes Edwards curves)
are given by the equationwith 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.There are two ways to identify the correct Montgomery curve and
rational map for use when hashing to a given twisted Edwards curve.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 MUST be used to ensure compatibility
with existing software.
Two such standardized curves are the edwards25519 and edwards448 curves,
which correspond to the Montgomery curves curve25519 and curve448, respectively.
For both of these curves, lists both the Montgomery and twisted Edwards
forms and gives the corresponding rational maps.The rational map for edwards25519 (, Section 4.1)
uses the constant sqrt_neg_486664 = sqrt(-486664) (mod 2^255 - 19).
To ensure compatibility, this constant MUST be chosen such that
sgn0(sqrt_neg_486664) == 1.
Analogous ambiguities in other standardized rational maps MUST be
resolved in the same way: for any constant k whose sign is ambiguous,
k MUST be chosen such that sgn0(k) == 1.The 4-isogeny map from curve448 to edwards448 (, Section 4.2)
is unambiguous with respect to sign.When defining new twisted Edwards curves, a Montgomery equivalent and rational
map SHOULD be specified, and the sign of the rational map SHOULD be stated
unambiguously.When hashing to a twisted Edwards curve that does not have a standardized
Montgomery form or rational map, the following procedure MUST be
used to derive them.
For a twisted Edwards curve given byfirst compute J and K, the parameters of the equivalent Montgomery
curve given byas follows:J = 2 * (a + d) / (a - d)K = 4 / (a - d)Note that this curve has the form required by the Elligator 2
mapping of .
The rational map from the point (s, t) on this Montgomery curve
to the point (v, w) on the twisted Edwards curve is given byv = s / tw = (s - 1) / (s + 1)(For completeness, we give the inverse map in .
Note that the inverse map is not used when hashing to a twisted Edwards curve.)Rational maps may be undefined on certain inputs, e.g., when the
denominator of one of the rational functions is zero.
In the map described above, the exceptional cases are t == 0 or s == -1.
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.
Implementations of other rational maps (e.g., the ones give in )
are analogous.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.)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.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 .Wahby and Boneh (, Section 5) describe a trick due to Scott for
fast cofactor clearing on any elliptic curve for which the prime
factorization of h and the structure of the elliptic curve group meet
certain conditions.The clear_cofactor function is parameterized by a scalar h_eff.
Specifically,where * represents scalar multiplication.
When a curve does not support a fast cofactor clearing method, h_eff = h
and the cofactor MUST be cleared via scalar multiplication.When a curve admits a fast cofactor clearing method, clear_cofactor
MAY be evaluated either via that method or via scalar multiplication
by the equivalent h_eff; these two methods give the same result.
Note that in this case scalar multiplication by the cofactor h does not
generally give the same result as the fast method, and SHOULD NOT be used.This section lists recommended suites for hashing to standard elliptic curves.A suite fully specifies the procedure for hashing byte strings to
points on a specific elliptic curve group.
Each suite comprises the following parameters:Suite ID, a short name used to refer to a given suite.
discusses the naming conventions for suite IDs.encoding type, either random oracle (hash_to_curve) or nonuniform (encode_to_curve).
See for definitions of these encoding types.E, the target elliptic curve over a field F.p, the characteristic of the field F.m, the extension degree of the field F.k, the target security level of the suite in bits.sgn0, one of the variants specified in .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’, and/or iso_map.
These MUST be specified when applicable.All applications MUST choose a domain separation tag (DST)
in accordance with the guidelines in .
In addition, applications whose security requires a random oracle
that returns points on the target curve MUST use a suite whose
encoding type is hash_to_curve (); see .The below table lists the curves for which suites are defined and
the subsection that gives the corresponding parameters.ESectionNIST P-256NIST P-384NIST P-521curve25519 / edwards25519curve448 / edwards448secp256k1BLS12-381This 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 = -3B = 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604bp: 2^256 - 2^224 + 2^192 + 2^96 - 1m: 1k: 128sgn0: sgn0_le ()expand_message: expand_message_xmd ()H: SHA-256L: 48f: Simplified SWU method, Z: -10h_eff: 1P256_XMD:SHA-256_SVDW_RO_ is identical to P256_XMD:SHA-256_SSWU_RO_,
except for the following parameters:f: Shallue-van de Woestijne method, Z: -3P256_XMD:SHA-256_SSWU_NU_ is identical to P256_XMD:SHA-256_SSWU_RO_,
except that the encoding type is encode_to_curve ().P256_XMD:SHA-256_SVDW_NU_ is identical to P256_XMD:SHA-256_SVDW_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 .This section defines ciphersuites for the NIST P-384 elliptic curve .P384_XMD:SHA-512_SSWU_RO_ is defined as follows:encoding type: hash_to_curve ()E: y^2 = x^3 + A * x + B, where
A = -3B = 0xb3312fa7e23ee7e4988e056be3f82d19181d9c6efe8141120314088f5013875ac656398d8a2ed19d2a85c8edd3ec2aefp: 2^384 - 2^128 - 2^96 + 2^32 - 1m: 1k: 192sgn0: sgn0_le ()expand_message: expand_message_xmd ()H: SHA-512L: 72f: Simplified SWU method, Z: -12h_eff: 1P384_XMD:SHA-512_SVDW_RO_ is identical to P384_XMD:SHA-512_SSWU_RO_,
except for the following parameters:f: Shallue-van de Woestijne method, Z: -1P384_XMD:SHA-512_SSWU_NU_ is identical to P384_XMD:SHA-512_SSWU_RO_,
except that the encoding type is encode_to_curve ().P384_XMD:SHA-512_SVDW_NU_ is identical to P384_XMD:SHA-512_SVDW_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 .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 = -3B = 0x51953eb9618e1c9a1f929a21a0b68540eea2da725b99b315f3b8b489918ef109e156193951ec7e937b1652c0bd3bb1bf073573df883d2c34f1ef451fd46b503f00p: 2^521 - 1m: 1k: 256sgn0: sgn0_le ()expand_message: expand_message_xmd ()H: SHA-512L: 96f: Simplified SWU method, Z: -4h_eff: 1P521_XMD:SHA-512_SVDW_RO_ is identical to P521_XMD:SHA-512_SSWU_RO_,
except for the following parameters:f: Shallue-van de Woestijne method, Z: 1P521_XMD:SHA-512_SSWU_NU_ is identical to P512_XMD:SHA-512_SSWU_RO_,
except that the encoding type is encode_to_curve ().P521_XMD:SHA-512_SVDW_NU_ is identical to P512_XMD:SHA-512_SVDW_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 .This section defines ciphersuites for curve25519 and edwards25519 .curve25519_XMD:SHA-256_ELL2_RO_ is defined as follows:encoding type: hash_to_curve ()E: K * t^2 = s^3 + J * s^2 + s, where
J = 486662K = 1p: 2^255 - 19m: 1k: 128sgn0: sgn0_le ()expand_message: expand_message_xmd ()H: SHA-256L: 48f: Elligator 2 method, Z: 2h_eff: 8edwards25519_XMD:SHA-256_ELL2_RO_ is identical to curve25519_XMD:SHA-256_ELL2_RO_,
except for the following parameters:E: a * v^2 + w^2 = 1 + d * v^2 * w^2, where
a = -1d = 0x52036cee2b6ffe738cc740797779e89800700a4d4141d8ab75eb4dca135978a3f: Twisted Edwards Elligator 2 method, M: curve25519 defined in , Section 4.1rational_map: the birational map defined in , Section 4.1curve25519_XMD:SHA-256_ELL2_NU_ is identical to curve25519_XMD:SHA-256_ELL2_RO_,
except that the encoding type is encode_to_curve ().edwards25519_XMD:SHA-256_ELL2_NU_ is identical to edwards25519_XMD:SHA-256_ELL2_RO_,
except that ene encoding type is encode_to_curve ().curve25519_XMD:SHA-512_ELL2_RO_ is identical to curve25519_XMD:SHA-256_ELL2_RO_,
except that H is SHA-512.curve25519_XMD:SHA-512_ELL2_NU_ is identical to curve25519_XMD:SHA-256_ELL2_NU_,
except that H is SHA-512.edwards25519_XMD:SHA-512_ELL2_RO_ is identical to edwards25519_XMD:SHA-256_ELL2_RO_,
except that H is SHA-512.edwards25519_XMD:SHA-512_ELL2_NU_ is identical to edwards25519_XMD:SHA-256_ELL2_NU_,
except that H is SHA-512.Optimized example implementations of the above mappings are given in
and .This section defines ciphersuites for curve448 and edwards448 .curve448_XMD:SHA-512_ELL2_RO_ is defined as follows:encoding type: hash_to_curve ()E: K * t^2 = s^3 + J * s^2 + s, where
J = 156326K = 1p: 2^448 - 2^224 - 1m: 1k: 224sgn0: sgn0_le ()expand_message: expand_message_xmd ()H: SHA-512L: 84f: Elligator 2 method, Z: -1h_eff: 4edwards448_XMD:SHA-512_ELL2_RO_ is identical to curve448_XMD:SHA-512_ELL2_RO_,
except for the following parameters:E: a * v^2 + w^2 = 1 + d * v^2 * w^2, where
a = 1d = -39081f: Twisted Edwards Elligator 2 method, M: curve448, defined in , Section 4.2rational_map: the 4-isogeny map defined in , Section 4.2curve448_XMD:SHA-512_ELL2_NU_ is identical to curve448_XMD:SHA-512_ELL2_RO_,
except that the encoding type is encode_to_curve ().edwards448_XMD:SHA-512_ELL2_NU_ is identical to edwards448_XMD:SHA-512_ELL2_RO_,
except that the encoding type is encode_to_curve ().Optimized example implementations of the above mappings are given in
and .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 + 7p: 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1m: 1k: 128sgn0: sgn0_le ()expand_message: expand_message_xmd ()H: SHA-256L: 48f: Simplified SWU for AB == 0, Z: -11E’: y’^2 = x’^3 + A’ * x’ + B’, where
A’: 0x3f8731abdd661adca08a5558f0f5d272e953d363cb6f0e5d405447c01a444533B’: 1771iso_map: the 3-isogeny map from E’ to E given in h_eff: 1secp256k1_XMD:SHA-256_SVDW_RO_ is identical to secp256k1_XMD:SHA-256_SSWU_RO_,
except for the following parameters:f: Shallue-van de Woestijne method, Z: 1E’ is not required for this suiteiso_map is not required for this suitesecp256k1_XMD:SHA-256_SSWU_NU_ is identical to secp256k1_XMD:SHA-256_SSWU_RO_,
except that the encoding type is encode_to_curve ().secp256k1_XMD:SHA-256_SVDW_NU_ is identical to secp256k1_XMD:SHA-256_SVDW_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 .This section defines ciphersuites for groups G1 and G2 of
the BLS12-381 elliptic curve .BLS12381G1_XMD:SHA-256_SSWU_RO_ is defined as follows:encoding type: hash_to_curve ()E: y^2 = x^3 + 4p: 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaabm: 1k: 128sgn0: sgn0_be ()expand_message: expand_message_xmd ()H: SHA-256L: 64f: Simplified SWU for AB == 0, Z: 11E’: y’^2 = x’^3 + A’ * x’ + B’, where
A’ = 0x144698a3b8e9433d693a02c96d4982b0ea985383ee66a8d8e8981aefd881ac98936f8da0e0f97f5cf428082d584c1dB’ = 0x12e2908d11688030018b12e8753eee3b2016c1f0f24f4070a0b9c14fcef35ef55a23215a316ceaa5d1cc48e98e172be0iso_map: the 11-isogeny map from E’ to E given in h_eff: 0xd201000000010001BLS12381G1_XMD:SHA-256_SVDW_RO_ is identical to BLS12381G1_XMD:SHA-256_SSWU_RO_,
except for the following parameters:f: Shallue-van de Woestijne method, Z: -3E’ is not required for this suiteiso_map is not required for this suiteBLS12381G1_XMD:SHA-256_SSWU_NU_ is identical to BLS12381G1_XMD:SHA-256_SSWU_RO_,
except that the encoding type is encode_to_curve ().BLS12381G1_XMD:SHA-256_SVDW_NU_ is identical to BLS12381G1_XMD:SHA-256_SVDW_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 .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: 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaabm: 2(1, I) is the basis for F, where I^2 + 1 == 0 in Fk: 128sgn0: sgn0_be ()expand_message: expand_message_xmd ()H: SHA-256L: 64f: Simplified SWU for AB == 0, Z: -(2 + I)E’: y’^2 = x’^3 + A’ * x’ + B’, where
A’ = 240 * IB’ = 1012 * (1 + I)iso_map: the isogeny map from E’ to E given in h_eff: 0xbc69f08f2ee75b3584c6a0ea91b352888e2a8e9145ad7689986ff031508ffe1329c2f178731db956d82bf015d1212b02ec0ec69d7477c1ae954cbc06689f6a359894c0adebbf6b4e8020005aaa95551BLS12381G2_XMD:SHA-256_SVDW_RO_ is identical to BLS12381G2_XMD:SHA-256_SSWU_RO_,
except for the following parameters:f: Shallue-van de Woestijne method, Z: IE’ is not required for this suiteiso_map is not required for this suiteBLS12381G2_XMD:SHA-256_SSWU_NU_ is identical to BLS12381G2_XMD:SHA-256_SSWU_RO_,
except that the encoding type is encode_to_curve ().BLS12381G2_XMD:SHA-256_SVDW_NU_ is identical to BLS12381G2_XMD:SHA-256_SVDW_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).The RECOMMENDED way to define a new hash-to-curve suite is:E, F, p, and m are determined by the elliptic curve and its base field;
k is determined by the security level of the elliptic curve.Choose encoding type, either hash_to_curve or encode_to_curve ().Choose a sgn0 variant following the guidelines in .Compute L as described in .Choose an expand_message variant from plus any
underlying cryptographic primitives (e.g., a hash function H).Choose a mapping following the guidelines in ,
and select any required parameters for that mapping.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 .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 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)
other underscore (i.e., 0x5f).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: For expand_message_xof () with SHAKE-128,
HASH_ID is “XOF:SHAKE-128”.For expand_message_xmd () with SHA3-256,
HASH_ID is “XMD:SHA3-256”.MAP_ID: a human-readable representation of the map_to_curve function
as defined in . These are defined as follows: “SVDW” for or Shallue and van de Woestijne ().“SSWU” for Simplified SWU (, ).“ELL2” for Elligator 2 (, ).ENC_VAR: a string indicating the encoding type and other information.
The first two characters of this string indicate whether the suite
represents a hash_to_curve or an encode_to_curve operation
(), as follows: If ENC_VAR begins with “RO”, the suite uses hash_to_curve.If ENC_VAR begins with “NU”, the suite uses encode_to_curve.ENC_VAR MUST NOT begin with any other string.
ENC_VAR MAY also be used to encode other information used to identify
variants, for example, a version number.
The RECOMMENDED way to do so is to add one or more subfields separated
by colons.
For example, “RO:V02” is an appropriate ENC_VAR value for the second
version of a random-oracle suite, while “RO:V02:FOO01:BAR17” might be
used to indicate a variant of that suite.This document has no IANA actions.When constant-time implementations are required, all basic operations and
utility functions must be implemented in constant time, as discussed in
.
In some applications (e.g., embedded systems), leakage through other side
channels (e.g., power or electromagnetic side channels) may be pertinent.
Defending against such leakage is outside the scope of this document, because
the nature of the leakage and the appropriate defense depends on the protocol
from which a hash-to-curve function is invoked. describes considerations related to domain separation. describes considerations for uniformly hashing to field elements;
see and
for further discussion.Each encoding variant () accepts an arbitrary byte string and maps
it to a pseudorandom point on the curve.
Note, however, that directly evaluating the mappings of produces
an output that is distinguishable from random.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 most cases such a function can be safely used in protocols whose security
analysis assumes a random oracle that outputs points on an elliptic curve.
As Ristenpart et al. discuss in , however, not all security proofs
that rely on random oracles continue to hold when those oracles are replaced
by indifferentiable functionalities.
This limitation should be considered when analyzing the security of protocols
relying on the hash_to_curve function.When hashing passwords using any function described in this document, an adversary
who learns the output of the hash function (or potentially any intermediate value,
e.g., the output of hash_to_field) may be able to carry out a dictionary attack.
To mitigate such attacks, it is recommended to first execute a more costly key
derivation function (e.g., PBKDF2 or scrypt ) on the password,
then hash the output of that function to the target elliptic curve.
For collision resistance, the hash underlying the key derivation function
should be chosen according to the guidelines listed in .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.)Finally, the expand_message variants in this document ()
always append the domain separation tag DST to the strings hashed by H, the
underlying hash or extensible output function.
This means that invocations of H outside of hash_to_field can be separated
from those inside of hash_to_field by appending a tag distinct from DST to
their inputs.
Other expand_message variants that follow the guidelines in
are expected to have similar properties,
but these should be analyzed on a case-by-case basis.The expand_message_xmd function defined in is
indifferentiable from a random oracle when one of the following holds:H is indifferentiable from a random oracle,H is a sponge-based hash function whose inner function
is modeled as a random transformation or random permutation , orH is a Merkle-Damgaard hash function whose compression function is
modeled as a random oracle .For cases (1) and (2), the indifferentiability of expand_message_xmd follows
directly from the indifferentiability of H.For case (3), i.e., for H a Merkle-Damgaard hash function, indifferentiability
follows from , Theorem 3.5.
In particular, expand_message_xmd computes b_0 by prepending one block of
0-bytes to the message and auxiliary information (length, counter, and DST).
Then, each of the output blocks b_i, i >= 1 in expand_message_xmd is the
result of invoking H on a unique, prefix-free encoding of b_0.
This is true, first, because the length of the input to all such invocations
is equal and fixed by the choice of H and DST, and
second, because each such input has a unique suffix (because of the inclusion
of the counter byte I2OSP(i, 1)).The essential difference between the construction of and
expand_message_xmd is that the latter hashes a counter appended to
strxor(b_0, b_(i - 1)) (step 9) 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.The authors would like to thank Adam Langley for his detailed writeup of Elligator 2 with
Curve25519 ;
Dan Boneh, Christopher Patton, and Benjamin Lipp for educational discussions; and
Sean Devlin, Justin Drake, Dan Harkins, Thomas Icart, Andy Polyakov, Leonid Reyzin, Michael Scott,
and Mathy Vanhoef for helpful feedback.Sharon Goldberg
Boston University
goldbe@cs.bu.eduEla Lee
Royal Holloway, University of London
Ela.Lee.2010@live.rhul.ac.ukKey words for use in RFCs to Indicate Requirement LevelsIn 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.PKCS #1: RSA Cryptography Specifications Version 2.2This 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 SecurityThis 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.Edwards-Curve Digital Signature Algorithm (EdDSA)This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.PKCS #5: Password-Based Cryptography Specification Version 2.0This 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 FunctionThis 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.BLS12-381: New zk-SNARK Elliptic Curve ConstructionElectric Coin CompanySEC 1: Elliptic Curve CryptographyStandards for Efficient Cryptography Group (SECG)SEC 2: Recommended Elliptic Curve Domain ParametersStandards for Efficient Cryptography Group (SECG)Secure Hash Standard (SHS)National Institute of Standards and Technology (NIST)FIPS Publication 186-4: Digital Signature StandardNational Institute of Standards and Technology (NIST)SHA-3 Standard: Permutation-Based Hash and Extendable-Output FunctionsNational Institute of Standards and Technology (NIST)On the Indifferentiability of the Sponge ConstructionSTMicroelectronicsSTMicroelectronicsNXP SemiconductorsSTMicroelectronicsMerkle-Damgaard Revisited: How to Construct a Hash FunctionUniversity of LuxembourgNew York UniversityUniversity of LuxembourgNew York UniversityDomain extension of public random functions: Beyond the birthday barrierETH ZurichETH ZurichImproved indifferentiability security analysis for ChopMD hash functionGeneric indifferentiability proofs of hash designsBLAKE2XHow to Hash into Elliptic CurvesSagem Securite and Universite du LuxembourgTwisted Edwards curvesDepartment of Computer Science, University of Illinois at Chicago, USADepartment of Mathematics and Computer Science, Technische Universiteit Eindhoven, The NetherlandsThomson R&D FranceDepartment of Mathematics and Computer Science, Technische Universiteit Eindhoven, The NetherlandsDepartment of Mathematics and Computer Science, Technische Universiteit Eindhoven, The NetherlandsThe geometry of flex tangents to a cubic curve and its parameterizationsUniversite BordeauxUniversite de RennesHashing into Hessian curvesMacquarie UniversitOn hashing into elliptic curvesMacquarie UniversitMacquarie UniversitUniversity of TexasEstimating the size of the image of deterministic hash functions to elliptic curves.Ecole Normale Superieure and INRIA RennesNTT Secure Platform LaboratoriesIndifferentiable Hashing to Barreto-Naehrig CurvesEcole Normale Superieure and INRIA RennesNTT Secure Platform LaboratoriesInjective encodings to elliptic curvesEcole Normale Superieure and INRIA RennesSorbonne UniversiteNTT Secure Platform LaboratoriesEncoding points on hyperelliptic curves over finite fields in deterministic polynomial timeUniversite de RennesUniversite de RennesUniversite Pierre et Marie CurieSquare Root Computation over Even Extension FieldsISFA, Universite Claude Bernard Lyon 1, Villeurbanne, FranceCINVESTAV-IPN, San Pedro Zacatenco, Mexico City, Mexico.Pairing-Friendly Elliptic Curves of Prime OrderEscola Politecnica, Universidade de Sao Paulo, Sao Paulo, BrazilLehrstuhl fur Theoretische Informationstechnik, Rheinisch-Westfalische Technische Hochschule Aachen, Aachen, GermanyBinary Elligator squaredInstitute of Computing, University of CampinasUniversite de Rennes 1 and Institut Universitaire de FranceENS RennesNTT Secure Platform LaboratoriesINRIAElligator squared: Uniform points on elliptic curves of prime order as uniform random stringsNTT Secure Platform LaboratoriesImproved elliptic curve hashing and point representationNTT Secure Platform LaboratoriesNTT Secure Platform LaboratoriesIdentity-based encryption from the Weil pairingStanford UniversityUC DavisShort signatures from the Weil pairingStanford UniversityStanford UniversityStanford UniversityConstructing Elliptic Curves with Prescribed Embedding DegreesUniversidade de Sao Paulo, BrazilStanford UniversityDublin City University, IrelandProvably secure password-authenticated key exchange using Diffie-HellmanMIT Laboratory for Computer ScienceBell Laboratories, Lucent TechnologiesBell Laboratories, Lucent TechnologiesStrong password-only authenticated key exchangeIntegrity Sciences, Inc. Westboro, MA.Hashing to Elliptic Curves - GitHub repositoryzkcrypto/jubjub - fq.rsImplementing Elligator for Curve25519Fast Hashing to G2 on Pairing-Friendly CurvesSchool 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 CurvesComputer Science Department, CINVESTAV-IPN. MexicoDept. Combinatorics & Optimization, University of Waterloo, CanadaComputer Science Department, CINVESTAV-IPN. MexicoEfficient hash maps to G2 on BLS curvesUniversity of Bergen, Norway and MIRACL Labs, London, EnglandUniversity of Trento, ItalyElligator: elliptic-curve points indistinguishable from uniform random stringsDepartment of Computer Science, University of Illinois at Chicago, USACryptography Research, a division of Rambus, USAPrivacy & Identity lab, Institute for Computing and Information Sciences, Radboud University Nijmegen, The NetherlandsDepartment of Mathematics and Computer Science, Technische Universiteit Eindhoven, The NetherlandsQuantum circuits for the CSIDH: optimizing quantum evaluation of isogeniesDepartment of Computer Science, University of Illinois at Chicago, USADepartment of Mathematics and Computer Science, Technische Universiteit Eindhoven, The NetherlandsDepartment of Mathematics and Computer Science, Technische Universiteit Eindhoven, The NetherlandsDepartment of Mathematics and Computer Science, Technische Universiteit Eindhoven, The NetherlandsOn equations y^2 = x^n + k in a finite field.Department of Mathemetics, University of WarsawDepartment of Mathematics, University of WarsawPoints on elliptic curves over finite fieldsDepartment of Mathematics, University of WarsawConstruction of rational points on elliptic curves over finite fieldsMathematics Department, University of Wisconsin-Madison. Madison, USA.Mathematisch Instituut, Universiteit Leiden. Leiden, The Netherlands.Rational points on certain hyperelliptic curves over finite fieldsInstitute of Mathematics, Jagiellonian University. PolandEfficient Indifferentiable Hashing into Ordinary Elliptic CurvesIngenicoUniversite du LuxembourgUniversite du LuxembourgTELECOM-ParisTechTELECOM-ParisTechUniversite du Luxembourg, Ecole normale superieureElliptic curves: Number theory and cryptographyA Course in Computational Algebraic Number TheoryHandbook of Elliptic and Hyperelliptic Curve CryptographyFast and simple constant-time hashing to the BLS12-381 elliptic curveStanford UniversityStanford UniversityIndifferentiable deterministic hashing to elliptic and hyperelliptic curvesMacquarie UniversitEcole normale superieureMacquarie UniversitEcole normale superieureUniversity of TexasIndifferentiability, impossibility results on reductions, and applications to the random oracle methodologyETH ZurichETH ZurichETH ZurichElliptic Curves Over Finite Fields and the Computation of Square Roots mod pSageMath, the Sage Mathematics Software SystemThe Sage DevelopersA Mechanised Proof of the WireGuard Virtual Private Network ProtocolINRIA ParisINRIA ParisINRIA ParisCareful with Composition: Limitations of the Indifferentiability FrameworkUniversity of Wisconsin-MadisonUC San DiegoPortland State UniversityAn explicit, generic parameterization for the Shallue--van de Woestijne mapStanford UniversityIEEE Standard Specifications for Public-Key Cryptography---Amendment 1: Additional TechniquesIEEE Computer SocietyPublic Key Cryptography for the Financial Services Industry: the Elliptic Curve Digital Signature Algorithm (ECDSA)ANSIThe 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 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 pseudorandom
value x in F.
If x is the x-coordinate of a point on the elliptic curve, output that
point. Otherwise, generate a new pseudorandom 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.This section gives several useful rational maps.This section gives a generic birational map between twisted Edwards
and Montgomery curves.
This birational map comprises the rational map specified in
and its inverse.The twisted Edwards curveis birationally equivalent to the Montgomery curveby the following mappings (, Theorem 3.2).
To convert from twisted Edwards to Montgomery form, the mapping isJ = 2 * (a + d) / (a - d)K = 4 / (a - d)s = (1 + w) / (1 - w)t = (1 + w) / (v * (1 - w))This mapping is defined when a != d, which is guaranteed by the definition
of twisted Edwards curves.
The mapping is undefined when v == 0 or w == 1.
If (v, w) == (0, -1), return the point (s, t) = (0, 0).
For all other undefined inputs, return the identity point on the Montgomery curve.
(This follows from , Section 3.)To convert from Montgomery to twisted Edwards form, the mapping isa = (J + 2) / Kd = (J - 2) / Kv = s / tw = (s - 1) / (s + 1)This mapping is defined when J != 2, J != -2, and K != 0; all Montgomery
curves meet these criteria.
The mapping is undefined when t == 0 or s == -1.
If (s, t) == (0, 0), return the point (v, w) = (0, -1).
For all other undefined inputs, return the identity point on the twisted
Edwards curve, namely, (v, w) = (0, 1).
(This follows from , Section 3.)(Note that gives a simpler rule for handling undefined
inputs to this rational map: always return the identity point.
The simpler rule gives the same result when used as part of an encoding
function (), because the cofactor clearing step will always
map the point (v, w) = (0, -1) to the identity point.)Composing the mapping of this section with the mapping from
Montgomery to Weierstrass curves in
yields a mapping from twisted Edwards curves to Weierstrass curves,
which is the form required by the mappings in .
This composition of mappings can be used to apply the Shallue-van
de Woestijne () or Simplified SWU () method
to twisted Edwards curves.The rational map from the point (s, t) on the Montgomery curveto the point (x, y) on the equivalent Weierstrass curveis 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 / KThe inverse map, from the point (x, y) to the point (s, t), is given bys = (3 * K * x - J) / 3t = y * KThis mapping can be used to apply the Shallue-van de Woestijne
() or Simplified SWU () method to
Montgomery curves.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.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) = 0x8e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38daaaaa8c7k_(1,1) = 0x7d3d4c80bc321d5b9f315cea7fd44c5d595d2fc0bf63b92dfff1044f17c6581k_(1,2) = 0x534c328d23f234e6e2a413deca25caece4506144037c40314ecbd0b53d9dd262k_(1,3) = 0x8e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38e38daaaaa88cThe constants used to compute x_den are as follows:k_(2,0) = 0xd35771193d94918a9ca34ccbb7b640dd86cd409542f8487d9fe6b745781eb49bk_(2,1) = 0xedadc6f64383dc1df7c4b2d51b54225406d36b641f5e41bbc52a56612a8c6d14The constants used to compute y_num are as follows:k_(3,0) = 0x4bda12f684bda12f684bda12f684bda12f684bda12f684bda12f684b8e38e23ck_(3,1) = 0xc75e0c32d5cb7c0fa9d0a54b12a0a6d5647ab046d686da6fdffc90fc201d71a3k_(3,2) = 0x29a6194691f91a73715209ef6512e576722830a201be2018a765e85a9ecee931k_(3,3) = 0x2f684bda12f684bda12f684bda12f684bda12f684bda12f684bda12f38e38d84The constants used to compute y_den are as follows:k_(4,0) = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffff93bk_(4,1) = 0x7a06534bb8bdb49fd5e9e6632722c2989467c1bfc8e8d978dfb425d2685c2573k_(4,2) = 0x6484aa716545ca2cf3a70c3fa8fe337e0a3d21162f0d6299a7bf8192bfd2a76fThe 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) = 0x11a05f2b1e833340b809101dd99815856b303e88a2d7005ff2627b56cdb4e2c85610c2d5f2e62d6eaeac1662734649b7k_(1,1) = 0x17294ed3e943ab2f0588bab22147a81c7c17e75b2f6a8417f565e33c70d1e86b4838f2a6f318c356e834eef1b3cb83bbk_(1,2) = 0xd54005db97678ec1d1048c5d10a9a1bce032473295983e56878e501ec68e25c958c3e3d2a09729fe0179f9dac9edcb0k_(1,3) = 0x1778e7166fcc6db74e0609d307e55412d7f5e4656a8dbf25f1b33289f1b330835336e25ce3107193c5b388641d9b6861k_(1,4) = 0xe99726a3199f4436642b4b3e4118e5499db995a1257fb3f086eeb65982fac18985a286f301e77c451154ce9ac8895d9k_(1,5) = 0x1630c3250d7313ff01d1201bf7a74ab5db3cb17dd952799b9ed3ab9097e68f90a0870d2dcae73d19cd13c1c66f652983k_(1,6) = 0xd6ed6553fe44d296a3726c38ae652bfb11586264f0f8ce19008e218f9c86b2a8da25128c1052ecaddd7f225a139ed84k_(1,7) = 0x17b81e7701abdbe2e8743884d1117e53356de5ab275b4db1a682c62ef0f2753339b7c8f8c8f475af9ccb5618e3f0c88ek_(1,8) = 0x80d3cf1f9a78fc47b90b33563be990dc43b756ce79f5574a2c596c928c5d1de4fa295f296b74e956d71986a8497e317k_(1,9) = 0x169b1f8e1bcfa7c42e0c37515d138f22dd2ecb803a0c5c99676314baf4bb1b7fa3190b2edc0327797f241067be390c9ek_(1,10) = 0x10321da079ce07e272d8ec09d2565b0dfa7dccdde6787f96d50af36003b14866f69b771f8c285decca67df3f1605fb7bk_(1,11) = 0x6e08c248e260e70bd1e962381edee3d31d79d7e22c837bc23c0bf1bc24c6b68c24b1b80b64d391fa9c8ba2e8ba2d229The constants used to compute x_den are as follows:k_(2,0) = 0x8ca8d548cff19ae18b2e62f4bd3fa6f01d5ef4ba35b48ba9c9588617fc8ac62b558d681be343df8993cf9fa40d21b1ck_(2,1) = 0x12561a5deb559c4348b4711298e536367041e8ca0cf0800c0126c2588c48bf5713daa8846cb026e9e5c8276ec82b3bffk_(2,2) = 0xb2962fe57a3225e8137e629bff2991f6f89416f5a718cd1fca64e00b11aceacd6a3d0967c94fedcfcc239ba5cb83e19k_(2,3) = 0x3425581a58ae2fec83aafef7c40eb545b08243f16b1655154cca8abc28d6fd04976d5243eecf5c4130de8938dc62cd8k_(2,4) = 0x13a8e162022914a80a6f1d5f43e7a07dffdfc759a12062bb8d6b44e833b306da9bd29ba81f35781d539d395b3532a21ek_(2,5) = 0xe7355f8e4e667b955390f7f0506c6e9395735e9ce9cad4d0a43bcef24b8982f7400d24bc4228f11c02df9a29f6304a5k_(2,6) = 0x772caacf16936190f3e0c63e0596721570f5799af53a1894e2e073062aede9cea73b3538f0de06cec2574496ee84a3ak_(2,7) = 0x14a7ac2a9d64a8b230b3f5b074cf01996e7f63c21bca68a81996e1cdf9822c580fa5b9489d11e2d311f7d99bbdcc5a5ek_(2,8) = 0xa10ecf6ada54f825e920b3dafc7a3cce07f8d1d7161366b74100da67f39883503826692abba43704776ec3a79a1d641k_(2,9) = 0x95fc13ab9e92ad4476d6e3eb3a56680f682b4ee96f7d03776df533978f31c1593174e4b4b7865002d6384d168ecdd0aThe constants used to compute y_num are as follows:k_(3,0) = 0x90d97c81ba24ee0259d1f094980dcfa11ad138e48a869522b52af6c956543d3cd0c7aee9b3ba3c2be9845719707bb33k_(3,1) = 0x134996a104ee5811d51036d776fb46831223e96c254f383d0f906343eb67ad34d6c56711962fa8bfe097e75a2e41c696k_(3,2) = 0xcc786baa966e66f4a384c86a3b49942552e2d658a31ce2c344be4b91400da7d26d521628b00523b8dfe240c72de1f6k_(3,3) = 0x1f86376e8981c217898751ad8746757d42aa7b90eeb791c09e4a3ec03251cf9de405aba9ec61deca6355c77b0e5f4cbk_(3,4) = 0x8cc03fdefe0ff135caf4fe2a21529c4195536fbe3ce50b879833fd221351adc2ee7f8dc099040a841b6daecf2e8fedbk_(3,5) = 0x16603fca40634b6a2211e11db8f0a6a074a7d0d4afadb7bd76505c3d3ad5544e203f6326c95a807299b23ab13633a5f0k_(3,6) = 0x4ab0b9bcfac1bbcb2c977d027796b3ce75bb8ca2be184cb5231413c4d634f3747a87ac2460f415ec961f8855fe9d6f2k_(3,7) = 0x987c8d5333ab86fde9926bd2ca6c674170a05bfe3bdd81ffd038da6c26c842642f64550fedfe935a15e4ca31870fb29k_(3,8) = 0x9fc4018bd96684be88c9e221e4da1bb8f3abd16679dc26c1e8b6e6a1f20cabe69d65201c78607a360370e577bdba587k_(3,9) = 0xe1bba7a1186bdb5223abde7ada14a23c42a0ca7915af6fe06985e7ed1e4d43b9b3f7055dd4eba6f2bafaaebca731c30k_(3,10) = 0x19713e47937cd1be0dfd0b8f1d43fb93cd2fcbcb6caf493fd1183e416389e61031bf3a5cce3fbafce813711ad011c132k_(3,11) = 0x18b46a908f36f6deb918c143fed2edcc523559b8aaf0c2462e6bfe7f911f643249d9cdf41b44d606ce07c8a4d0074d8ek_(3,12) = 0xb182cac101b9399d155096004f53f447aa7b12a3426b08ec02710e807b4633f06c851c1919211f20d4c04f00b971ef8k_(3,13) = 0x245a394ad1eca9b72fc00ae7be315dc757b3b080d4c158013e6632d3c40659cc6cf90ad1c232a6442d9d3f5db980133k_(3,14) = 0x5c129645e44cf1102a159f748c4a3fc5e673d81d7e86568d9ab0f5d396a7ce46ba1049b6579afb7866b1e715475224bk_(3,15) = 0x15e6be4e990f03ce4ea50b3b42df2eb5cb181d8f84965a3957add4fa95af01b2b665027efec01c7704b456be69c8b604The constants used to compute y_den are as follows:k_(4,0) = 0x16112c4c3a9c98b252181140fad0eae9601a6de578980be6eec3232b5be72e7a07f3688ef60c206d01479253b03663c1k_(4,1) = 0x1962d75c2381201e1a0cbd6c43c348b885c84ff731c4d59ca4a10356f453e01f78a4260763529e3532f6102c2e49a03dk_(4,2) = 0x58df3306640da276faaae7d6e8eb15778c4855551ae7f310c35a5dd279cd2eca6757cd636f96f891e2538b53dbf67f2k_(4,3) = 0x16b7d288798e5395f20d23bf89edb4d1d115c5dbddbcd30e123da489e726af41727364f2c28297ada8d26d98445f5416k_(4,4) = 0xbe0e079545f43e4b00cc912f8228ddcc6d19c9f0f69bbb0542eda0fc9dec916a20b15dc0fd2ededda39142311a5001dk_(4,5) = 0x8d9e5297186db2d9fb266eaac783182b70152c65550d881c5ecd87b6f0f5a6449f38db9dfa9cce202c6477faaf9b7ack_(4,6) = 0x166007c08a99db2fc3ba8734ace9824b5eecfdfa8d0cf8ef5dd365bc400a0051d5fa9c01a58b1fb93d1a1399126a775ck_(4,7) = 0x16a3ef08be3ea7ea03bcddfabba6ff6ee5a4375efa1f4fd7feb34fd206357132b920f5b00801dee460ee415a15812ed9k_(4,8) = 0x1866c8ed336c61231a1be54fd1d74cc4f9fb0ce4c6af5920abc5750c4bf39b4852cfe2f7bb9248836b233d9d55535d4ak_(4,9) = 0x167a55cda70a6e1cea820597d94a84903216f763e13d87bb5308592e7ea7d4fbc7385ea3d529b35e346ef48bb8913f55k_(4,10) = 0x4d2f259eea405bd48f010a01ad2911d9c6dd039bb61a6290e591b36e636a5c871a5c29f4f83060400f8b49cba8f6aa8k_(4,11) = 0xaccbb67481d033ff5852c1e48c50c477f94ff8aefce42d28c0f9a88cea7913516f968986f7ebbea9684b529e2561092k_(4,12) = 0xad6b9514c767fe3c3613144b45f1496543346d98adf02267d5ceef9a00d9b8693000763e3b90ac11e99b138573345cck_(4,13) = 0x2660400eb2e4f3b628bdd0d53cd76f2bf565b94e72927c1cb748df27942480e420517bd8714cc80d1fadc1326ed06f7k_(4,14) = 0xe0fa1d816ddc03e6b24255e0d7819c171c40f65e273b853324efcd6356caa205ca2f570f13497804415473a1d634b8fThe 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 * Ik_(1,1) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c6b4f20a4181472aaa9cb8d555526a9ffffffffc71a * Ik_(1,2) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c6b4f20a4181472aaa9cb8d555526a9ffffffffc71e + 0x8ab05f8bdd54cde190937e76bc3e447cc27c3d6fbd7063fcd104635a790520c0a395554e5c6aaaa9354ffffffffe38d * Ik_(1,3) = 0x171d6541fa38ccfaed6dea691f5fb614cb14b4e7f4e810aa22d6108f142b85757098e38d0f671c7188e2aaaaaaaa5ed1The constants used to compute x_den are as follows:k_(2,0) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa63 * Ik_(2,1) = 0xc + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa9f * IThe constants used to compute y_num are as follows:k_(3,0) = 0x1530477c7ab4113b59a4c18b076d11930f7da5d4a07f649bf54439d87d27e500fc8c25ebf8c92f6812cfc71c71c6d706 + 0x1530477c7ab4113b59a4c18b076d11930f7da5d4a07f649bf54439d87d27e500fc8c25ebf8c92f6812cfc71c71c6d706 * Ik_(3,1) = 0x5c759507e8e333ebb5b7a9a47d7ed8532c52d39fd3a042a88b58423c50ae15d5c2638e343d9c71c6238aaaaaaaa97be * Ik_(3,2) = 0x11560bf17baa99bc32126fced787c88f984f87adf7ae0c7f9a208c6b4f20a4181472aaa9cb8d555526a9ffffffffc71c + 0x8ab05f8bdd54cde190937e76bc3e447cc27c3d6fbd7063fcd104635a790520c0a395554e5c6aaaa9354ffffffffe38f * Ik_(3,3) = 0x124c9ad43b6cf79bfbf7043de3811ad0761b0f37a1e26286b0e977c69aa274524e79097a56dc4bd9e1b371c71c718b10The constants used to compute y_den are as follows:k_(4,0) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffa8fb + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffa8fb * Ik_(4,1) = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffa9d3 * Ik_(4,2) = 0x12 + 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaa99 * IThis 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 .The sample code in this section uses a different interface than
the mappings of .
Specifically, each mapping function in this section has the following
signature:The resulting point (x, y) is given by (xn / xd, yn / yd).The reason for this modified interface is that it enables further
optimizations when working with points in a projective coordinate
system.
This is desirable, for example, when the resulting point will be
immediately multiplied by a scalar, since most scalar multiplication
algorithms operate on projective points.The following are two commonly used projective coordinate systems
and the corresponding conversions:A point (X, Y, Z) in homogeneous projective coordinates corresponds
to the affine point (x, y) = (X / Z, Y / Z);
the inverse conversion is given by (X, Y, Z) = (x, y, 1).
To convert (xn, xd, yn, yd) to homogeneous projective coordinates,
compute (X, Y, Z) = (xn * yd, yn * xd, xd * yd).A point (X’, Y’, Z’) in Jacobian projective coordinates corresponds
to the affine point (x, y) = (X’ / Z’^2, Y’ / Z’^3);
the inverse conversion is given by (X’, Y’, Z’) = (x, y, 1).
To convert (xn, xd, yn, yd) to Jacobian projective coordinates,
compute (X’, Y’, Z’) = (xn * xd * yd^2, yn * yd^2 * xd^3, xd * yd).The following is a straight-line implementation of the Simplified SWU
mapping that applies to any curve over GF(p) for p = 3 (mod 4).
This includes the ciphersuites for NIST curves P-256, P-384, and P-521 given in .
It also includes the curves isogenous to secp256k1 () and BLS12-381 G1 ().The implementations for these curves differ only in the constants
and the base field.
The constant definitions below are given in terms of the parameters for the
Simplified SWU mapping; for parameter values for the curves listed above, see
(P-256),
(P-384),
(P-521),
(E’ isogenous to secp256k1), and
(E’ isogenous to BLS12-381 G1).The following is a straight-line implementation of Elligator 2
for curve25519 as specified in .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 .The following is a straight-line implementation of Elligator 2
for curve448 as specified in .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 .This section gives Sage scripts used to generate parameters for the mappings of .The below function outputs an appropriate Z for the Shallue and van de Woestijne map ().The below function outputs an appropriate Z for the Simplified SWU map ().The below function outputs an appropriate Z for the Elligator 2 map ().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).
In addition, it gives a generic constant-time algorithm that works for any prime modulus. and describe optimized methods for extension fields.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.This section gives test vectors for each suite defined in {#suites}.
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.