]> Symantec Corporation

crypto@brainhub.org

General Network Workign Group ECC elliptic curve elliptic curve point compact representation point compression SEC1 cryptography This document defines a format for efficient storage representation of an elliptic curve point over prime fields, suitable for use with any IETF format or protocol.

The National Security Agency (NSA) of the United States specifies elliptic curve cryptography (ECC) for use in its set of algorithms. The NIST elliptic curves over the prime fields , which include curves, or the Brainpool curves are the examples of curves over prime fields. This document provides an efficient format for compact representation of a point on an elliptic curve over a prime field. It is intended as an open format that other IETF protocols can rely on to minimize space required to store an ECC point. This document complements the with the on-the-wire definition of an ECC point. The method described here can be applied to a various types of elliptic curves, see . One of the benefits of the ECC is the small size of field elements. The compact representation reduces the encoded size of an ECC element in half, which can be a substantial saving in cases such as encryption of a short message sent to multiple recipients.

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 .

IETF protocols often use the representation of a point on an elliptic curve, which is a sequence of the following fields: Field Description B0 {02, 03, 04}, where 02 or 03 represent a compressed point (x only), while 04 represents a complete point (x,y) X x coordinate of a point Y y coordinate of a point, optional (present only for B0=04) The is an example of a general-purpose elliptic curve point compression. The idea behind these methods is the following: For the given point P=(x,y) the y coordinate can be derived from x by solving the corresponding elliptic curve equation. There are two possible y coordinates for any x of a given P The either of the two possibilities for y is encoded in some way in the compressed representation There are a few undesirable properties of the above representation: The requirement to store one bit to identify the 'y' means that the whole byte is required. For most well-known elliptic curves the extra byte removes the power of two alignment for the encoded point. The requirement for the balanced security calls for the ECC curve size to be equal the hash output size, yet the storage length of the ECC point is equal to the hash output size + 1. The encoded point is not a multi-precision integer, but a structured sequence of bytes. For example, special wording is required to define the encoding of the P-521 to clarify how odd number of bits for x and y, or a bit representing y, are packed into bytes. Some protocols, such as ECDH, don't depend on the exact value of the y. It is unnecessary to track the precise point P=(x,y) in such protocols.

