idnits 2.17.1 draft-jivsov-ecc-compact-04.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 330 has weird spacing: '... rename y is ...' -- The document date (January 23, 2014) is 3746 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 January 23, 2014 5 Expires: July 27, 2014 7 Compact representation of an elliptic curve point 8 draft-jivsov-ecc-compact-04 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 July 27, 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.3. The efficient square root algorithm for p=4*k+3 . . . . . 7 59 4.4. General applicability . . . . . . . . . . . . . . . . . . 7 60 5. Interoperability considerations . . . . . . . . . . . . . . . 8 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 67 Appendix A. Sample code change to add compliant key 68 generation to libgcrypt and openssl . . . . . . . . . 12 69 A.1. libgcrypt changes . . . . . . . . . . . . . . . . . . . . 12 70 A.2. OpenSSL changes . . . . . . . . . . . . . . . . . . . . . 14 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 The National Security Agency (NSA) of the United States specifies 76 elliptic curve cryptography (ECC) for use in its [SuiteB] set of 77 algorithms. The NIST elliptic curves over the prime fields 78 [FIPS-186], which include [SuiteB] curves, or the Brainpool curves 79 [RFC5639] are the examples of curves over prime fields. 81 This document provides an efficient format for compact representation 82 of a point on an elliptic curve over a prime field. It is intended 83 as an open format that other IETF protocols can rely on to minimize 84 space required to store an ECC point. This document complements the 85 [RFC6090] with the on-the-wire definition of an ECC point. The 86 method described here can be applied to a various types of elliptic 87 curves, see Section 4.4. 89 One of the benefits of the ECC is the small size of field elements. 90 The compact representation reduces the encoded size of an ECC element 91 in half, which can be a substantial saving in cases such as 92 encryption of a short message sent to multiple recipients. 94 2. Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 3. Overview of the compact representation in IETF protocols 102 IETF protocols often use the [SEC1] representation of a point on an 103 elliptic curve, which is a sequence of the following fields: 105 Field Description 106 ------ -------------------------------------------------------------- 107 B0 {02, 03, 04}, where 02 or 03 represent a compressed point (x 108 only), while 04 represents a complete point (x,y) 109 X x coordinate of a point 110 Y y coordinate of a point, optional (present only for B0=04) 112 SEC1 point representation 114 The [SEC1] is an example of a general-purpose elliptic curve point 115 compression. The idea behind these methods is the following: 117 o For the given point P=(x,y) the y coordinate can be derived from x 118 by solving the corresponding elliptic curve equation. 120 o There are two possible y coordinates for any x of a given P 122 o The either of the two possibilities for y is encoded in some way 123 in the compressed representation 125 There are a few undesirable properties of the above representation: 127 o The requirement to store one bit to identify the 'y' means that 128 the whole byte is required. 130 o For most well-known elliptic curves the extra byte removes the 131 power of two alignment for the encoded point. 133 o The requirement for the balanced security calls for the ECC curve 134 size to be equal the hash output size, yet the storage length of 135 the ECC point is equal to the hash output size + 1. 137 o The encoded point is not a multi-precision integer, but a 138 structured sequence of bytes. For example, special wording is 139 required to define the encoding of the [FIPS-186] P-521 to clarify 140 how odd number of bits for x and y, or a bit representing y, are 141 packed into bytes. 143 o Some protocols, such as ECDH, don't depend on the exact value of 144 the y. It is unnecessary to track the precise point P=(x,y) in 145 such protocols. 147 4. The definition of the compact representation 149 This document is an improvement to the idea by [Miller] to not 150 transmit the y coordinate of an ECC point in the elliptic curve 151 Diffie-Hellman (ECDH) protocol. 153 We will use the following notations for the ECC point Q and the 154 features of the corresponding elliptic curve: 156 Q = k*G, where 158 Q = (x,y) is the point on an elliptic curve (the canonical 159 represenation) 161 k - the private key (a scalar) 163 G - the elliptic curve generator point 165 y^2 = C(x) is the appropriate Weierstrass equation linking x and 166 y; for example, C(x) = x^3 + a*x + b is used for the short 167 Weierstrass form 169 p - the order of the underlying finite field to which x and y 170 belong 172 Ord - the order of the elliptic curve field, i.e. the number of 173 points on the curve ( Ord*G = O, where O is the identity element ) 175 This document specify how Q is representated in the compact form. 176 The integer operations considered in this document are performed 177 modulo prime p and "(mod p)" is assumed in every formula with x and 178 y. 180 Every elliptic curve for prime p (more generally, for any underlying 181 field that doesn't have characteristic 2) can be represented as y^2 = 182 C(x) with appropriate substitution, where C(x) is degree-3 polynomial 183 in x. 185 The steps to create and interpret the compact representation of a 186 point are described next. A special key generation algorithm is 187 needed to make them possible, defined later in Section 4.2. 189 4.1. Encoding and decoding of an elliptic curve point 191 Encoding: Given the canonical representation of Q=(x,y), return the 192 x as its compact representation. 194 Decoding: Given the compact representation of Q, return canonical 195 representation of Q=(x,y) as follows: 197 1. y' = sqrt( C(x) ), where y'>0 199 2. y = min(y',p-y') 201 3. Q=(x,y) is the canonical representation of the point 203 Recall that the x is an element in the underlying finite field, 204 represented by an integer. Its precise encoding SHOULD be consistent 205 with encoding of other multi-precision integers in the application, 206 for example, it would be the same encoding as used for the r or s 207 integer that is a part of the DSA signature and it is typically a 208 sequence of big-endian bytes. 210 The efficient algorithm to recover y for [SuiteB] or the Brainpool 211 curves [RFC5639], among others, is given in Section 4.3. 213 min(y,p-y) can be calculated with the help of the pre-calculated 214 value p2=(p-1)/2. min(y,p-y) is y if y<=p2 and p-y otherwise. 216 The efficient encoding and decoding algorithms are possible with the 217 special key generation algorithm, defined next. 219 4.2. The algorithms to generate a key pair 221 This document specifies two algorithms, called the "black box" and 222 the "deterministic" key generation algorithms, to generate a key pair 223 {k, Q=k*G=(x,y)}, where k is the private key and Q=(x,y) is the 224 public key. A key pair generated according to the requirements in 225 this section is called a compliant key pair, and the public key of 226 such a key pair -- a compliant public key. A compliant public key 227 Q=(x,y) allows compact representation as x, as defined in 228 Section 4.1. 230 Both key generation algorithms can be built with any general purpose 231 key generation algorithm which would be needed in any ECC 232 implementation that generates keys, regardless of the support for any 233 method defined in this document. Such a general purpose key 234 generation algorithm is referred in this section as "KG". 236 The black box algorithm works in scenarios when the KG doesn't allow 237 any adjustments to the private key. The disadvantage of this 238 algorithm is that multiple KGs may be needed to generate a single key 239 pair {k, Q}. The deterministic algorithm is similar, except that it 240 is allowed to perform a simple and fast modification to the private 241 key after the KG. The advantage of the second algorithm is 242 performance, in particular, the guarantee that only a single KG is 243 needed. 245 4.2.1. The black box key generation algorithm 247 The following algorithm calculates a key pair {k, Q=k*G=(x,y)}, where 248 k is the private key and Q=(x,y) is the public key. 250 Black box generation: 252 1. Generate a key pair {k, Q=k*G=(x,y)} with KG 254 2. if( y != min(y,p-y) ) goto step 1 256 3. output {k, Q=(x,y)} as a key pair 258 Note that the step 1 is a general purpose key generation algorithm, 259 such as an algorithm compliant with [NIST-SP800-133]. Step 1 assumes 260 neither changes to existing key generation methods nor access to the 261 private key in clear. 263 The expected number of iterations in the loop in the above algorithm 264 is 2. The step 2 is not needed for the ECDH keys. 266 4.2.2. The deterministic key generation algorithm 268 The following algorithm calculates a key pair {k, Q=k*G=(x,y)}, where 269 k is the private key and Q=(x,y) is the public key. 271 Deterministic generation: 273 1. Generate a key pair {k, Q=k*G=(x,y)} with KG 275 2. if( y != min(y,p-y) ) k = Ord - k; y = p - y 277 3. output {k, Q=(x,y)} as a key pair 279 The step 2 is not needed for the ECDH keys. 281 4.3. The efficient square root algorithm for p=4*k+3 283 When p mod 4 = 3, as is the case of [SuiteB] and the Brainpool curves 284 [RFC5639], there is an efficient square root algorithm to recover the 285 y, as follows: 287 Given the compact representation of Q as x, 289 y2 = C(x) 291 y' = y2^((p+1)/4) 293 y = min(y',p-y') 295 Q=(x,y) is the canonical representation of the point 297 See [Lehmer] for details. 299 4.4. General applicability 301 The method described in this document should work for any elliptic 302 curve over the prime fields provided that the canonical repsentation 303 of the point is in affine coordinates. For the given x there are two 304 solutions to the equation y^2 = C(x); the method described here 305 selects the smallest y; this corresponds to the private keys k or 306 Ord-k. 308 The extension of the method described above is straightforward. Note 309 that the fundamental technique described above relies on the 310 relationship between {k,Ord-k} and {Q, -Q}. -Q refers to the explicit 311 affine negation formula. The transition between Q, -Q and k, Ord-k 312 is exceptionally fast. In general, the appropriate affine point 313 negation formula changes the coordinate that we will omit in the 314 compact representation (this is typically the y coordinate). The 315 code that recovers the omitted coordinate assumes that it is the 316 smallest possible coordinate y, such that y^2 = C(x). This 317 assumption is assured by the selection of the corresponding {k, 318 Ord-k}. This will be clear from the following examples. 320 Many definitions of elliptic curve are known and the list may keep 321 keep growing. [EFD] specifies the affine point negation formula for 322 various curves. Here are a few possibilities for -Q, where Q = 323 (x,y): 325 Formula Method Synopsis 326 --------- -------------------------------------------- -------------- 327 (x,-y) Use step-by-step instructions in this y=min(y,p-y) 328 specification 329 (-x,y) Edwards curves. Given that the curve x=min(x,p-x); 330 definition is symmetric for x and y, rename y is compact 331 x and y in the description of the above representation 332 methods 333 (y,x) This specification, except change the y = min(x,y) 334 formula for negation to "exchange x with y" 335 (x/y,1/y) This specification, except change the y = 336 formula for negation to use division by y min(y,1/y), 337 x=x/y 339 Affine negation methods 341 5. Interoperability considerations 343 The compact representation described in this document allows two- 344 phase introduction. 346 First, key pairs must be generated as defined in Section 4.2 to allow 347 compact representation. No accompanied changes are needed elsewhere 348 to use these keys. This allows safe deployment of the new key 349 generation, which, in turn, allows encoding and decoding of compact 350 representation, possibly at a later time. 352 Finally, the encoding of public keys in the new compact 353 representation format can be enabled after there is confidence in the 354 universal support of new compact representation. This event would 355 not need to change any private key material, only public key 356 representation. 358 The above two phases can be implemented at once for new formats. 360 Most ECC cryptographic protocols, such as ECDSA [FIPS-186], are 361 intended to work with persistently stored public keys that are 362 generated as fresh key pairs, as opposed to some derivation function 363 that transforms an ECC point. The algorithm described in Section 4.2 364 is possible in all these cases. Furthermore, a typical instantiation 365 of the ECDH protocol, such as ECDH specified in [NIST-SP800-56A], 366 makes any ECC key used in a DH key key agreement automatically 367 compliant for the purpose of this specification ( as noted in the 368 Section 4.2 ). The algorithm in Section 4.2 will even work for 369 secure devices that never reveal the private key, such as smartcards 370 or Hardware Security Modules. A public key that is generated 371 according to the Section 4.2 can be used without limitations in 372 existing protocols that use ECC points encoded in other ways, such as 373 [SEC1], with compression or not, with the added advantage that the 374 keys generated according to the method in Section 4.2 will allow the 375 Section 4.1 encoding. 377 6. Acknowledgements 379 The methods described in this document eliminates one bit that is 380 tranditionally needed to identify either of the two y coordinates. 381 [FPE] is the earliest reference about such an approach to compact 382 representation in the prime underlying finite field that the author 383 is aware of, viewed in that work in the context of the format 384 preserving encryption. 386 7. IANA Considerations 388 This document defines a low-level format that may be suitable for a 389 wide range of applications. However, it is responsibility of the 390 application that adopts this format to define the IDs that will 391 enable the ECC compact point representation in that application. 393 A new ID may not be always necessary. For example, an application 394 that currently allows the [SEC1] encoding may allow the compact 395 representation defined in this document as an extension to the [SEC1] 396 as follows. Consider the encoding of a compressed [FIPS-186] P-256 397 point, for example. The [SEC1] compressed representation of a P-256 398 point will always occupy exactly 33 bytes. On the other hand, the 399 compact representation defined in this document will never exceed 32 400 bytes (it may occupy fewer that 32 bytes when the most significant 401 byte has happened to be zero). This size will allow reliable 402 discrimination between two encoding formats. 404 8. Security Considerations 406 The key pair generation process in Section 4.2 excludes exactly half 407 of the points on the elliptic curve. What is left is the subset of 408 points suitable for compact representation. The filtering of points 409 is based on a public criteria that are applied to the public output 410 of the ECC one-way function. 412 The set of Ord points on the elliptic curve can be subdivided as 413 follows. First, remove the point O, which leaves Ord-1 points. Of 414 these points there are exactly (Ord-1)/2 points that have unique x 415 coordinate. This document specifies a method to form the (Ord-1)/2 416 of points, each having a unique x coordinate. These points are 417 called compliant public keys in Section 4.2. 419 For any two public keys P=(x,y) and P=(x,y') there is up to one bit 420 of entropy in y' v.s. y and this information is public. This bit of 421 entropy doesn't contribute to the difficulty of the underlying hard 422 problem of the ECC: the elliptic curve discrete logarithm problem 423 (ECDLP). 425 It will be shown next that breaking the ECDLP with a key generated 426 according to Section 4.2 is not easier than breaking the ECDLP with a 427 key obtained through a standard key generation algorithm, referred to 428 as the KG algorithm in the Section 4.2. 430 Let us assume that there is an algorithm A that solves the ECDLP for 431 the KG. The algorithm A can be transformed into the algorithm A' as 432 follows. 434 o If P=(x,y) is a compliant public key, the ECDLP is solved with A 435 for the point (x,y): the result is k, such that k*G=(x,y) 437 o If P=(x,y) is not a compliant public key, the ECDLP is solved with 438 A for the point (x,p-y); assuming the output produced by A is k, 439 the output produced by A' is set to (Ord-k). Note that (Ord-k)*G 440 = (x,y), which means that the output of A' is the correct 441 solution. 443 A' is equivalent to A. The complexity of one additional substraction 444 in the prime field is negligible even to the complexity of a single 445 elliptic curve addition. Observe that A' works for all public keys 446 by performing the actual work only on compliant public keys. 448 If we now consider only the compliant public keys, which cuts the 449 number of points in half, we observe that the ECDLP solving algorithm 450 A' doesn't get to break fewer public keys. This concludes the proof. 452 The same result can be observed based on the details of the current 453 state of the art attacks on the ECDLP. These attacks use Pollard's 454 rho algorithm, which uses the collision search in the sequence(s) of 455 generated points with the goal to produce the points P1=(x1,y1) and 456 P2=(x2,y2), such that x1=x2 and y1=y2. The match in the x coordinate 457 is the sufficient event for the successful attack. After this event 458 has ocurred, the sequence(s) that led to x1=x2 collision can be 459 adjusted in a constant number of steps to ensure that y1=y2, if this 460 is not already the case. Furthermore, collision search requires the 461 storage of candidates for the collision. It's wasteful to store 462 (x,y) v.s. storing x and only calculating y when the collision in x 463 is detected. Thus, the ECDLP attack does not benefit from the 464 unpredictability of the y. 466 Finally, note that a common design feature of an ECDH-based system is 467 not to depend on the y coordinate, such as the one defined in the 468 [NIST-SP800-56A]. Thus, the security of the system is unaffected if 469 we fix either of the two possibilities for the point with the given x 470 coordinate. 472 9. References 474 9.1. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 9.2. Informative References 481 [EFD] Bernstein, D. and T. Lange, "Genus-1 curves over large- 482 characteristic fields", 2014, 483 . 485 [FIPS-186] 486 National Institute of Standards and Technology, "Digital 487 Signature Standard (DSS)", FIPS 186-3, June 2009, 488 . 490 [FPE] Rogaway, P. and J. Black, "Ciphers with arbitrary finite 491 domains.", Proceedings Topics in Cryptology CT-RSA. 492 Springer Berlin Heidelberg, 2002, 493 . 495 [Lehmer] Lehmer, D., "Computer technology applied to the theory of 496 numbers", 1969. 498 [Miller] Miller, V., "Use of elliptic curves in cryptography", 499 Proceedings Lecture notes in computer sciences; 218 on 500 Advances in cryptology -- CRYPTO 85, June 1986. 502 [NIST-SP800-133] 503 National Institute of Standards and Technology, 504 "Recommendation for Cryptographic Key Generation", SP 800- 505 133, November 2012, 506 . 508 [NIST-SP800-56A] 509 National Institute of Standards and Technology, 510 "Recommendation for Pair-Wise Key Establishment Schemes 511 Using Discrete Logarithm Cryptography", SP 800-56A 512 Revision 1, March 2007, 513 . 515 [OpenSSL] Jivsov, A., "An enhancement to EC key generation to enable 516 compact point representation", June 2013, 517 . 519 [RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography 520 (ECC) Brainpool Standard Curves and Curve Generation", 521 RFC 5639, March 2010. 523 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 524 Curve Cryptography Algorithms", RFC 6090, February 2011. 526 [SEC1] STANDARDS FOR EFFICIENT CRYPTOGRAPHY, "SEC 1: Elliptic 527 Curve Cryptography", September 2000, . 530 [SuiteB] National Security Agency, "NSA Suite B Cryptography", 531 March 2010, 532 . 534 Appendix A. Sample code change to add compliant key generation to 535 libgcrypt and openssl 537 The complete changes that were needed to make libgcrypt library 538 generate a compliant key are shown inline in this section, followed 539 by pending changes to OpenSSL. 541 A.1. libgcrypt changes 543 In the following changes, the Q is the initial public key, G 544 generator, and d is the corresponding private key. "-" prefix marks 545 the two lines that were replaced with the lines starting with "+". 547 Lines starting with "+" represent the code that adds compliant key 548 generation to libgcrypt. 550 @@ generate_key (ECC_secret_key *sk, 551 unsigned int nbits, 552 const char *name, 553 point_set (&sk->E.G, &E.G); 554 sk->E.n = mpi_copy (E.n); 555 point_init (&sk->Q); 556 - point_set (&sk->Q, &Q); 557 - sk->d = mpi_copy (d); 558 + 559 + /* We want the Q=(x,y) be a "compliant key" in terms of the 560 + * http://tools.ietf.org/html/draft-jivsov-ecc-compact, 561 + * which simply means that we choose either Q=(x,y) or -Q=(x,p-y) 562 + * such that we end up with the min(y,p-y) as the y coordinate. 563 + * Such a public key allows the most efficient compression: y can 564 + * simply be dropped because we know that it's a minimum of 565 + * the two possibilities without any loss of security. 566 + */ 567 + { 568 + gcry_mpi_t x, p_y, y; 569 + const unsigned int nbits = mpi_get_nbits (E.p); 570 + 571 + x = mpi_new (nbits); 572 + p_y = mpi_new (nbits); 573 + y = mpi_new (nbits); 574 + 575 + if (_gcry_mpi_ec_get_affine (x, y, &Q, ctx)) 576 + log_fatal ("ecgen: Failed to get affine coordinates for Q\n"); 577 + 578 + mpi_sub( p_y, E.p, y ); /* p_y = p-y */ 579 + 580 + if( mpi_cmp( p_y /*p-y*/, y ) < 0 ) { /* is p-y < p ? */ 581 + gcry_mpi_t z = mpi_copy( mpi_const (MPI_C_ONE) ); 582 + /* we need to end up with -Q; this assures that new Q's y 583 + * is the smallest one */ 584 + sk->d = mpi_new (nbits); 585 + mpi_sub( sk->d, E.n, d ); /* d = order-d */ 586 + /* log_mpidump ("ecgen d after ", sk->d); */ 587 + gcry_mpi_point_set (&sk->Q, x, p_y/*p-y*/, z); /* Q = -Q */ 588 + if (DBG_CIPHER) 589 + { 590 + log_debug ("ecgen converted Q to a compliant point\n"); 591 + } 592 + mpi_free (z); 593 + } 594 + else 595 + { 596 + /* no change is needed exactly 50% of the time: just copy */ 597 + sk->d = mpi_copy (d); 598 + point_set (&sk->Q, &Q); 599 + if (DBG_CIPHER) 600 + { 601 + log_debug ("ecgen didn't need to convert Q to " 602 + "a compliant point\n"); 603 + } 604 + } 605 + mpi_free (x); 606 + mpi_free (p_y); 607 + mpi_free (y); 608 + } 610 A.2. OpenSSL changes 612 OpenSSL changes are even more compact than in Appendix A.1. They are 613 tracked at [OpenSSL]. 615 Author's Address 617 Andrey Jivsov 618 Symantec Corporation 620 Email: openpgp@brainhub.org