idnits 2.17.1 draft-irtf-cfrg-curves-09.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 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 (September 19, 2015) is 3135 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 812 -- Looks like a reference, but probably isn't: '1' on line 812 -- Looks like a reference, but probably isn't: '2' on line 277 == Missing Reference: '-1' is mentioned on line 302, but not defined -- Looks like a reference, but probably isn't: '31' on line 537 -- Looks like a reference, but probably isn't: '55' on line 331 == Missing Reference: 'A' is mentioned on line 812, but not defined Summary: 1 error (**), 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: March 22, 2016 Rambus Cryptography Research 6 S. Turner 7 IECA, Inc. 8 September 19, 2015 10 Elliptic Curves for Security 11 draft-irtf-cfrg-curves-09 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 March 22, 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 . . . . . . . . . . . . . . . . . . . . . . . 12 65 6.1. Curve25519 . . . . . . . . . . . . . . . . . . . . . . . 12 66 6.2. Curve448 . . . . . . . . . . . . . . . . . . . . . . . . 13 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 71 9.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Appendix A. Deterministic Generation . . . . . . . . . . . . . . 16 73 A.1. p = 1 mod 4 . . . . . . . . . . . . . . . . . . . . . . . 17 74 A.2. p = 3 mod 4 . . . . . . . . . . . . . . . . . . . . . . . 18 75 A.3. Base points . . . . . . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 Since the initial standardization of elliptic curve cryptography (ECC 81 [RFC6090]) in [SEC1] there has been significant progress related to 82 both efficiency and security of curves and implementations. Notable 83 examples are algorithms protected against certain side-channel 84 attacks, various 'special' prime shapes that allow faster modular 85 arithmetic, and a larger set of curve models from which to choose. 86 There is also concern in the community regarding the generation and 87 potential weaknesses of the curves defined by NIST [NIST]. 89 This memo specifies two elliptic curves ("curve25519" and "curve448") 90 that lend themselves to constant-time implementation and an 91 exception-free scalar multiplication that is resistant to a wide 92 range of side-channel attacks, including timing and cache attacks. 93 They are Montgomery curves (where y^2 = x^3 + Ax^2 + x) and thus have 94 birationally equivalent Edwards versions. Edwards curves support the 95 fastest (currently known) complete formulas for the elliptic-curve 96 group operations, specifically the Edwards curve x^2 + y^2 = 1 + 97 dx^2y^2 for primes p when p = 3 mod 4, and the twisted Edwards curve 98 -x^2 + y^2 = 1 + dx^2y^2 when p = 1 mod 4. The maps to/from the 99 Montgomery curves to their (twisted) Edwards equivalents are also 100 given. 102 This memo also specifies how these curves can be used with the 103 Diffie-Hellman protocol for key agreement. 105 2. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 3. Notation 113 Throughout this document, the following notation is used: 115 p Denotes the prime number defining the underlying field. 117 GF(p) The finite field with p elements. 119 A An element in the finite field GF(p), not equal to -2 or 2. 121 d A non-zero element in the finite field GF(p), not equal to 1, in 122 the case of an Edwards curve, or not equal to -1, in the case of a 123 twisted Edwards curve. 125 P A generator point defined over GF(p) of prime order. 127 X(P) The x-coordinate of the elliptic curve point P on a (twisted) 128 Edwards curve. 130 Y(P) The y-coordinate of the elliptic curve point P on a (twisted) 131 Edwards curve. 133 u, v Coordinates on a Montgomery curve. 135 x, y Coordinates on a (twisted) Edwards curve. 137 4. Recommended Curves 139 4.1. Curve25519 141 For the ~128-bit security level, the prime 2^255-19 is recommended 142 for performance on a wide-range of architectures. Few primes of the 143 form 2^c-s with s small exist between 2^250 and 2^521, and other 144 choices of coefficient are not as competitive in performance. This 145 prime is congruent to 1 mod 4 and the derivation procedure in 146 Appendix A results in the following Montgomery curve v^2 = u^3 + 147 A*u^2 + u, called "curve25519": 149 p 2^255-19 151 A 486662 153 order 2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed 155 cofactor 8 157 The base point is u = 9, v = 1478161944758954479102059356840998688726 158 4606134616475288964881837755586237401. 160 This curve is birationally equivalent to a twisted Edwards curve -x^2 161 + y^2 = 1 + d*x^2*y^2, called "edwards25519", where: 163 p 2^255-19 165 d 370957059346694393431380835087545651895421138798432190163887855330 166 85940283555 168 order 2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed 170 cofactor 8 172 X(P) 151122213495354007725011514095885315114540126930418572060461132 173 83949847762202 175 Y(P) 463168356949264781694283940034751631413079938662562256157830336 176 03165251855960 178 The birational maps are: 180 (u, v) = ((1+y)/(1-y), sqrt(-486664)*u/x) 181 (x, y) = (sqrt(-486664)*u/v, (u-1)/(u+1)) 183 The Montgomery curve defined here is equal to the one defined in 184 [curve25519] and the equivalent twisted Edwards curve is equal to the 185 one defined in [ed25519]. 187 4.2. Curve448 189 For the ~224-bit security level, the prime 2^448-2^224-1 is 190 recommended for performance on a wide-range of architectures. This 191 prime is congruent to 3 mod 4 and the derivation procedure in 192 Appendix A results in the following Montgomery curve, called 193 "curve448": 195 p 2^448-2^224-1 197 A 156326 199 order 2^446 - 200 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d 202 cofactor 4 204 The base point is u = 5, v = 3552939267855681752641275020637833348089 205 763993877142718318808984351690887869674100029326737658645509101427741 206 47268105838985595290606362. 208 This curve is birationally equivalent to the Edwards curve x^2 + y^2 209 = 1 + d*x^2*y^2 where: 211 p 2^448-2^224-1 213 d 611975850744529176160423220965553317543219696871016626328968936415 214 087860042636474891785599283666020414768678979989378147065462815545 215 017 217 order 2^446 - 218 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d 220 cofactor 4 222 X(P) 345397493039729516374008604150537410266655260075183290216406970 223 281645695073672344430481787759340633221708391583424041788924124567 224 700732 226 Y(P) 363419362147803445274661903944002267176820680343659030140745099 227 590306164083365386343198191849338272965044442230921818680526749009 228 182718 230 The birational maps are: 232 (u, v) = ((y-1)/(y+1), sqrt(156324)*u/x) 233 (x, y) = (sqrt(156324)*u/v, (1+u)/(1-u)) 235 Both of those curves are also 4-isogenous to the following Edwards 236 curve x^2 + y^2 = 1 + d*x^2*y^2, called "edwards448", where: 238 p 2^448-2^224-1 239 d -39081 241 order 2^446 - 242 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d 244 cofactor 4 246 X(P) 224580040295924300187604334099896036246789641632564134246125461 247 686950415467406032909029192869357953282578032075146446173674602635 248 247710 250 Y(P) 298819210078481492676017930443930673437544040154080242095928241 251 372331506189835876003536878655418784733982303233503462500531545062 252 832660 254 The 4-isogeny maps between the Montgomery curve and this Edwards 255 curve are: 257 (u, v) = (y^2/x^2, (2 - x^2 - y^2)*y/x^3) 258 (x, y) = (4*v*(u^2 - 1)/(u^4 - 2*u^2 + 4*v^2 + 1), 259 -(u^5 - 2*u^3 - 4*u*v^2 + u)/ 260 (u^5 - 2*u^2*v^2 - 2*u^3 - 2*v^2 + u)) 262 The curve edwards448 defined here is also called "Goldilocks" and is 263 equal to the one defined in [goldilocks]. 265 5. The X25519 and X448 functions 267 The "X25519" and "X448" functions perform scalar multiplication on 268 the Montgomery form of the above curves. (This is used when 269 implementing Diffie-Hellman.) The functions take a scalar and a 270 u-coordinate as inputs and produce a u-coordinate as output. 271 Although the functions work internally with integers, the inputs and 272 outputs are 32-byte strings (for X25519) or 56-byte strings (for 273 X448) and this specification defines their encoding. 275 The u-coordinates are elements of the underlying field GF(2^255-19) 276 or GF(2^448-2^224-1) and are encoded as an array of bytes, u, in 277 little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + 278 256^(n-1)*u[n-1] is congruent to the value modulo p and u[n-1] is 279 minimal. When receiving such an array, implementations of X25519 280 (but not X448) MUST mask the most-significant bit in the final byte. 281 This is done to preserve compatibility with point formats which 282 reserve the sign bit for use in other protocols and to increase 283 resistance to implementation fingerprinting. 285 Implementations MUST accept non-canonical values and process them as 286 if they had been reduced modulo the field prime. The non-canonical 287 values are 2^255-19 through 2^255-1 for X25519 and 2^448-2^224-1 288 through 2^448-1 for X448. 290 The following functions implement this in Python, although the Python 291 code is not intended to be performant nor side-channel free. Here 292 the "bits" parameter should be set to 255 for X25519 and 448 for 293 X448: 295 def decodeLittleEndian(b, bits): 296 return sum([b[i] << 8*i for i in range((bits+7)/8)]) 298 def decodeUCoordinate(u, bits): 299 u_list = [ord(b) for b in u] 300 # Ignore any unused bits. 301 if bits % 8: 302 u_list[-1] &= (1<<(bits%8))-1 303 return decodeLittleEndian(u_list, bits) 305 def encodeUCoordinate(u, bits): 306 u = u % p 307 return ''.join([chr((u >> 8*i) & 0xff) 308 for i in range((bits+7)/8)]) 310 Scalars are assumed to be randomly generated bytes. For X25519, in 311 order to decode 32 random bytes as an integer scalar, set the three 312 least significant bits of the first byte and the most significant bit 313 of the last to zero, set the second most significant bit of the last 314 byte to 1 and, finally, decode as little-endian. This means that 315 resulting integer is of the form 2^254 + 8 * {0, 1, ..., 2^(251) - 316 1}. Likewise, for X448, set the two least significant bits of the 317 first byte to 0, and the most significant bit of the last byte to 1. 318 This means that the resulting integer is of the form 2^447 + 4 * {0, 319 1, ..., 2^(445) - 1}. 321 def decodeScalar25519(k): 322 k_list = [ord(b) for b in k] 323 k_list[0] &= 248 324 k_list[31] &= 127 325 k_list[31] |= 64 326 return decodeLittleEndian(k_list, 255) 328 def decodeScalar448(k): 329 k_list = [ord(b) for b in k] 330 k_list[0] &= 252 331 k_list[55] |= 128 332 return decodeLittleEndian(k_list, 448) 334 To implement the X25519(k, u) and X448(k, u) functions (where k is 335 the scalar and u is the u-coordinate) first decode k and u and then 336 perform the following procedure, which is taken from [curve25519] and 337 based on formulas from [montgomery]. All calculations are performed 338 in GF(p), i.e., they are performed modulo p. The constant a24 is 339 (486662 - 2) / 4 = 121665 for curve25519/X25519 and (156326 - 2) / 4 340 = 39081 for curve448/X448. 342 x_1 = u 343 x_2 = 1 344 z_2 = 0 345 x_3 = u 346 z_3 = 1 347 swap = 0 349 For t = bits-1 down to 0: 350 k_t = (k >> t) & 1 351 swap ^= k_t 352 // Conditional swap; see text below. 353 (x_2, x_3) = cswap(swap, x_2, x_3) 354 (z_2, z_3) = cswap(swap, z_2, z_3) 355 swap = k_t 357 A = x_2 + z_2 358 AA = A^2 359 B = x_2 - z_2 360 BB = B^2 361 E = AA - BB 362 C = x_3 + z_3 363 D = x_3 - z_3 364 DA = D * A 365 CB = C * B 366 x_3 = (DA + CB)^2 367 z_3 = x_1 * (DA - CB)^2 368 x_2 = AA * BB 369 z_2 = E * (AA + a24 * E) 371 // Conditional swap; see text below. 372 (x_2, x_3) = cswap(swap, x_2, x_3) 373 (z_2, z_3) = cswap(swap, z_2, z_3) 374 Return x_2 * (z_2^(p - 2)) 376 (Note that these formulas are slightly different from Montgomery's 377 original paper. Implementations are free to use any correct 378 formulas.) 379 Finally, encode the resulting value as 32 or 56 bytes in little- 380 endian order. For X25519, the unused, most-significant bit MUST be 381 zero. 383 The cswap function SHOULD be implemented in constant time (i.e. 384 independent of the swap argument). For example, this can be done as 385 follows: 387 cswap(swap, x_2, x_3): 388 dummy = mask(swap) AND (x_2 XOR x_3) 389 x_2 = x_2 XOR dummy 390 x_3 = x_3 XOR dummy 391 Return (x_2, x_3) 393 Where mask(swap) is the all-1 or all-0 word of the same length as x_2 394 and x_3, computed, e.g., as mask(swap) = 0 - swap. 396 5.1. Side-channel considerations 398 X25519 and X448 are designed so that fast, constant-time 399 implementations are easier to produce. The procedure above ensures 400 that the same sequence of field operations is performed for all 401 values of the secret key, thus eliminating a common source of side- 402 channel leakage. However, this alone does not prevent all side- 403 channels by itself. It is important that the pattern of memory 404 accesses and jumps not depend on the values of any of the bits of k. 405 It is also important that the arithmetic used not leak information 406 about the integers modulo p, for example by having b*c be 407 distinguishable from c*c. On some architectures, even primitive 408 machine instructions, such as single-word division, can have variable 409 timing based on their inputs. 411 Side-channel attacks are an active research area that still sees 412 significant, new results. Implementors are advised to follow this 413 research closely. 415 5.2. Test vectors 417 Two types of tests are provided. The first is a pair of test vectors 418 for each function that consist of expected outputs for the given 419 inputs. The inputs are generally given as 64 or 112 hexadecimal 420 digits that need to be decoded as 32 or 56 binary bytes before 421 processing. 423 X25519: 425 Input scalar: 426 a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4 428 Input scalar as a number (base 10): 429 31029842492115040904895560451863089656 430 472772604678260265531221036453811406496 431 Input u-coordinate: 432 e6db6867583030db3594c1a424b15f7c726624ec26b3353b10a903a6d0ab1c4c 433 Input u-coordinate as a number: 434 34426434033919594451155107781188821651 435 316167215306631574996226621102155684838 436 Output u-coordinate: 437 c3da55379de9c6908e94ea4df28d084f32eccf03491c71f754b4075577a28552 439 Input scalar: 440 4b66e9d4d1b4673c5ad22691957d6af5c11b6421e0ea01d42ca4169e7918ba0d 441 Input scalar as a number (base 10): 442 35156891815674817266734212754503633747 443 128614016119564763269015315466259359304 444 Input u-coordinate: 445 e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a493 446 Input u-coordinate as a number: 447 88838573511839298940907593866106493194 448 17338800022198945255395922347792736741 449 Output u-coordinate: 450 95cbde9476e8907d7aade45cb4b873f88b595a68799fa152e6f8f7647aac7957 452 X448: 454 Input scalar: 455 3d262fddf9ec8e88495266fea19a34d28882acef045104d0d1aae121 456 700a779c984c24f8cdd78fbff44943eba368f54b29259a4f1c600ad3 457 Input scalar as a number (base 10): 458 599189175373896402783756016145213256157230856 459 085026129926891459468622403380588640249457727 460 683869421921443004045221642549886377526240828 461 Input u-coordinate: 462 06fce640fa3487bfda5f6cf2d5263f8aad88334cbd07437f020f08f9 463 814dc031ddbdc38c19c6da2583fa5429db94ada18aa7a7fb4ef8a086 464 Input u-coordinate as a number: 465 382239910814107330116229961234899377031416365 466 240571325148346555922438025162094455820962429 467 142971339584360034337310079791515452463053830 468 Output u-coordinate: 469 ce3e4ff95a60dc6697da1db1d85e6afbdf79b50a2412d7546d5f239f 470 e14fbaadeb445fc66a01b0779d98223961111e21766282f73dd96b6f 472 Input scalar: 473 203d494428b8399352665ddca42f9de8fef600908e0d461cb021f8c5 474 38345dd77c3e4806e25f46d3315c44e0a5b4371282dd2c8d5be3095f 476 Input scalar as a number (base 10): 477 633254335906970592779259481534862372382525155 478 252028961056404001332122152890562527156973881 479 968934311400345568203929409663925541994577184 480 Input u-coordinate: 481 0fbcc2f993cd56d3305b0b7d9e55d4c1a8fb5dbb52f8e9a1e9b6201b 482 165d015894e56c4d3570bee52fe205e28a78b91cdfbde71ce8d157db 483 Input u-coordinate as a number: 484 622761797758325444462922068431234180649590390 485 024811299761625153767228042600197997696167956 486 134770744996690267634159427999832340166786063 487 Output u-coordinate: 488 884a02576239ff7a2f2f63b2db6a9ff37047ac13568e1e30fe63c4a7 489 ad1b3ee3a5700df34321d62077e63633c575c1c954514e99da7c179d 491 The second type of test vector consists of the result of calling the 492 function in question a specified number of times. Initially, set k 493 and u to be the following values: 495 For X25519: 496 0900000000000000000000000000000000000000000000000000000000000000 497 For X448: 498 05000000000000000000000000000000000000000000000000000000 499 00000000000000000000000000000000000000000000000000000000 501 For each iteration, set k to be the result of calling the function 502 and u to be the old value of k. The final result is the value left 503 in k. 505 X25519: 507 After one iteration: 508 422c8e7a6227d7bca1350b3e2bb7279f7897b87bb6854b783c60e80311ae3079 509 After 1,000 iterations: 510 684cf59ba83309552800ef566f2f4d3c1c3887c49360e3875f2eb94d99532c51 511 After 1,000,000 iterations: 512 7c3911e0ab2586fd864497297e575e6f3bc601c0883c30df5f4dd2d24f665424 514 X448: 516 After one iteration: 517 3f482c8a9f19b01e6c46ee9711d9dc14fd4bf67af30765c2ae2b846a 518 4d23a8cd0db897086239492caf350b51f833868b9bc2b3bca9cf4113 519 After 1,000 iterations: 520 aa3b4749d55b9daf1e5b00288826c467274ce3ebbdd5c17b975e09d4 521 af6c67cf10d087202db88286e2b79fceea3ec353ef54faa26e219f38 522 After 1,000,000 iterations: 523 077f453681caca3693198420bbe515cae0002472519b3e67661a7e89 524 cab94695c8f4bcd66e61b9b9c946da8d524de3d69bd9d9d66b997e37 526 6. Diffie-Hellman 528 6.1. Curve25519 530 The X25519 function can be used in an elliptic-curve Diffie-Hellman 531 (ECDH) protocol as follows: 533 Alice generates 32 random bytes in f[0] to f[31] and transmits K_A = 534 X25519(f, 9) to Bob, where 9 is the u-coordinate of the base point 535 and is encoded as a byte with value 9, followed by 31 zero bytes. 537 Bob similarly generates 32 random bytes in g[0] to g[31] and computes 538 K_B = X25519(g, 9) and transmits it to Alice. 540 Using their generated values and the received input, Alice computes 541 X25519(f, K_B) and Bob computes X25519(g, K_A). 543 Both now share K = X25519(f, X25519(g, 9)) = X25519(g, X25519(f, 9)) 544 as a shared secret. Both MUST check, without leaking extra 545 information about the value of K, whether K is the all-zero value and 546 abort if so (see below). Alice and Bob can then use a key-derivation 547 function that includes K, K_A and K_B to derive a key. 549 The check for the all-zero value results from the fact that the 550 X25519 function produces that value if it operates on an input 551 corresponding to a point with order dividing the co-factor, h, of the 552 curve. This check is cheap and so MUST always be carried out. The 553 check may be performed by ORing all the bytes together and checking 554 whether the result is zero as this eliminates standard side-channels 555 in software implementations. 557 Test vector: 559 Alice's private key, f: 560 77076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c2a 561 Alice's public key, X25519(f, 9): 562 8520f0098930a754748b7ddcb43ef75a0dbf3a0d26381af4eba4a98eaa9b4e6a 563 Bob's private key, g: 564 5dab087e624a8a4b79e17f8b83800ee66f3bb1292618b6fd1c2f8b27ff88e0eb 565 Bob's public key, X25519(g, 9): 566 de9edb7d7b7dc1b4d35b61c2ece435373f8343c85b78674dadfc7e146f882b4f 567 Their shared secret, K: 568 4a5d9d5ba4ce2de1728e3bf480350f25e07e21c947d19e3376f09b3c1e161742 570 6.2. Curve448 572 The X448 function can be used in an ECDH protocol very much like the 573 X25519 function. 575 If X448 is to be used, the only differences are that Alice and Bob 576 generate 56 random bytes (not 32) and calculate K_A = X448(f, 5) or 577 K_B = X448(g, 5) where 5 is the u-coordinate of the base point and is 578 encoded as a byte with value 5, followed by 55 zero bytes. 580 As with X25519, both sides MUST check, without leaking extra 581 information about the value of K, whether the resulting shared K is 582 the all-zero value and abort if so. 584 Test vector: 586 Alice's private key, f: 587 9a8f4925d1519f5775cf46b04b5800d4ee9ee8bae8bc5565d498c28d 588 d9c9baf574a9419744897391006382a6f127ab1d9ac2d8c0a598726b 589 Alice's public key, X448(f, 5): 590 9b08f7cc31b7e3e67d22d5aea121074a273bd2b83de09c63faa73d2c 591 22c5d9bbc836647241d953d40c5b12da88120d53177f80e532c41fa0 592 Bob's private key, g: 593 1c306a7ac2a0e2e0990b294470cba339e6453772b075811d8fad0d1d 594 6927c120bb5ee8972b0d3e21374c9c921b09d1b0366f10b65173992d 595 Bob's public key, X448(g, 5): 596 3eb7a829b0cd20f5bcfc0b599b6feccf6da4627107bdb0d4f345b430 597 27d8b972fc3e34fb4232a13ca706dcb57aec3dae07bdc1c67bf33609 598 Their shared secret, K: 599 07fff4181ac6cc95ec1c16a94a0f74d12da232ce40a77552281d282b 600 b60c0b56fd2464c335543936521c24403085d59a449a5037514a879d 602 7. Security Considerations 604 The security level (i.e. the number of "operations" needed for a 605 brute-force attack on a primitive) of curve25519 is slightly under 606 the standard 128-bit level. This is acceptable because the standard 607 security levels are primarily driven by much simplier, symmetric 608 primitives where the security level naturally falls on a power of 609 two. For asymmetric primitives, rigidly adhering to a power-of-two 610 security level would require compromises in other parts of the 611 design, which we reject. Additionally, comparing security levels 612 between types of primitives can be misleading under common threat 613 models where multiple targets can be attacked concurrently 614 [bruteforce]. 616 The ~224-bit security level of curve448 is a trade-off between 617 performance and paranoia. Large quantum computers, if ever created, 618 will break both curve25519 and curve448, and reasonable projections 619 of the abilities of classical computers conclude that curve25519 is 620 perfectly safe. However, some designs have relaxed performance 621 requirements and wish to hedge against some amount of analytical 622 advance against elliptic curves and thus curve448 is also provided. 624 8. Acknowledgements 626 This document merges draft-black-rpgecc-01 and draft-turner- 627 thecurve25519function-01. The following authors of those documents 628 wrote much of the text and figures but are not listed as authors on 629 this document: Benjamin Black, Joppe W. Bos, Craig Costello, Patrick 630 Longa, Michael Naehrig and Watson Ladd. 632 The authors would also like to thank Tanja Lange, Rene Struik, Rich 633 Salz, Ilari Liusvaara, Deirdre Connolly, Simon Josefsson, Stephen 634 Farrell and Georg Nestmann for their reviews and contributions. 636 The X25519 function was developed by Daniel J. Bernstein in 637 [curve25519]. 639 9. References 641 9.1. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 9.2. Informative References 650 [brainpool] 651 ECC Brainpool, "ECC Brainpool Standard Curves and Curve 652 Generation", October 2005, . 655 [bruteforce] 656 Bernstein, D., "Understanding brute force", April 2005, 657 . 659 [curve25519] 660 Bernstein, D., "Curve25519 -- new Diffie-Hellman speed 661 records", 2006, 662 . 665 [ed25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B. 666 Yang, "High-speed high-security signatures", 2011, 667 . 670 [goldilocks] 671 Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", 672 2015, . 674 [montgomery] 675 Montgomery, P., "Speeding the Pollard and elliptic curve 676 methods of factorization", 1983, 677 . 680 [NIST] National Institute of Standards, "Recommended Elliptic 681 Curves for Federal Government Use", July 1999, 682 . 685 [reducing] 686 Menezes, A., Okamoto, T., and S. Vanstone, "Reducing 687 elliptic curve logarithms to logarithms in a finite 688 field", 1993, . 692 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 693 Curve Cryptography Algorithms", RFC 6090, 694 DOI 10.17487/RFC6090, February 2011, 695 . 697 [safecurves] 698 Bernstein, D. and T. Lange, "SafeCurves: choosing safe 699 curves for elliptic-curve cryptography", Oct 2013, 700 . 702 [satoh] Satoh, T. and K. Araki, "Fermat quotients and the 703 polynomial time discrete log algorithm for anomalous 704 elliptic curves", 1998. 706 [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", 707 September 2000, 708 . 710 [semaev] Semaev, I., "Evaluation of discrete logarithms on some 711 elliptic curves", 1998. 713 [smart] Smart, N., "The discrete logarithm problem on elliptic 714 curves of trace one", 1999, 715 . 717 Appendix A. Deterministic Generation 719 This section specifies the procedure that was used to generate the 720 above curves; specifically it defines how to generate the parameter A 721 of the Montgomery curve y^2 = x^3 + Ax^2 + x. This procedure is 722 intended to be as objective as can reasonably be achieved so that 723 it's clear that no untoward considerations influenced the choice of 724 curve. The input to this process is p, the prime that defines the 725 underlying field. The size of p determines the amount of work needed 726 to compute a discrete logarithm in the elliptic curve group and 727 choosing a precise p depends on many implementation concerns. The 728 performance of the curve will be dominated by operations in GF(p) so 729 carefully choosing a value that allows for easy reductions on the 730 intended architecture is critical. This document does not attempt to 731 articulate all these considerations. 733 The value (A-2)/4 is used in several of the elliptic curve point 734 arithmetic formulas. For simplicity and performance reasons, it is 735 beneficial to make this constant small, i.e. to choose A so that 736 (A-2) is a small integer which is divisible by four. 738 For each curve at a specific security level: 740 1. The trace of Frobenius MUST NOT be in {0, 1} in order to rule out 741 the attacks described in [smart], [satoh], and [semaev], as in 742 [brainpool] and [safecurves]. 744 2. MOV Degree [reducing]: the embedding degree k MUST be greater 745 than (r - 1) / 100, as in [brainpool] and [safecurves]. 747 3. CM Discriminant: discriminant D MUST be greater than 2^100, as in 748 [safecurves]. 750 A.1. p = 1 mod 4 752 For primes congruent to 1 mod 4, the minimal cofactors of the curve 753 and its twist are either {4, 8} or {8, 4}. We choose a curve with the 754 latter cofactors so that any algorithms that take the cofactor into 755 account don't have to worry about checking for points on the twist, 756 because the twist cofactor will be the smaller of the two. 758 To generate the Montgomery curve we find the minimal, positive A 759 value, such that A > 2 and (A-2) is divisible by four and where the 760 cofactors are as desired. The find1Mod4 function in the following 761 Sage script returns this value given p: 763 def findCurve(prime, curveCofactor, twistCofactor): 764 F = GF(prime) 766 for A in xrange(3, 1e9): 767 if (A-2) % 4 != 0: 768 continue 770 try: 771 E = EllipticCurve(F, [0, A, 0, 1, 0]) 772 except: 773 continue 775 order = E.order() 776 twistOrder = 2*(prime+1)-order 778 if (order % curveCofactor == 0 and 779 is_prime(order // curveCofactor) and 780 twistOrder % twistCofactor == 0 and 781 is_prime(twistOrder // twistCofactor)): 782 return A 784 def find1Mod4(prime): 785 assert((prime % 4) == 1) 786 return findCurve(prime, 8, 4) 788 Generating a curve where p = 1 mod 4 790 A.2. p = 3 mod 4 792 For a prime congruent to 3 mod 4, both the curve and twist cofactors 793 can be 4 and this is minimal. Thus we choose the curve with these 794 cofactors and minimal, positive A such that A > 2 and (A-2) is 795 divisible by four. The find3Mod4 function in the following Sage 796 script returns this value given p: 798 def find3Mod4(prime): 799 assert((prime % 4) == 3) 800 return findCurve(prime, 4, 4) 802 Generating a curve where p = 3 mod 4 804 A.3. Base points 806 The base point for a curve is the point with minimal, positive u 807 value that is in the correct subgroup. The findBasepoint function in 808 the following Sage script returns this value given p and A: 810 def findBasepoint(prime, A): 811 F = GF(prime) 812 E = EllipticCurve(F, [0, A, 0, 1, 0]) 814 for uInt in range(1, 1e3): 815 u = F(uInt) 816 v2 = u^3 + A*u^2 + u 817 if not v2.is_square(): 818 continue 819 v = v2.sqrt() 821 point = E(u, v) 822 order = point.order() 823 if order > 8 and order.is_prime(): 824 return point 826 Generating the base point 828 Authors' Addresses 830 Adam Langley 831 Google 832 345 Spear St 833 San Francisco, CA 94105 834 US 836 Email: agl@google.com 838 Mike Hamburg 839 Rambus Cryptography Research 840 425 Market Street, 11th Floor 841 San Francisco, CA 94105 842 US 844 Email: mike@shiftleft.org 846 Sean Turner 847 IECA, Inc. 848 3057 Nutley Street 849 Suite 106 850 Fairfax, VA 22031 851 US 853 Email: turners@ieca.com