This document is an improvement to the idea by to not transmit the y coordinate of an ECC point in the elliptic curve Diffie-Hellman (ECDH) protocol. We will use the following notations for the ECC point Q and the features of the corresponding elliptic curve: Q = k*G, where Q = (x,y) is the point on an elliptic curve (the canonical represenation) k - the private key (a scalar) G - the elliptic curve generator point y^2 = C(x) is the appropriate Weierstrass equation linking x and y; for example, C(x) = x^3 + a*x + b is used for the short Weierstrass form p - the order of the underlying finite field to which x and y belong Ord - the order of the elliptic curve field, i.e. the number of points on the curve ( Ord*G = O, where O is the identity element ) This document specify how Q is represented in the compact form. The integer operations considered in this document are performed modulo prime p and "(mod p)" is assumed in every formula with x and y. Every elliptic curve for prime p (more generally, for any underlying field that doesn't have characteristic 2) can be represented as y^2 = C(x) with appropriate substitution, where C(x) is degree-3 polynomial in x. The steps to create and interpret the compact representation of a point are described next. A special key generation algorithm is needed to make them possible, defined later in .

Given the canonical representation of Q=(x,y), return the x as its compact representation. Given the compact representation of Q, return canonical representation of Q=(x,y) as follows: y' = sqrt( C(x) ), where y'>0 y = min(y',p-y') Q=(x,y) is the canonical representation of the point Recall that the x is an element in the underlying finite field, represented by an integer. Its precise encoding SHOULD be consistent with encoding of other multi-precision integers in the application, for example, it would be the same encoding as used for the r or s integer that is a part of the DSA signature and it is typically a sequence of big-endian bytes. The efficient algorithm to recover y for or the Brainpool curves , among others, is given in . min(y,p-y) can be calculated with the help of the pre-calculated value p2=(p-1)/2. min(y,p-y) is y if y<=p2 and p-y otherwise. The efficient encoding and decoding algorithms are possible with the special key generation algorithm, defined next.

This document specifies two algorithms, called the "black box" and the "deterministic" key generation algorithms, to generate a key pair {k, Q=k*G=(x,y)}, where k is the private key and Q=(x,y) is the public key. A key pair generated according to the requirements in this section is called a compliant key pair, and the public key of such a key pair -- a compliant public key. A compliant public key Q=(x,y) allows compact representation as x, as defined in . Both key generation algorithms can be built with any general purpose key generation algorithm which would be needed in any ECC implementation that generates keys, regardless of the support for any method defined in this document. Such a general purpose key generation algorithm is referred in this section as "KG". The black box algorithm works in scenarios when the KG doesn't allow any adjustments to the private key. The disadvantage of this algorithm is that multiple KGs may be needed to generate a single key pair {k, Q}. The deterministic algorithm is similar, except that it is allowed to perform a simple and fast modification to the private key after the KG. The advantage of the second algorithm is performance, in particular, the guarantee that only a single KG is needed.

The following algorithm calculates a key pair {k, Q=k*G=(x,y)}, where k is the private key and Q=(x,y) is the public key. Generate a key pair {k, Q=k*G=(x,y)} with KG if( y != min(y,p-y) ) goto step 1 output {k, Q=(x,y)} as a key pair Note that the step 1 is a general purpose key generation algorithm, such as an algorithm compliant with . Step 1 assumes neither changes to existing key generation methods nor access to the private key in clear. The expected number of iterations in the loop in the above algorithm is 2. The step 2 is not needed for the ECDH keys.

The following algorithm calculates a key pair {k, Q=k*G=(x,y)}, where k is the private key and Q=(x,y) is the public key. Generate a key pair {k, Q=k*G=(x,y)} with KG if( y != min(y,p-y) ) k = Ord - k; y = p - y output {k, Q=(x,y)} as a key pair The step 2 is not needed for the ECDH keys.

In some protocols a participant must produce a point Q, such that Q = S + P. Q is to be shared with other participants. In this equation S is some known point and P is a point for the key pair {k, P=k*G=(x1,y1)} that the participant generates internally, but never makes available to other participants of the protocol. The Q must be compliant, while there is no such requirement for P. The following algorithm is a generalization of the previous two algorithms to produce a compliant Q. It's easy to observe that the black box algorithm in section is easily adopted to this case. All that's needed is to continue to generate a new P so that the Q (not P) is compliant. A more efficient version of this algorithm that only requires one KG is described next. This algorithm expects that the participant generates a delta key pair {d, D=d*G} and caches it for a certain period of time to ammortize the cost of generation of {d, D}. For example, {d, D} might be generated once during the process start-up and is kept in memory until the process is terminated. This allows the same {d, D} to be used with many protocol runs. In this case the formula is Q = S + (P + t*D), which means that the P is adjusted with t additions of D until the point Q is a compliant point. The expected value of t is 1. Obtain the point S Generate a delta key pair {d, D=d*G} with KG; save it so it can be used in subsequent protocol runs Generate an internal key pair {k, P=k*G=(x1,y1)} with KG Calculate Q=(x,y)=P+S Until ( y == min(y,p-y) ) do {Q += D; k += d;} Output {k, P}, Q=(x,y), where Q is a compliant point and {k, P} is a corresponding to Q internal key pair

In some protocols a participant must produce a point Q, such that Q = k1*k2*...*kn*P. Q is to be shared with other participants. In this equation P is a point for the key pair {k, P=k*G} that the participant generates internally, but never makes available to other participants of the protocol. The Q must be compliant, while there is no such requirement for P. It's easy to observe that the black box algorithm in section is easily adopted to this case. All that's needed is to continue to generate a new P so that the Q (not P) is compliant. However, there is a deterministic algorithm with a single KG, based on the algorithm in section . Q can be rewritten as Q = k1*k2*...*kn*k*G = k*(k1*k2*...*kn)G = k * S. The algorithm in section is used as is, except the G is replaced with S, so that Q=k*G is interpreted as Q=k*S.

When p mod 4 = 3, as is the case of and the Brainpool curves , there is an efficient square root algorithm to recover the y, as follows: Given the compact representation of Q as x, y2 = C(x) y' = y2^((p+1)/4) y = min(y',p-y') Q=(x,y) is the canonical representation of the point See for details.

The method described in this document should work for any elliptic curve over the prime fields provided that the canonical repsentation of the point is in affine coordinates. For the given x there are two solutions to the equation y^2 = C(x); the method described here selects the smallest y; this corresponds to the private keys k or Ord-k. The extension of the method described above is straightforward. Note that the fundamental technique described above relies on the relationship between {k,Ord-k} and {Q, -Q}. -Q refers to the explicit affine negation formula. The transition between Q, -Q and k, Ord-k is exceptionally fast. In general, the appropriate affine point negation formula changes the coordinate that we will omit in the compact representation (this is typically the y coordinate). The code that recovers the omitted coordinate assumes that it is the smallest possible coordinate y, such that y^2 = C(x). This assumption is assured by the selection of the corresponding {k, Ord-k}. This will be clear from the following examples. Many definitions of elliptic curve are known and the list may keep keep growing. specifies the affine point negation formula for various curves. Here are a few possibilities for -Q, where Q = (x,y): Formula Method Synopsis (x,-y) Use step-by-step instructions in this specification y=min(y,p-y) (-x,y) Edwards curves. Given that the curve definition is symmetric for x and y, rename x and y in the description of the above methods x=min(x,p-x); y is compact representation (y,x) This specification, except change the formula for negation to "exchange x with y" y = min(x,y) (x/y,1/y) This specification, except change the formula for negation to use division by y y = min(y,1/y), x=x/y

The compact representation described in this document allows two-phase introduction. First, key pairs must be generated as defined in to allow compact representation. No accompanied changes are needed elsewhere to use these keys. This allows safe deployment of the new key generation, which, in turn, allows encoding and decoding of compact representation, possibly at a later time. Finally, the encoding of public keys in the new compact representation format can be enabled after there is confidence in the universal support of new compact representation. This event would not need to change any private key material, only public key representation. The above two phases can be implemented at once for new formats. Most ECC cryptographic protocols, such as ECDSA , are intended to work with persistently stored public keys that are generated as fresh key pairs, as opposed to some derivation function that transforms an ECC point. The algorithm described in is possible in all these cases. Furthermore, a typical instantiation of the ECDH protocol, such as ECDH specified in , makes any ECC key used in a DH key key agreement automatically compliant for the purpose of this specification ( as noted in the ). The algorithm in will even work for secure devices that never reveal the private key, such as smartcards or Hardware Security Modules. A public key that is generated according to the can be used without limitations in existing protocols that use ECC points encoded in other ways, such as , with compression or not, with the added advantage that the keys generated according to the method in will allow the encoding.

The methods described in this document eliminates one bit that is tranditionally needed to identify either of the two y coordinates. is the earliest reference about such an approach to compact representation in the prime underlying finite field that the author is aware of, viewed in that work in the context of the format preserving encryption.

This document defines a low-level format that may be suitable for a wide range of applications. However, it is responsibility of the application that adopts this format to define the IDs that will enable the ECC compact point representation in that application. A new ID may not be always necessary. For example, an application that currently allows the encoding may allow the compact representation defined in this document as an extension to the as follows. Consider the encoding of a compressed P-256 point, for example. The compressed representation of a P-256 point will always occupy exactly 33 bytes. On the other hand, the compact representation defined in this document will never exceed 32 bytes (it may occupy fewer that 32 bytes when the most significant byte has happened to be zero). This size will allow reliable discrimination between two encoding formats.

The key pair generation process in excludes exactly half of the points on the elliptic curve. What is left is the subset of points suitable for compact representation. The filtering of points is based on a public criteria that are applied to the public output of the ECC one-way function. The set of Ord points on the elliptic curve can be subdivided as follows. First, remove the point O, which leaves Ord-1 points. Of these points there are exactly (Ord-1)/2 points that have unique x coordinate. This document specifies a method to form the (Ord-1)/2 of points, each having a unique x coordinate. These points are called compliant public keys in . For any two public keys P=(x,y) and P=(x,y') there is up to one bit of entropy in y' v.s. y and this information is public. This bit of entropy doesn't contribute to the difficulty of the underlying hard problem of the ECC: the elliptic curve discrete logarithm problem (ECDLP). It will be shown next that breaking the ECDLP with a key generated according to is not easier than breaking the ECDLP with a key obtained through a standard key generation algorithm, referred to as the KG algorithm in the . Let us assume that there is an algorithm A that solves the ECDLP for the KG. The algorithm A can be transformed into the algorithm A' as follows. If P=(x,y) is a compliant public key, the ECDLP is solved with A for the point (x,y): the result is k, such that k*G=(x,y) If P=(x,y) is not a compliant public key, the ECDLP is solved with A for the point (x,p-y); assuming the output produced by A is k, the output produced by A' is set to (Ord-k). Note that (Ord-k)*G = (x,y), which means that the output of A' is the correct solution. A' is equivalent to A. The complexity of one additional substraction in the prime field is negligible even to the complexity of a single elliptic curve addition. Observe that A' works for all public keys by performing the actual work only on compliant public keys. If we now consider only the compliant public keys, which cuts the number of points in half, we observe that the ECDLP solving algorithm A' doesn't get to break fewer public keys. This concludes the proof. The same result can be observed based on the details of the current state of the art attacks on the ECDLP. These attacks use Pollard's rho algorithm, which uses the collision search in the sequence(s) of generated points with the goal to produce the points P1=(x1,y1) and P2=(x2,y2), such that x1=x2 and y1=y2. The match in the x coordinate is the sufficient event for the successful attack. After this event has occurred, the sequence(s) that led to x1=x2 collision can be adjusted in a constant number of steps to ensure that y1=y2, if this is not already the case. Furthermore, collision search requires the storage of candidates for the collision. It's wasteful to store (x,y) v.s. storing x and only calculating y when the collision in x is detected. Thus, the ECDLP attack does not benefit from the unpredictability of the y. Finally, note that a common design feature of an ECDH-based system is not to depend on the y coordinate, such as the one defined in the . Thus, the security of the system is unaffected if we fix either of the two possibilities for the point with the given x coordinate.

&RFC2119; &RFC5639; &RFC6090; Springer-Verlag New York, Inc. The Mathematical Association of America (Incorporated) National Security Agency National Institute of Standards and Technology STANDARDS FOR EFFICIENT CRYPTOGRAPHY National Institute of Standards and Technology National Institute of Standards and Technology OpenSSL bug reporting system

The complete changes that were needed to make libgcrypt library generate a compliant key are shown inline in this section, followed by pending changes to OpenSSL.

In the following changes, the Q is the initial public key, G generator, and d is the corresponding private key. "-" prefix marks the two lines that were replaced with the lines starting with "+". Lines starting with "+" represent the code that adds compliant key generation to libgcrypt.

E.G, &E.G); sk->E.n = mpi_copy (E.n); point_init (&sk->Q); - point_set (&sk->Q, &Q); - sk->d = mpi_copy (d); + + /* We want the Q=(x,y) be a "compliant key" in terms of the + * http://tools.ietf.org/html/draft-jivsov-ecc-compact, + * which simply means that we choose either Q=(x,y) or -Q=(x,p-y) + * such that we end up with the min(y,p-y) as the y coordinate. + * Such a public key allows the most efficient compression: y can + * simply be dropped because we know that it's a minimum of + * the two possibilities without any loss of security. + */ + { + gcry_mpi_t x, p_y, y; + const unsigned int nbits = mpi_get_nbits (E.p); + + x = mpi_new (nbits); + p_y = mpi_new (nbits); + y = mpi_new (nbits); + + if (_gcry_mpi_ec_get_affine (x, y, &Q, ctx)) + log_fatal ("ecgen: Failed to get affine coordinates for Q\n"); + + mpi_sub( p_y, E.p, y ); /* p_y = p-y */ + + if( mpi_cmp( p_y /*p-y*/, y ) < 0 ) { /* is p-y < p ? */ + gcry_mpi_t z = mpi_copy( mpi_const (MPI_C_ONE) ); + /* we need to end up with -Q; this assures that new Q's y + * is the smallest one */ + sk->d = mpi_new (nbits); + mpi_sub( sk->d, E.n, d ); /* d = order-d */ + /* log_mpidump ("ecgen d after ", sk->d); */ + gcry_mpi_point_set (&sk->Q, x, p_y/*p-y*/, z); /* Q = -Q */ + if (DBG_CIPHER) + { + log_debug ("ecgen converted Q to a compliant point\n"); + } + mpi_free (z); + } + else + { + /* no change is needed exactly 50% of the time: just copy */ + sk->d = mpi_copy (d); + point_set (&sk->Q, &Q); + if (DBG_CIPHER) + { + log_debug ("ecgen didn't need to convert Q to " + "a compliant point\n"); + } + } + mpi_free (x); + mpi_free (p_y); + mpi_free (y); + } ]]>

OpenSSL changes are even more compact than in . They are tracked at .