idnits 2.17.1 draft-irtf-cfrg-curves-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 26, 2015) is 3165 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 ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 681 -- Looks like a reference, but probably isn't: '1' on line 681 -- Looks like a reference, but probably isn't: '2' on line 270 == Missing Reference: '-1' is mentioned on line 295, but not defined -- Looks like a reference, but probably isn't: '31' on line 521 -- Looks like a reference, but probably isn't: '55' on line 323 == Missing Reference: 'A' is mentioned on line 681, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CFRG A. Langley 3 Internet-Draft Google 4 Intended status: Informational M. Hamburg 5 Expires: February 27, 2016 Rambus Cryptography Research 6 S. Turner 7 IECA, Inc. 8 August 26, 2015 10 Elliptic Curves for Security 11 draft-irtf-cfrg-curves-06 13 Abstract 15 This memo specifies two elliptic curves over prime fields that offer 16 high practical security in cryptographic applications, including 17 Transport Layer Security (TLS). These curves are intended to operate 18 at the ~128-bit and ~224-bit security level, respectively, and are 19 generated deterministically based on a list of required properties. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 27, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Recommended Curves . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Curve25519 . . . . . . . . . . . . . . . . . . . . . . . 3 60 4.2. Curve448 . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. The X25519 and X448 functions . . . . . . . . . . . . . . . . 6 62 5.1. Side-channel considerations . . . . . . . . . . . . . . . 9 63 5.2. Test vectors . . . . . . . . . . . . . . . . . . . . . . 9 64 6. Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . . . 11 65 6.1. Curve25519 . . . . . . . . . . . . . . . . . . . . . . . 11 66 6.2. Curve448 . . . . . . . . . . . . . . . . . . . . . . . . 12 67 7. Deterministic Generation . . . . . . . . . . . . . . . . . . 13 68 7.1. p = 1 mod 4 . . . . . . . . . . . . . . . . . . . . . . . 14 69 7.2. p = 3 mod 4 . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.3. Base points . . . . . . . . . . . . . . . . . . . . . . . 15 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 74 9.2. Informative References . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 Since the initial standardization of elliptic curve cryptography 80 (ECC) in [SEC1] there has been significant progress related to both 81 efficiency and security of curves and implementations. Notable 82 examples are algorithms protected against certain side-channel 83 attacks, various 'special' prime shapes that allow faster modular 84 arithmetic, and a larger set of curve models from which to choose. 85 There is also concern in the community regarding the generation and 86 potential weaknesses of the curves defined by NIST [NIST]. 88 This memo specifies two elliptic curves (curve25519 and curve448) 89 that support constant-time, exception-free scalar multiplication that 90 is resistant to a wide range of side-channel attacks, including 91 timing and cache attacks. They are Montgomery curves (where y^2 = 92 x^3 + Ax^2 + x) and thus have birationally equivalent Edwards 93 versions. Edwards curves support the fastest (currently known) 94 complete formulas for the elliptic-curve group operations, 95 specifically the Edwards curve x^2 + y^2 = 1 + dx^2y^2 for primes p 96 when p = 3 mod 4, and the twisted Edwards curve -x^2 + y^2 = 1 + 97 dx^2y^2 when p = 1 mod 4. The maps to/from the Montgomery curves to 98 their (twisted) Edwards equivalents are also given. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 3. Notation 108 Throughout this document, the following notation is used: 110 p Denotes the prime number defining the underlying field. 112 GF(p) The finite field with p elements. 114 A An element in the finite field GF(p), not equal to -2 or 2. 116 d A non-zero element in the finite field GF(p), not equal to 1, in 117 the case of an Edwards curve, or not equal to -1, in the case of a 118 twisted Edwards curve. 120 P A generator point defined over GF(p) of prime order. 122 X(P) The x-coordinate of the elliptic curve point P on a (twisted) 123 Edwards curve. 125 Y(P) The y-coordinate of the elliptic curve point P on a (twisted) 126 Edwards curve. 128 u, v Coordinates on a Montgomery curve. 130 x, y Coordinates on a (twisted) Edwards curve. 132 4. Recommended Curves 134 4.1. Curve25519 136 For the ~128-bit security level, the prime 2^255-19 is recommended 137 for performance on a wide-range of architectures. Few primes of the 138 form 2^c-s with s small exist between 2^250 and 2^521, and other 139 choices of coefficient are not as competitive in performance. This 140 prime is congruent to 1 mod 4 and the derivation procedure in 141 Section 7 results in the following Montgomery curve v^2 = u^3 + A*u^2 142 + u, called "curve25519": 144 p 2^255-19 145 A 486662 147 order 2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed 149 cofactor 8 151 The base point is u = 9, v = 1478161944758954479102059356840998688726 152 4606134616475288964881837755586237401. 154 This curve is birationally equivalent to a twisted Edwards curve -x^2 155 + y^2 = 1 + d*x^2*y^2, called "edwards25519", where: 157 p 2^255-19 159 d 370957059346694393431380835087545651895421138798432190163887855330 160 85940283555 162 order 2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed 164 cofactor 8 166 X(P) 151122213495354007725011514095885315114540126930418572060461132 167 83949847762202 169 Y(P) 463168356949264781694283940034751631413079938662562256157830336 170 03165251855960 172 The birational maps are: 174 (u, v) = ((1+y)/(1-y), sqrt(-486664)*u/x) 175 (x, y) = (sqrt(-486664)*u/v, (u-1)/(u+1) 177 The Montgomery curve defined here is equal to the one defined in 178 [curve25519] and the equivalent twisted Edwards curve is equal to the 179 one defined in [ed25519]. 181 4.2. Curve448 183 For the ~224-bit security level, the prime 2^448-2^224-1 is 184 recommended for performance on a wide-range of architectures. This 185 prime is congruent to 3 mod 4 and the derivation procedure in 186 Section 7 results in the following Montgomery curve, called 187 "curve448": 189 p 2^448-2^224-1 191 A 156326 192 order 2^446 - 193 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d 195 cofactor 4 197 The base point is u = 5, v = 3552939267855681752641275020637833348089 198 763993877142718318808984351690887869674100029326737658645509101427741 199 47268105838985595290606362. 201 This curve is birationally equivalent to the Edwards curve x^2 + y^2 202 = 1 + d*x^2*y^2 where: 204 p 2^448-2^224-1 206 d 611975850744529176160423220965553317543219696871016626328968936415 207 087860042636474891785599283666020414768678979989378147065462815545 208 017 210 order 2^446 - 211 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d 213 cofactor 4 215 X(P) 345397493039729516374008604150537410266655260075183290216406970 216 281645695073672344430481787759340633221708391583424041788924124567 217 700732 219 Y(P) 363419362147803445274661903944002267176820680343659030140745099 220 590306164083365386343198191849338272965044442230921818680526749009 221 182718 223 The birational maps are: 225 (u, v) = ((y-1)/(y+1), sqrt(156324)*u/x) 226 (x, y) = (sqrt(156324)*u/v, (1+u)/(1-u) 228 Both of those curves are also 4-isogenous to the following Edwards 229 curve x^2 + y^2 = 1 + d*x^2*y^2, called "edwards448", where: 231 p 2^448-2^224-1 233 d -39081 235 order 2^446 - 236 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d 238 cofactor 4 239 X(P) 224580040295924300187604334099896036246789641632564134246125461 240 686950415467406032909029192869357953282578032075146446173674602635 241 247710 243 Y(P) 298819210078481492676017930443930673437544040154080242095928241 244 372331506189835876003536878655418784733982303233503462500531545062 245 832660 247 The 4-isogeny maps between the Montgomery curve and this Edwards 248 curve are: 250 (u, v) = (y^2/x^2, -(2 - x^2 - y^2)*y/x^3) 251 (x, y) = (4*v*(u^2 - 1)/(u^4 - 2*u^2 + 4*v^2 + 1), 252 (u^5 - 2*u^3 - 4*u*v^2 + u)/ 253 (u^5 - 2*u^2*v^2 - 2*u^3 - 2*v^2 + u)) 255 The curve "edwards448" defined here is also called "Goldilocks" and 256 is equal to the one defined in [goldilocks]. 258 5. The X25519 and X448 functions 260 The "X25519" and "X448" functions perform scalar multiplication on 261 the Montgomery form of the above curves. (This is used when 262 implementing Diffie-Hellman.) The functions take a scalar and a 263 u-coordinate as inputs and produce a u-coordinate as output. 264 Although the functions work internally with integers, the inputs and 265 outputs are 32-byte or 56-byte strings and this specification defines 266 their encoding. 268 The u-coordinates are elements of the underlying field GF(2^255-19) 269 or GF(2^448-2^224-1) and are encoded as an array of bytes, u, in 270 little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + 271 256^n*u[n] is congruent to the value modulo p and u[n] is minimal. 272 When receiving such an array, implementations of X25519 (but not 273 X448) MUST mask the most-significant bit in the final byte. This is 274 done to preserve compatibility with point formats which reserve the 275 sign bit for use in other protocols and to increase resistance to 276 implementation fingerprinting. 278 Implementations MUST accept non-canonical values and process them as 279 if they had been reduced modulo the field prime. The non-canonical 280 values are 2^255-19 through 2^255-1 for X25519 and 2^448-2^224-1 281 through 2^448-1 for X448. 283 The following functions implement this in Python, although the Python 284 code is not intended to be performant nor side-channel free. Here 285 the "bits" parameter should be set to 255 for X25519 and 448 for 286 X448: 288 def decodeLittleEndian(b, bits): 289 return sum([b[i] << 8*i for i in range((bits+7)/8)]) 291 def decodeUCoordinate(u, bits): 292 u_list = [ord(b) for b in u] 293 # Ignore any unused bits. 294 if bits % 8: 295 u_list[-1] &= (1<<(bits%8))-1 296 return decodeLittleEndian(u_list, bits) 298 def encodeUCoordinate(u, bits): 299 u = u % p 300 return ''.join([chr((u >> 8*i) & 0xff) for i in range((bits+7)/8)]) 302 Scalars are assumed to be randomly generated bytes. For X25519, in 303 order to decode 32 random bytes as an integer scalar, set the three 304 least significant bits of the first byte and the most significant bit 305 of the last to zero, set the second most significant bit of the last 306 byte to 1 and, finally, decode as little-endian. This means that 307 resulting integer is of the form 2^254 + 8 * {0, 1, ..., 2^(251) - 308 1}. Likewise, for X448, set the two least significant bits of the 309 first byte to 0, and the most significant bit of the last byte to 1. 310 This means that the resulting integer is of the form 2^447 + 4 * {0, 311 1, ..., 2^(445) - 1}. 313 def decodeScalar25519(k): 314 k_list = [ord(b) for b in k] 315 k_list[0] &= 248 316 k_list[31] &= 127 317 k_list[31] |= 64 318 return decodeLittleEndian(k_list, 255) 320 def decodeScalar448(k): 321 k_list = [ord(b) for b in k] 322 k_list[0] &= 252 323 k_list[55] |= 128 324 return decodeLittleEndian(k_list, 448) 326 To implement the "X25519(k, u)" and "X448(k, u)" functions (where "k" 327 is the scalar and "u" is the u-coordinate) first decode "k" and "u" 328 and then perform the following procedure, which is taken from 329 [curve25519] and based on formulas from [montgomery]. All 330 calculations are performed in GF(p), i.e., they are performed modulo 331 p. The constant a24 is (486662 - 2) / 4 = 121665 for curve25519/ 332 X25519 and (156326 - 2) / 4 = 39081 for curve448/X448. 334 x_1 = u 335 x_2 = 1 336 z_2 = 0 337 x_3 = u 338 z_3 = 1 339 swap = 0 341 For t = bits-1 down to 0: 342 k_t = (k >> t) & 1 343 swap ^= k_t 344 // Conditional swap; see text below. 345 (x_2, x_3) = cswap(swap, x_2, x_3) 346 (z_2, z_3) = cswap(swap, z_2, z_3) 347 swap = k_t 349 A = x_2 + z_2 350 AA = A^2 351 B = x_2 - z_2 352 BB = B^2 353 E = AA - BB 354 C = x_3 + z_3 355 D = x_3 - z_3 356 DA = D * A 357 CB = C * B 358 x_3 = (DA + CB)^2 359 z_3 = x_1 * (DA - CB)^2 360 x_2 = AA * BB 361 z_2 = E * (AA + a24 * E) 363 // Conditional swap; see text below. 364 (x_2, x_3) = cswap(swap, x_2, x_3) 365 (z_2, z_3) = cswap(swap, z_2, z_3) 366 Return x_2 * (z_2^(p - 2)) 368 (Note that these formulas are slightly different from Montgomery's 369 original paper. Implementations are free to use any correct 370 formulas.) 372 Finally, encode the resulting value as 32 or 56 bytes in little- 373 endian order. For X25519, the unused, most-significant bit MUST be 374 zero. 376 The cswap function SHOULD be implemented in constant time (i.e. 377 independent of the "swap" argument). For example, this can be done 378 as follows: 380 cswap(swap, x_2, x_3): 381 dummy = mask(swap) AND (x_2 XOR x_3) 382 x_2 = x_2 XOR dummy 383 x_3 = x_3 XOR dummy 384 Return (x_2, x_3) 386 Where "mask(swap)" is the all-1 or all-0 word of the same length as 387 x_2 and x_3, computed, e.g., as mask(swap) = 0 - swap. 389 5.1. Side-channel considerations 391 X22519 and X448 are designed so that fast, constant-time 392 implementations are easier to produce. The procedure above ensures 393 that the same sequence of field operations is performed for all 394 values of the secret key, thus eliminating a common source of side- 395 channel leakage. However, this alone does not prevent all side- 396 channels by itself. It is important that the pattern of memory 397 accesses and jumps not depend on the values of any of the bits of 398 "k". It is also important that the arithmetic used not leak 399 information about the integers modulo p, for example by having b*c be 400 distinguishable from c*c. On some architectures, even primitive 401 machine instructions, such as single-word division, can have variable 402 timing based on their inputs. 404 Side-channel attacks are an active research area that still sees 405 significant, new results. Implementors are advised to follow this 406 research closely. 408 5.2. Test vectors 410 Two types of tests are provided. The first is a pair of test vectors 411 for each function that consist of expected outputs for the given 412 inputs: 414 X25519: 416 Input scalar: 417 a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4 418 Input scalar as a number (base 10): 419 31029842492115040904895560451863089656 420 472772604678260265531221036453811406496 421 Input u-coordinate: 422 e6db6867583030db3594c1a424b15f7c726624ec26b3353b10a903a6d0ab1c4c 423 Input u-coordinate as a number: 424 34426434033919594451155107781188821651 425 316167215306631574996226621102155684838 426 Output u-coordinate: 427 c3da55379de9c6908e94ea4df28d084f32eccf03491c71f754b4075577a28552 429 Input scalar: 430 4b66e9d4d1b4673c5ad22691957d6af5c11b6421e0ea01d42ca4169e7918ba0d 431 Input scalar as a number (base 10): 432 35156891815674817266734212754503633747 433 128614016119564763269015315466259359304 434 Input u-coordinate: 435 e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a493 436 Input u-coordinate as a number: 437 88838573511839298940907593866106493194 438 17338800022198945255395922347792736741 439 Output u-coordinate: 440 95cbde9476e8907d7aade45cb4b873f88b595a68799fa152e6f8f7647aac7957 442 X448: 444 Input scalar: 445 3d262fddf9ec8e88495266fea19a34d28882acef045104d0d1aae121 446 700a779c984c24f8cdd78fbff44943eba368f54b29259a4f1c600ad3 447 Input scalar as a number (base 10): 448 5991891753738964027837560161452132561572308560850261299268914594686 \ 449 22403380588640249457727683869421921443004045221642549886377526240828 450 Input u-coordinate: 451 06fce640fa3487bfda5f6cf2d5263f8aad88334cbd07437f020f08f9 452 814dc031ddbdc38c19c6da2583fa5429db94ada18aa7a7fb4ef8a086 453 Input u-coordinate as a number: 454 3822399108141073301162299612348993770314163652405713251483465559224 \ 455 38025162094455820962429142971339584360034337310079791515452463053830 456 Output u-coordinate: 457 ce3e4ff95a60dc6697da1db1d85e6afbdf79b50a2412d7546d5f239f 458 e14fbaadeb445fc66a01b0779d98223961111e21766282f73dd96b6f 460 Input scalar: 461 203d494428b8399352665ddca42f9de8fef600908e0d461cb021f8c5 462 38345dd77c3e4806e25f46d3315c44e0a5b4371282dd2c8d5be3095f 463 Input scalar as a number (base 10): 464 6332543359069705927792594815348623723825251552520289610564040013321 \ 465 22152890562527156973881968934311400345568203929409663925541994577184 466 Input u-coordinate: 467 0fbcc2f993cd56d3305b0b7d9e55d4c1a8fb5dbb52f8e9a1e9b6201b 468 165d015894e56c4d3570bee52fe205e28a78b91cdfbde71ce8d157db 469 Input u-coordinate as a number: 470 6227617977583254444629220684312341806495903900248112997616251537672 \ 471 28042600197997696167956134770744996690267634159427999832340166786063 472 Output u-coordinate: 473 884a02576239ff7a2f2f63b2db6a9ff37047ac13568e1e30fe63c4a7 474 ad1b3ee3a5700df34321d62077e63633c575c1c954514e99da7c179d 475 The second type of test vector consists of the result of calling the 476 function in question a specified number of times. Initially, set "k" 477 and "u" to be the following values: 479 For X25519: 480 0900000000000000000000000000000000000000000000000000000000000000 481 For X448: 482 05000000000000000000000000000000000000000000000000000000 483 00000000000000000000000000000000000000000000000000000000 485 For each iteration, set "k" to be the result of calling the function 486 and "u" to be the old value of "k". The final result is the value 487 left in "k". 489 X25519: 491 After one iteration: 492 422c8e7a6227d7bca1350b3e2bb7279f7897b87bb6854b783c60e80311ae3079 493 After 1,000 iterations: 494 684cf59ba83309552800ef566f2f4d3c1c3887c49360e3875f2eb94d99532c51 495 After 1,000,000 iterations: 496 7c3911e0ab2586fd864497297e575e6f3bc601c0883c30df5f4dd2d24f665424 498 X448: 500 After one iteration: 501 3f482c8a9f19b01e6c46ee9711d9dc14fd4bf67af30765c2ae2b846a 502 4d23a8cd0db897086239492caf350b51f833868b9bc2b3bca9cf4113 503 After 1,000 iterations: 504 aa3b4749d55b9daf1e5b00288826c467274ce3ebbdd5c17b975e09d4 505 af6c67cf10d087202db88286e2b79fceea3ec353ef54faa26e219f38 506 After 1,000,000 iterations: 507 077f453681caca3693198420bbe515cae0002472519b3e67661a7e89 508 cab94695c8f4bcd66e61b9b9c946da8d524de3d69bd9d9d66b997e37 510 6. Diffie-Hellman 512 6.1. Curve25519 514 The "X25519" function can be used in an elliptic-curve Diffie-Hellman 515 (ECDH) protocol as follows: 517 Alice generates 32 random bytes in f[0] to f[31] and transmits K_A = 518 X25519(f, 9) to Bob, where 9 is the u-coordinate of the base point 519 and is encoded as a byte with value 9, followed by 31 zero bytes. 521 Bob similarly generates 32 random bytes in g[0] to g[31] and computes 522 K_B = X25519(g, 9) and transmits it to Alice. 524 Using their generated values and the received input, Alice computes 525 X25519(f, K_B) and Bob computes X25519(g, K_A). 527 Both now share K = X25519(f, X25519(g, 9)) = X25519(g, X25519(f, 9)) 528 as a shared secret. Both MUST check, without leaking extra 529 information about the value of K, whether K is the all-zero value and 530 abort if so (see below). Alice and Bob can then use a key-derivation 531 function that includes K, K_A and K_B to derive a key. 533 The check for the all-zero value results from the fact that the 534 X25519 function produces that value if it operates on an input 535 corresponding to a point with order dividing the co-factor, h, of the 536 curve. This check is cheap and so MUST always be carried out. The 537 check may be performed by ORing all the bytes together and checking 538 whether the result is zero as this eliminates standard side-channels 539 in software implementations. 541 Test vector: 543 Alice's private key, f: 544 77076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c2a 545 Alice's public key, X25519(f, 9): 546 8520f0098930a754748b7ddcb43ef75a0dbf3a0d26381af4eba4a98eaa9b4e6a 547 Bob's private key, g: 548 5dab087e624a8a4b79e17f8b83800ee66f3bb1292618b6fd1c2f8b27ff88e0eb 549 Bob's public key, X25519(g, 9): 550 de9edb7d7b7dc1b4d35b61c2ece435373f8343c85b78674dadfc7e146f882b4f 551 Their shared secret, K: 552 4a5d9d5ba4ce2de1728e3bf480350f25e07e21c947d19e3376f09b3c1e161742 554 6.2. Curve448 556 The "X448" function can be used in an ECDH protocol very much like 557 the "X22519" function. 559 If "X448" is to be used, the only differences are that Alice and Bob 560 generate 56 random bytes (not 32) and calculate K_A = X448(f, 5) or 561 K_B = X448(g, 5) where 5 is the u-coordinate of the base point and is 562 encoded as a byte with value 5, followed by 55 zero bytes. 564 As with "X25519", both sides MUST check, without leaking extra 565 information about the value of K, whether the resulting shared K is 566 the all-zero value and abort if so. 568 Test vector: 570 Alice's private key, f: 571 9a8f4925d1519f5775cf46b04b5800d4ee9ee8bae8bc5565d498c28d 572 d9c9baf574a9419744897391006382a6f127ab1d9ac2d8c0a598726b 573 Alice's public key, X448(f, 5): 574 9b08f7cc31b7e3e67d22d5aea121074a273bd2b83de09c63faa73d2c 575 22c5d9bbc836647241d953d40c5b12da88120d53177f80e532c41fa0 576 Bob's private key, g: 577 1c306a7ac2a0e2e0990b294470cba339e6453772b075811d8fad0d1d 578 6927c120bb5ee8972b0d3e21374c9c921b09d1b0366f10b65173992d 579 Bob's public key, X448(g, 5): 580 3eb7a829b0cd20f5bcfc0b599b6feccf6da4627107bdb0d4f345b430 581 27d8b972fc3e34fb4232a13ca706dcb57aec3dae07bdc1c67bf33609 582 Their shared secret, K: 583 fe2d52f1ca113e5441538037dc4a9d4cb381035fb4a990ac50ac4333 584 63dc072301d1d4f2e82883b35103be96068c11e7c84b8fff74bb6ab0 586 7. Deterministic Generation 588 This section specifies the procedure that was used to generate the 589 above curves; specifically it defines how to generate the parameter A 590 of the Montgomery curve y^2 = x^3 + Ax^2 + x. This procedure is 591 intended to be as objective as can reasonably be achieved so that 592 it's clear that no untoward considerations influenced the choice of 593 curve. The input to this process is p, the prime that defines the 594 underlying field. The size of p determines the amount of work needed 595 to compute a discrete logarithm in the elliptic curve group and 596 choosing a precise p depends on many implementation concerns. The 597 performance of the curve will be dominated by operations in GF(p) so 598 carefully choosing a value that allows for easy reductions on the 599 intended architecture is critical. This document does not attempt to 600 articulate all these considerations. 602 The value (A-2)/4 is used in several of the elliptic curve point 603 arithmetic formulas. For simplicity and performance reasons, it is 604 beneficial to make this constant small, i.e. to choose A so that 605 (A-2) is a small integer which is divisible by four. 607 For each curve at a specific security level: 609 1. The trace of Frobenius MUST NOT be in {0, 1} in order to rule out 610 the attacks described in [smart], [satoh], and [semaev], as in 611 [brainpool] and [safecurves]. 613 2. MOV Degree: the embedding degree k MUST be greater than (r - 1) / 614 100, as in [brainpool] and [safecurves]. 616 3. CM Discriminant: discriminant D MUST be greater than 2^100, as in 617 [safecurves]. 619 7.1. p = 1 mod 4 621 For primes congruent to 1 mod 4, the minimal cofactors of the curve 622 and its twist are either {4, 8} or {8, 4}. We choose a curve with the 623 latter cofactors so that any algorithms that take the cofactor into 624 account don't have to worry about checking for points on the twist, 625 because the twist cofactor will be the smaller of the two. 627 To generate the Montgomery curve we find the minimal, positive A 628 value, such that A > 2 and (A-2) is divisible by four and where the 629 cofactors are as desired. The "find1Mod4" function in the following 630 Sage script returns this value given p: 632 def findCurve(prime, curveCofactor, twistCofactor): 633 F = GF(prime) 635 for A in xrange(3, 1e9): 636 if (A-2) % 4 != 0: 637 continue 639 try: 640 E = EllipticCurve(F, [0, A, 0, 1, 0]) 641 except: 642 continue 644 order = E.order() 645 twistOrder = 2*(prime+1)-order 647 if (order % curveCofactor == 0 and 648 is_prime(order // curveCofactor) and 649 twistOrder % twistCofactor == 0 and 650 is_prime(twistOrder // twistCofactor)): 651 return A 653 def find1Mod4(prime): 654 assert((prime % 4) == 1) 655 return findCurve(prime, 8, 4) 657 Generating a curve where p = 1 mod 4 659 7.2. p = 3 mod 4 661 For a prime congruent to 3 mod 4, both the curve and twist cofactors 662 can be 4 and this is minimal. Thus we choose the curve with these 663 cofactors and minimal, positive A such that A > 2 and (A-2) is 664 divisible by four. The "find3Mod4" function in the following Sage 665 script returns this value given p: 667 def find3Mod4(prime): 668 assert((prime % 4) == 3) 669 return findCurve(prime, 4, 4) 671 Generating a curve where p = 3 mod 4 673 7.3. Base points 675 The base point for a curve is the point with minimal, positive u 676 value that is in the correct subgroup. The "findBasepoint" function 677 in the following Sage script returns this value given p and A: 679 def findBasepoint(prime, A): 680 F = GF(prime) 681 E = EllipticCurve(F, [0, A, 0, 1, 0]) 683 for uInt in range(1, 1e3): 684 u = F(uInt) 685 v2 = u^3 + A*u^2 + u 686 if not v2.is_square(): 687 continue 688 v = v2.sqrt() 690 point = E(u, v) 691 order = point.order() 692 if order > 8 and order.is_prime(): 693 return point 695 Generating the base point 697 8. Acknowledgements 699 This document merges "draft-black-rpgecc-01" and "draft-turner- 700 thecurve25519function-01". The following authors of those documents 701 wrote much of the text and figures but are not listed as authors on 702 this document: Benjamin Black, Joppe W. Bos, Craig Costello, Patrick 703 Longa, Michael Naehrig and Watson Ladd. 705 The authors would also like to thank Tanja Lange, Rene Struik, Rich 706 Salz, Ilari Liusvaara, Deirdre Connolly and Simon Josefsson for their 707 reviews and contributions. 709 The curve25519 function was developed by Daniel J. Bernstein in 710 [curve25519]. 712 9. References 714 9.1. Normative References 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, 718 DOI 10.17487/RFC2119, March 1997, 719 . 721 9.2. Informative References 723 [brainpool] 724 ECC Brainpool, "ECC Brainpool Standard Curves and Curve 725 Generation", October 2005, . 728 [curve25519] 729 Bernstein, D., "Curve25519 -- new Diffie-Hellman speed 730 records", 2006, 731 . 734 [ed25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. 735 Yang, "High-speed high-security signatures", 2011, 736 . 739 [goldilocks] 740 Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", 741 2015, . 743 [montgomery] 744 Montgomery, P., "Speeding the Pollard and elliptic curve 745 methods of factorization", 1983, 746 . 749 [NIST] National Institute of Standards, "Recommended Elliptic 750 Curves for Federal Government Use", July 1999, 751 . 754 [safecurves] 755 Bernstein, D. and T. Lange, "SafeCurves: choosing safe 756 curves for elliptic-curve cryptography", Oct 2013, 757 . 759 [satoh] Satoh, T. and K. Araki, "Fermat quotients and the 760 polynomial time discrete log algorithm for anomalous 761 elliptic curves", 1998. 763 [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", 764 September 2000, 765 . 767 [semaev] Semaev, I., "Evaluation of discrete logarithms on some 768 elliptic curves", 1998. 770 [smart] Smart, N., "The discrete logarithm problem on elliptic 771 curves of trace one", 1999. 773 Authors' Addresses 775 Adam Langley 776 Google 777 345 Spear St 778 San Francisco, CA 94105 779 US 781 Email: agl@google.com 783 Mike Hamburg 784 Rambus Cryptography Research 785 425 Market Street, 11th Floor 786 San Francisco, CA 94105 787 US 789 Email: mike@shiftleft.org 791 Sean Turner 792 IECA, Inc. 793 3057 Nutley Street 794 Suite 106 795 Fairfax, VA 22031 796 US 798 Email: turners@ieca.com