Network Workign Group A. Jivsov
Internet-Draft Symantec Corporation
Intended status: Informational May 31, 2013
Expires: December 2, 2013
Compact representation of an elliptic curve point
draft-jivsov-ecc-compact-01
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 2, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jivsov Expires December 2, 2013 [Page 1]
Internet-Draft Compact representation of an EC point May 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Overview of the compact representation in IETF protocols . . . 3
4. The definition of the compact representation . . . . . . . . . 4
4.1. Encoding and decoding of an elliptic curve point . . . . . 5
4.2. The algorithms to generate a key pair . . . . . . . . . . 5
4.2.1. The black box key generation algorithm . . . . . . . . 6
4.2.2. The deterministic key generation algorithm . . . . . . 6
4.3. The efficient square root algorithm for p=4*k+3 . . . . . 7
5. Interoperability considerations . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Sample code change to add compliant key
generation to libgcrypt . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Jivsov Expires December 2, 2013 [Page 2]
Internet-Draft Compact representation of an EC point May 2013
1. Introduction
The National Security Agency (NSA) of the United States specifies
elliptic curve cryptography (ECC) for use in its [SuiteB] set of
algorithms. The NIST elliptic curves over the prime fields
[FIPS-186], which include [SuiteB] curves, or the Brainpool curves
[RFC5639] 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
[RFC6090] with the on-the-wire definition of an ECC point.
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.
2. Conventions used in this document
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 [RFC2119].
3. Overview of the compact representation in IETF protocols
IETF protocols often use the [SEC1] 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)
SEC1 point representation
The [SEC1] is an example of a general-purpose elliptic curve point
compression. The idea behind these methods is the following:
o For the given point P=(x,y) the y coordinate can be derived from x
by solving the corresponding equation of the ECC.
Jivsov Expires December 2, 2013 [Page 3]
Internet-Draft Compact representation of an EC point May 2013
o There are two possible y coordinates for any x of a given P
o 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:
o The requirement to store one bit to identify the 'y' means that
the whole byte is required.
o For most well-known elliptic curves the extra byte removes the
power of two alignment for the encoded point.
o 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.
o 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 [FIPS-186] P-521 to clarify
how odd number of bits for x and y, or a bit representing y, are
packed into bytes.
o 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.
4. The definition of the compact representation
This document is an improvement to the idea by [Miller] 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 = x^3 + a*x + b is the standard Weierstrass equation linking x
and y
Jivsov Expires December 2, 2013 [Page 4]
Internet-Draft Compact representation of an EC point May 2013
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 )
Q is a point that we need to represent 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.
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 Section 4.2.
4.1. Encoding and decoding of an elliptic curve point
Encoding: Given the canonical representation of Q=(x,y), return the
x as the compact representation.
Decoding: Given the compact representation of Q, return canonical
representation of Q=(x,y) as follows:
1. y' = sqrt( x^3 + a*x + b ), where y'>0
2. y = min(y',p-y')
3. 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 [SuiteB] or the Brainpool
curves [RFC5639], among others, is given in Section 4.3.
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.
[Lehmer] Lehmer, D., "Computer technology applied to the theory of
numbers", 1969.
[Miller] Miller, V., "Use of elliptic curves in cryptography",
Proceedings Lecture notes in computer sciences; 218 on
Advances in cryptology -- CRYPTO 85, June 1986.
[NIST-SP800-133]
National Institute of Standards and Technology,
"Recommendation for Cryptographic Key Generation", SP 800-
133, November 2012,
.
[NIST-SP800-56A]
National Institute of Standards and Technology,
"Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", SP 800-56A
Revision 1, March 2007,
.
[RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
(ECC) Brainpool Standard Curves and Curve Generation",
RFC 5639, March 2010.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
Jivsov Expires December 2, 2013 [Page 10]
Internet-Draft Compact representation of an EC point May 2013
[SEC1] STANDARDS FOR EFFICIENT CRYPTOGRAPHY, "SEC 1: Elliptic
Curve Cryptography", September 2000, .
[SuiteB] National Security Agency, "NSA Suite B Cryptography",
March 2010,
.
Appendix A. Sample code change to add compliant key generation to
libgcrypt
This section shows complete changes that were needed to make
libgcrypt library generate a compliant key. Note that 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.
@@ generate_key (ECC_secret_key *sk,
unsigned int nbits,
const char *name,
point_set (&sk->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 */
Jivsov Expires December 2, 2013 [Page 11]
Internet-Draft Compact representation of an EC point May 2013
+
+ 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);
+ }
Author's Address
Andrey Jivsov
Symantec Corporation
Email: openpgp@brainhub.org
Jivsov Expires December 2, 2013 [Page 12]