idnits 2.17.1 draft-jivsov-ecc-compact-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 392 has weird spacing: '... rename y is ...' -- The document date (March 15, 2014) is 3694 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Workign Group A. Jivsov 3 Internet-Draft Symantec Corporation 4 Intended status: Informational March 15, 2014 5 Expires: September 16, 2014 7 Compact representation of an elliptic curve point 8 draft-jivsov-ecc-compact-05 10 Abstract 12 This document defines a format for efficient storage representation 13 of an elliptic curve point over prime fields, suitable for use with 14 any IETF format or protocol. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 16, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions used in this document . . . . . . . . . . . . . . 3 52 3. Overview of the compact representation in IETF protocols . . . 3 53 4. The definition of the compact representation . . . . . . . . . 4 54 4.1. Encoding and decoding of an elliptic curve point . . . . . 5 55 4.2. The algorithms to generate a key pair . . . . . . . . . . 6 56 4.2.1. The black box key generation algorithm . . . . . . . . 6 57 4.2.2. The deterministic key generation algorithm . . . . . . 7 58 4.2.3. The key generation algorithm for the sum of points . . 7 59 4.2.4. The key generation algorithm for the multiples . . . . 8 60 4.3. The efficient square root algorithm for p=4*k+3 . . . . . 8 61 4.4. General applicability . . . . . . . . . . . . . . . . . . 9 62 5. Interoperability considerations . . . . . . . . . . . . . . . 10 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 69 Appendix A. Sample code change to add compliant key 70 generation to libgcrypt and openssl . . . . . . . . . 14 71 A.1. libgcrypt changes . . . . . . . . . . . . . . . . . . . . 14 72 A.2. OpenSSL changes . . . . . . . . . . . . . . . . . . . . . 15 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 The National Security Agency (NSA) of the United States specifies 78 elliptic curve cryptography (ECC) for use in its [SuiteB] set of 79 algorithms. The NIST elliptic curves over the prime fields 80 [FIPS-186], which include [SuiteB] curves, or the Brainpool curves 81 [RFC5639] are the examples of curves over prime fields. 83 This document provides an efficient format for compact representation 84 of a point on an elliptic curve over a prime field. It is intended 85 as an open format that other IETF protocols can rely on to minimize 86 space required to store an ECC point. This document complements the 87 [RFC6090] with the on-the-wire definition of an ECC point. The 88 method described here can be applied to a various types of elliptic 89 curves, see Section 4.4. 91 One of the benefits of the ECC is the small size of field elements. 92 The compact representation reduces the encoded size of an ECC element 93 in half, which can be a substantial saving in cases such as 94 encryption of a short message sent to multiple recipients. 96 2. Conventions used in this document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Overview of the compact representation in IETF protocols 104 IETF protocols often use the [SEC1] representation of a point on an 105 elliptic curve, which is a sequence of the following fields: 107 Field Description 108 ------ -------------------------------------------------------------- 109 B0 {02, 03, 04}, where 02 or 03 represent a compressed point (x 110 only), while 04 represents a complete point (x,y) 111 X x coordinate of a point 112 Y y coordinate of a point, optional (present only for B0=04) 114 SEC1 point representation 116 The [SEC1] is an example of a general-purpose elliptic curve point 117 compression. The idea behind these methods is the following: 119 o For the given point P=(x,y) the y coordinate can be derived from x 120 by solving the corresponding elliptic curve equation. 122 o There are two possible y coordinates for any x of a given P 124 o The either of the two possibilities for y is encoded in some way 125 in the compressed representation 127 There are a few undesirable properties of the above representation: 129 o The requirement to store one bit to identify the 'y' means that 130 the whole byte is required. 132 o For most well-known elliptic curves the extra byte removes the 133 power of two alignment for the encoded point. 135 o The requirement for the balanced security calls for the ECC curve 136 size to be equal the hash output size, yet the storage length of 137 the ECC point is equal to the hash output size + 1. 139 o The encoded point is not a multi-precision integer, but a 140 structured sequence of bytes. For example, special wording is 141 required to define the encoding of the [FIPS-186] P-521 to clarify 142 how odd number of bits for x and y, or a bit representing y, are 143 packed into bytes. 145 o Some protocols, such as ECDH, don't depend on the exact value of 146 the y. It is unnecessary to track the precise point P=(x,y) in 147 such protocols. 149 4. The definition of the compact representation 151 This document is an improvement to the idea by [Miller] to not 152 transmit the y coordinate of an ECC point in the elliptic curve 153 Diffie-Hellman (ECDH) protocol. 155 We will use the following notations for the ECC point Q and the 156 features of the corresponding elliptic curve: 158 Q = k*G, where 160 Q = (x,y) is the point on an elliptic curve (the canonical 161 represenation) 163 k - the private key (a scalar) 165 G - the elliptic curve generator point 167 y^2 = C(x) is the appropriate Weierstrass equation linking x and 168 y; for example, C(x) = x^3 + a*x + b is used for the short 169 Weierstrass form 171 p - the order of the underlying finite field to which x and y 172 belong 174 Ord - the order of the elliptic curve field, i.e. the number of 175 points on the curve ( Ord*G = O, where O is the identity element ) 177 This document specify how Q is represented in the compact form. The 178 integer operations considered in this document are performed modulo 179 prime p and "(mod p)" is assumed in every formula with x and y. 181 Every elliptic curve for prime p (more generally, for any underlying 182 field that doesn't have characteristic 2) can be represented as y^2 = 183 C(x) with appropriate substitution, where C(x) is degree-3 polynomial 184 in x. 186 The steps to create and interpret the compact representation of a 187 point are described next. A special key generation algorithm is 188 needed to make them possible, defined later in Section 4.2. 190 4.1. Encoding and decoding of an elliptic curve point 192 Encoding: Given the canonical representation of Q=(x,y), return the 193 x as its compact representation. 195 Decoding: Given the compact representation of Q, return canonical 196 representation of Q=(x,y) as follows: 198 1. y' = sqrt( C(x) ), where y'>0 200 2. y = min(y',p-y') 202 3. Q=(x,y) is the canonical representation of the point 204 Recall that the x is an element in the underlying finite field, 205 represented by an integer. Its precise encoding SHOULD be consistent 206 with encoding of other multi-precision integers in the application, 207 for example, it would be the same encoding as used for the r or s 208 integer that is a part of the DSA signature and it is typically a 209 sequence of big-endian bytes. 211 The efficient algorithm to recover y for [SuiteB] or the Brainpool 212 curves [RFC5639], among others, is given in Section 4.3. 214 min(y,p-y) can be calculated with the help of the pre-calculated 215 value p2=(p-1)/2. min(y,p-y) is y if y<=p2 and p-y otherwise. 217 The efficient encoding and decoding algorithms are possible with the 218 special key generation algorithm, defined next. 220 4.2. The algorithms to generate a key pair 222 This document specifies two algorithms, called the "black box" and 223 the "deterministic" key generation algorithms, to generate a key pair 224 {k, Q=k*G=(x,y)}, where k is the private key and Q=(x,y) is the 225 public key. A key pair generated according to the requirements in 226 this section is called a compliant key pair, and the public key of 227 such a key pair -- a compliant public key. A compliant public key 228 Q=(x,y) allows compact representation as x, as defined in 229 Section 4.1. 231 Both key generation algorithms can be built with any general purpose 232 key generation algorithm which would be needed in any ECC 233 implementation that generates keys, regardless of the support for any 234 method defined in this document. Such a general purpose key 235 generation algorithm is referred in this section as "KG". 237 The black box algorithm works in scenarios when the KG doesn't allow 238 any adjustments to the private key. The disadvantage of this 239 algorithm is that multiple KGs may be needed to generate a single key 240 pair {k, Q}. The deterministic algorithm is similar, except that it 241 is allowed to perform a simple and fast modification to the private 242 key after the KG. The advantage of the second algorithm is 243 performance, in particular, the guarantee that only a single KG is 244 needed. 246 4.2.1. The black box key generation algorithm 248 The following algorithm calculates a key pair {k, Q=k*G=(x,y)}, where 249 k is the private key and Q=(x,y) is the public key. 251 Black box generation: 253 1. Generate a key pair {k, Q=k*G=(x,y)} with KG 255 2. if( y != min(y,p-y) ) goto step 1 257 3. output {k, Q=(x,y)} as a key pair 259 Note that the step 1 is a general purpose key generation algorithm, 260 such as an algorithm compliant with [NIST-SP800-133]. Step 1 assumes 261 neither changes to existing key generation methods nor access to the 262 private key in clear. 264 The expected number of iterations in the loop in the above algorithm 265 is 2. The step 2 is not needed for the ECDH keys. 267 4.2.2. The deterministic key generation algorithm 269 The following algorithm calculates a key pair {k, Q=k*G=(x,y)}, where 270 k is the private key and Q=(x,y) is the public key. 272 Deterministic generation: 274 1. Generate a key pair {k, Q=k*G=(x,y)} with KG 276 2. if( y != min(y,p-y) ) k = Ord - k; y = p - y 278 3. output {k, Q=(x,y)} as a key pair 280 The step 2 is not needed for the ECDH keys. 282 4.2.3. The key generation algorithm for the sum of points 284 In some protocols a participant must produce a point Q, such that Q = 285 S + P. Q is to be shared with other participants. In this equation S 286 is some known point and P is a point for the key pair {k, 287 P=k*G=(x1,y1)} that the participant generates internally, but never 288 makes available to other participants of the protocol. The Q must be 289 compliant, while there is no such requirement for P. The following 290 algorithm is a generalization of the previous two algorithms to 291 produce a compliant Q. 293 It's easy to observe that the black box algorithm in section 294 Section 4.2.1 is easily adopted to this case. All that's needed is 295 to continue to generate a new P so that the Q (not P) is compliant. 297 A more efficient version of this algorithm that only requires one KG 298 is described next. This algorithm expects that the participant 299 generates a delta key pair {d, D=d*G} and caches it for a certain 300 period of time to ammortize the cost of generation of {d, D}. For 301 example, {d, D} might be generated once during the process start-up 302 and is kept in memory until the process is terminated. This allows 303 the same {d, D} to be used with many protocol runs. In this case the 304 formula is Q = S + (P + t*D), which means that the P is adjusted with 305 t additions of D until the point Q is a compliant point. The 306 expected value of t is 1. 308 Before the first protocol run: 310 1. Obtain the point S 311 2. Generate a delta key pair {d, D=d*G} with KG; save it so it 312 can be used in subsequent protocol runs 314 Generation: 316 1. Generate an internal key pair {k, P=k*G=(x1,y1)} with KG 318 2. Calculate Q=(x,y)=P+S 320 3. Until ( y == min(y,p-y) ) do {Q += D; k += d;} 322 4. Output {k, P}, Q=(x,y), where Q is a compliant point and 323 {k, P} is a corresponding to Q internal key pair 325 4.2.4. The key generation algorithm for the multiples 327 In some protocols a participant must produce a point Q, such that Q = 328 k1*k2*...*kn*P. Q is to be shared with other participants. In this 329 equation P is a point for the key pair {k, P=k*G} that the 330 participant generates internally, but never makes available to other 331 participants of the protocol. The Q must be compliant, while there 332 is no such requirement for P. 334 It's easy to observe that the black box algorithm in section 335 Section 4.2.1 is easily adopted to this case. All that's needed is 336 to continue to generate a new P so that the Q (not P) is compliant. 338 However, there is a deterministic algorithm with a single KG, based 339 on the algorithm in section Section 4.2.2. Q can be rewritten as Q = 340 k1*k2*...*kn*k*G = k*(k1*k2*...*kn)G = k * S. The algorithm in 341 section Section 4.2.2 is used as is, except the G is replaced with S, 342 so that Q=k*G is interpreted as Q=k*S. 344 4.3. The efficient square root algorithm for p=4*k+3 346 When p mod 4 = 3, as is the case of [SuiteB] and the Brainpool curves 347 [RFC5639], there is an efficient square root algorithm to recover the 348 y, as follows: 350 Given the compact representation of Q as x, 352 y2 = C(x) 354 y' = y2^((p+1)/4) 356 y = min(y',p-y') 357 Q=(x,y) is the canonical representation of the point 359 See [Lehmer] for details. 361 4.4. General applicability 363 The method described in this document should work for any elliptic 364 curve over the prime fields provided that the canonical repsentation 365 of the point is in affine coordinates. For the given x there are two 366 solutions to the equation y^2 = C(x); the method described here 367 selects the smallest y; this corresponds to the private keys k or 368 Ord-k. 370 The extension of the method described above is straightforward. Note 371 that the fundamental technique described above relies on the 372 relationship between {k,Ord-k} and {Q, -Q}. -Q refers to the explicit 373 affine negation formula. The transition between Q, -Q and k, Ord-k 374 is exceptionally fast. In general, the appropriate affine point 375 negation formula changes the coordinate that we will omit in the 376 compact representation (this is typically the y coordinate). The 377 code that recovers the omitted coordinate assumes that it is the 378 smallest possible coordinate y, such that y^2 = C(x). This 379 assumption is assured by the selection of the corresponding {k, 380 Ord-k}. This will be clear from the following examples. 382 Many definitions of elliptic curve are known and the list may keep 383 keep growing. [EFD] specifies the affine point negation formula for 384 various curves. Here are a few possibilities for -Q, where Q = 385 (x,y): 387 Formula Method Synopsis 388 --------- -------------------------------------------- -------------- 389 (x,-y) Use step-by-step instructions in this y=min(y,p-y) 390 specification 391 (-x,y) Edwards curves. Given that the curve x=min(x,p-x); 392 definition is symmetric for x and y, rename y is compact 393 x and y in the description of the above representation 394 methods 395 (y,x) This specification, except change the y = min(x,y) 396 formula for negation to "exchange x with y" 397 (x/y,1/y) This specification, except change the y = 398 formula for negation to use division by y min(y,1/y), 399 x=x/y 401 Affine negation methods 403 5. Interoperability considerations 405 The compact representation described in this document allows two- 406 phase introduction. 408 First, key pairs must be generated as defined in Section 4.2 to allow 409 compact representation. No accompanied changes are needed elsewhere 410 to use these keys. This allows safe deployment of the new key 411 generation, which, in turn, allows encoding and decoding of compact 412 representation, possibly at a later time. 414 Finally, the encoding of public keys in the new compact 415 representation format can be enabled after there is confidence in the 416 universal support of new compact representation. This event would 417 not need to change any private key material, only public key 418 representation. 420 The above two phases can be implemented at once for new formats. 422 Most ECC cryptographic protocols, such as ECDSA [FIPS-186], are 423 intended to work with persistently stored public keys that are 424 generated as fresh key pairs, as opposed to some derivation function 425 that transforms an ECC point. The algorithm described in Section 4.2 426 is possible in all these cases. Furthermore, a typical instantiation 427 of the ECDH protocol, such as ECDH specified in [NIST-SP800-56A], 428 makes any ECC key used in a DH key key agreement automatically 429 compliant for the purpose of this specification ( as noted in the 430 Section 4.2 ). The algorithm in Section 4.2 will even work for 431 secure devices that never reveal the private key, such as smartcards 432 or Hardware Security Modules. A public key that is generated 433 according to the Section 4.2 can be used without limitations in 434 existing protocols that use ECC points encoded in other ways, such as 435 [SEC1], with compression or not, with the added advantage that the 436 keys generated according to the method in Section 4.2 will allow the 437 Section 4.1 encoding. 439 6. Acknowledgements 441 The methods described in this document eliminates one bit that is 442 tranditionally needed to identify either of the two y coordinates. 443 [FPE] is the earliest reference about such an approach to compact 444 representation in the prime underlying finite field that the author 445 is aware of, viewed in that work in the context of the format 446 preserving encryption. 448 7. IANA Considerations 450 This document defines a low-level format that may be suitable for a 451 wide range of applications. However, it is responsibility of the 452 application that adopts this format to define the IDs that will 453 enable the ECC compact point representation in that application. 455 A new ID may not be always necessary. For example, an application 456 that currently allows the [SEC1] encoding may allow the compact 457 representation defined in this document as an extension to the [SEC1] 458 as follows. Consider the encoding of a compressed [FIPS-186] P-256 459 point, for example. The [SEC1] compressed representation of a P-256 460 point will always occupy exactly 33 bytes. On the other hand, the 461 compact representation defined in this document will never exceed 32 462 bytes (it may occupy fewer that 32 bytes when the most significant 463 byte has happened to be zero). This size will allow reliable 464 discrimination between two encoding formats. 466 8. Security Considerations 468 The key pair generation process in Section 4.2 excludes exactly half 469 of the points on the elliptic curve. What is left is the subset of 470 points suitable for compact representation. The filtering of points 471 is based on a public criteria that are applied to the public output 472 of the ECC one-way function. 474 The set of Ord points on the elliptic curve can be subdivided as 475 follows. First, remove the point O, which leaves Ord-1 points. Of 476 these points there are exactly (Ord-1)/2 points that have unique x 477 coordinate. This document specifies a method to form the (Ord-1)/2 478 of points, each having a unique x coordinate. These points are 479 called compliant public keys in Section 4.2. 481 For any two public keys P=(x,y) and P=(x,y') there is up to one bit 482 of entropy in y' v.s. y and this information is public. This bit of 483 entropy doesn't contribute to the difficulty of the underlying hard 484 problem of the ECC: the elliptic curve discrete logarithm problem 485 (ECDLP). 487 It will be shown next that breaking the ECDLP with a key generated 488 according to Section 4.2 is not easier than breaking the ECDLP with a 489 key obtained through a standard key generation algorithm, referred to 490 as the KG algorithm in the Section 4.2. 492 Let us assume that there is an algorithm A that solves the ECDLP for 493 the KG. The algorithm A can be transformed into the algorithm A' as 494 follows. 496 o If P=(x,y) is a compliant public key, the ECDLP is solved with A 497 for the point (x,y): the result is k, such that k*G=(x,y) 499 o If P=(x,y) is not a compliant public key, the ECDLP is solved with 500 A for the point (x,p-y); assuming the output produced by A is k, 501 the output produced by A' is set to (Ord-k). Note that (Ord-k)*G 502 = (x,y), which means that the output of A' is the correct 503 solution. 505 A' is equivalent to A. The complexity of one additional substraction 506 in the prime field is negligible even to the complexity of a single 507 elliptic curve addition. Observe that A' works for all public keys 508 by performing the actual work only on compliant public keys. 510 If we now consider only the compliant public keys, which cuts the 511 number of points in half, we observe that the ECDLP solving algorithm 512 A' doesn't get to break fewer public keys. This concludes the proof. 514 The same result can be observed based on the details of the current 515 state of the art attacks on the ECDLP. These attacks use Pollard's 516 rho algorithm, which uses the collision search in the sequence(s) of 517 generated points with the goal to produce the points P1=(x1,y1) and 518 P2=(x2,y2), such that x1=x2 and y1=y2. The match in the x coordinate 519 is the sufficient event for the successful attack. After this event 520 has occurred, the sequence(s) that led to x1=x2 collision can be 521 adjusted in a constant number of steps to ensure that y1=y2, if this 522 is not already the case. Furthermore, collision search requires the 523 storage of candidates for the collision. It's wasteful to store 524 (x,y) v.s. storing x and only calculating y when the collision in x 525 is detected. Thus, the ECDLP attack does not benefit from the 526 unpredictability of the y. 528 Finally, note that a common design feature of an ECDH-based system is 529 not to depend on the y coordinate, such as the one defined in the 530 [NIST-SP800-56A]. Thus, the security of the system is unaffected if 531 we fix either of the two possibilities for the point with the given x 532 coordinate. 534 9. References 536 9.1. Normative References 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, March 1997. 541 9.2. Informative References 543 [EFD] Bernstein, D. and T. Lange, "Genus-1 curves over large- 544 characteristic fields", 2014, 545 . 547 [FIPS-186] 548 National Institute of Standards and Technology, "Digital 549 Signature Standard (DSS)", FIPS 186-3, June 2009, 550 . 552 [FPE] Rogaway, P. and J. Black, "Ciphers with arbitrary finite 553 domains.", Proceedings Topics in Cryptology CT-RSA. 554 Springer Berlin Heidelberg, 2002, 555 . 557 [Lehmer] Lehmer, D., "Computer technology applied to the theory of 558 numbers", 1969. 560 [Miller] Miller, V., "Use of elliptic curves in cryptography", 561 Proceedings Lecture notes in computer sciences; 218 on 562 Advances in cryptology -- CRYPTO 85, June 1986. 564 [NIST-SP800-133] 565 National Institute of Standards and Technology, 566 "Recommendation for Cryptographic Key Generation", SP 800- 567 133, November 2012, 568 . 570 [NIST-SP800-56A] 571 National Institute of Standards and Technology, 572 "Recommendation for Pair-Wise Key Establishment Schemes 573 Using Discrete Logarithm Cryptography", SP 800-56A 574 Revision 1, March 2007, 575 . 577 [OpenSSL] Jivsov, A., "An enhancement to EC key generation to enable 578 compact point representation", June 2013, 579 . 581 [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography 582 (ECC) Brainpool Standard Curves and Curve Generation", 583 RFC 5639, March 2010. 585 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 586 Curve Cryptography Algorithms", RFC 6090, February 2011. 588 [SEC1] STANDARDS FOR EFFICIENT CRYPTOGRAPHY, "SEC 1: Elliptic 589 Curve Cryptography", September 2000, . 592 [SuiteB] National Security Agency, "NSA Suite B Cryptography", 593 March 2010, 594 . 596 Appendix A. Sample code change to add compliant key generation to 597 libgcrypt and openssl 599 The complete changes that were needed to make libgcrypt library 600 generate a compliant key are shown inline in this section, followed 601 by pending changes to OpenSSL. 603 A.1. libgcrypt changes 605 In the following changes, the Q is the initial public key, G 606 generator, and d is the corresponding private key. "-" prefix marks 607 the two lines that were replaced with the lines starting with "+". 608 Lines starting with "+" represent the code that adds compliant key 609 generation to libgcrypt. 611 @@ generate_key (ECC_secret_key *sk, 612 unsigned int nbits, 613 const char *name, 614 point_set (&sk->E.G, &E.G); 615 sk->E.n = mpi_copy (E.n); 616 point_init (&sk->Q); 617 - point_set (&sk->Q, &Q); 618 - sk->d = mpi_copy (d); 619 + 620 + /* We want the Q=(x,y) be a "compliant key" in terms of the 621 + * http://tools.ietf.org/html/draft-jivsov-ecc-compact, 622 + * which simply means that we choose either Q=(x,y) or -Q=(x,p-y) 623 + * such that we end up with the min(y,p-y) as the y coordinate. 624 + * Such a public key allows the most efficient compression: y can 625 + * simply be dropped because we know that it's a minimum of 626 + * the two possibilities without any loss of security. 627 + */ 628 + { 629 + gcry_mpi_t x, p_y, y; 630 + const unsigned int nbits = mpi_get_nbits (E.p); 631 + 632 + x = mpi_new (nbits); 633 + p_y = mpi_new (nbits); 634 + y = mpi_new (nbits); 635 + 636 + if (_gcry_mpi_ec_get_affine (x, y, &Q, ctx)) 637 + log_fatal ("ecgen: Failed to get affine coordinates for Q\n"); 638 + 639 + mpi_sub( p_y, E.p, y ); /* p_y = p-y */ 640 + 641 + if( mpi_cmp( p_y /*p-y*/, y ) < 0 ) { /* is p-y < p ? */ 642 + gcry_mpi_t z = mpi_copy( mpi_const (MPI_C_ONE) ); 643 + /* we need to end up with -Q; this assures that new Q's y 644 + * is the smallest one */ 645 + sk->d = mpi_new (nbits); 646 + mpi_sub( sk->d, E.n, d ); /* d = order-d */ 647 + /* log_mpidump ("ecgen d after ", sk->d); */ 648 + gcry_mpi_point_set (&sk->Q, x, p_y/*p-y*/, z); /* Q = -Q */ 649 + if (DBG_CIPHER) 650 + { 651 + log_debug ("ecgen converted Q to a compliant point\n"); 652 + } 653 + mpi_free (z); 654 + } 655 + else 656 + { 657 + /* no change is needed exactly 50% of the time: just copy */ 658 + sk->d = mpi_copy (d); 659 + point_set (&sk->Q, &Q); 660 + if (DBG_CIPHER) 661 + { 662 + log_debug ("ecgen didn't need to convert Q to " 663 + "a compliant point\n"); 664 + } 665 + } 666 + mpi_free (x); 667 + mpi_free (p_y); 668 + mpi_free (y); 669 + } 671 A.2. OpenSSL changes 673 OpenSSL changes are even more compact than in Appendix A.1. They are 674 tracked at [OpenSSL]. 676 Author's Address 678 Andrey Jivsov 679 Symantec Corporation 681 Email: crypto@brainhub.org