idnits 2.17.1 draft-irtf-cfrg-cpace-00.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 -- The document date (July 28, 2020) is 1369 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 (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Abdalla 3 Internet-Draft DI, Ecole Normale Superieure, Paris 4 Intended status: Informational B. Haase 5 Expires: January 29, 2021 Endress + Hauser Liquid Analysis 6 J. Hesse 7 IBM, Zuerich Research Laboratory 8 July 28, 2020 10 CPace, a balanced composable PAKE 11 draft-irtf-cfrg-cpace-00 13 Abstract 15 This document describes CPace which is a protocol for two parties 16 that share a low-entropy secret (password) to derive a strong shared 17 key without disclosing the secret to offline dictionary attacks. 18 This method was tailored for constrained devices, is compatible with 19 any group of both prime- and non-prime order, and comes with a 20 security proof providing composability guarantees. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 29, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 58 3. Definition CPace . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. CPace . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.1. CPACE-X25519-ELLIGATOR2_SHA512-SHA512 . . . . . . . . . . 9 64 4.2. CPACE-P256-SSWU_SHA256-SHA256 . . . . . . . . . . . . . . 11 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 70 8.2. Informative References . . . . . . . . . . . . . . . . . 16 71 Appendix A. CPace25519 Test Vectors . . . . . . . . . . . . . . 17 72 A.1. X25519 test vectors . . . . . . . . . . . . . . . . . . . 17 73 A.2. Elligator2 test vectors . . . . . . . . . . . . . . . . . 18 74 A.3. Test vectors for the secret generator G . . . . . . . . . 19 75 A.4. Test vectors for CPace DH . . . . . . . . . . . . . . . . 20 76 A.5. Test vectors for intermediate session key generation . . 21 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 79 1. Introduction 81 This document describes CPace which is a protocol for two parties 82 that share a low-entropy secret (password) to derive a to derive a 83 strong shared key without disclosing the secret to offline dictionary 84 attacks. This preliminary working version is a renamed version of 85 the earlier draft-haase-cpace-01 with minor corrections. It has been 86 uploaded for starting the work in the newly formed team of editors 87 (M. Abdalla, B. Haase, J. Hesse) and did not yet see a detailed 88 review by M. Abdalla and J. Hesse. The CPace method was tailored 89 for constrained devices and specifically considers efficiency and 90 hardware side-channel attack mitigations at the protocol level. 91 CPace is designed to be compatible with any group of both prime- and 92 non-prime order and explicitly handles the complexity of cofactor 93 clearing on the protcol level. CPace comes with a security proof 94 providing composability guarantees. As a protocol, CPace is designed 95 to be compatible with so-called "x-coordinate-only" Diffie-Hellman 96 implementations on elliptic curve groups. 98 CPace is designed to be suitable as both, a building block within a 99 larger protocol construction using CPace as substep, and as a 100 standalone protocol. 102 It is considered, that for composed larger protocol constructions, 103 the CPace subprotocol might be best executed in a separate 104 cryptographic hardware, such as secure element chipsets. The CPace 105 protocol design aims at considering the resulting constraints. 107 2. Requirements Notation 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 3. Definition CPace 117 3.1. Setup 119 Let C be a group in which there exists a subgroup of prime order p 120 where the computational simultaneous Diffie-Hellman (SDH) problem 121 [VTBPEKE] is hard. C has order p*c where p is a large prime; c will 122 be called the cofactor. Let I be the unit element in C, e.g., the 123 point at infinity in if C is an elliptic curve group. We denote the 124 operations in the group using addition and multiplication operators, 125 e.g. P + (P + P) = P + 2 * P = 3 * P. We refer to a sequence of n 126 additions of an element in P as scalar multiplication by n and use 127 the notation scalar_multiply(P,n). 129 With F we denote a field that may be associated with C, e.g. the 130 prime base field used for representing the coordinates of points on 131 an elliptic curve. 133 We assume that for any element P in C there is a representation 134 modulo negation, encode_group_element_mod_neg(P) as a byte string 135 such that for any Q in C with Q != P and Q != -P, 136 encode_group_element_mod_neg(P) != encode_group_element_mod_neg(Q). 137 It is recommended that encodings of the elements P and -P share the 138 same result string. Common choices would be a fixed (per-group) 139 length encoding of the x-coordinate of points on an elliptic curve C 140 or its twist C' in Weierstrass form, e.g. according to [IEEE1363] in 141 case of short Weierstrass form curves. For curves in Montgomery form 142 correspondingly the u-coordinate would be encoded, as specified, 143 e.g., by the encodeUCoordinate function from [RFC7748]. 145 With J we denote the group modulo negation associated to C. Note 146 that in J the scalar multiplication operation scalar_multiply is well 147 defined since scalar_multiply(P,s) == -scalar_multiply(-P,s) while 148 arbitrary additions of group elements are no longer available. 150 With J' be denote a second group modulo negation that might share the 151 byte-string encoding function encode_group_element_mod_neg with J 152 such for a given byte string either an element in J or J' is encoded. 153 If the x-coordinate of an elliptic curve point group is used for the 154 encoding, J' would commonly be corresponding to the group of points 155 on the elliptic curve's quadratic twist. Correspondingly, with p' we 156 denote the largest prime factor of the order of J' and its cofactor 157 with c'. 159 Let scalar_cofactor_clearing(s) be a cofactor clearing function 160 taking an integer input argument and returning an integer as result. 161 For any s, scalar_cofactor_clearing(s) is REQUIRED to be of the form 162 c * s1. I.e. it MUST return a multiple of the cofactor. An example 163 of such a function may be the cofactor clearing and clamping 164 functions decodeScalar25519 and decodeScalar448 as used in the X25519 165 and X448 protocols definitions of [RFC7748]. In case of prime-order 166 groups with c == 1, it is RECOMMENDED to use the identity function 167 with scalar_cofactor_clearing(s) = s. 169 Let scalar_mult_cc(P,s) be a joint "scalar multiplication and 170 cofactor clearing" function of an integer s and an string-encoded 171 value P, where P could represent an element either on J or J'. If P 172 is an element in J or J', the scalar_mult_cc function returns a 173 string encoding of an element in J or J' respectively, such that the 174 result of scalar_mult_cc(P,s) encodes (scalar_cofactor_clearing(s) * 175 P). 177 Let scalar_mult_ccv(P,s) be a "scalar multiplication cofactor 178 clearing and verify" function of an integer s and an encoding of a 179 group element P. Unlike scalar_mult_cc, scalar_mult_ccv additionally 180 carries out a verification that checks that the computational 181 simultaneous Diffie-Hellman problem (SDH) is hard in the subgroup (in 182 J or J') generated by the encoded element SP = scalar_mult_cc(P,s). 183 In case that the verification fails (SP might be of low order or on 184 the wrong curve), scalar_mult_ccv is REQUIRED to return the encoding 185 of the identity element I. Otherwise scalar_mult_ccv(P,S) is 186 REQUIRED to return the result of scalar_mult_cc(P,s). A common 187 choice for scalar_mult_ccv for Montgomery curves with twist security 188 would be the X25519 and X448 Diffie-Hellman functions as specified in 189 [RFC7748]. For curves in short Weierstrass form, scalar_mult_ccv 190 could be implemented by the combination of a point verification of 191 the input point with a scalar multiplication. Here scalar_mult_ccv 192 SHALL return the encoding of the neutral element I if the input point 193 P was not on the curve C. 195 Let P=map_to_group_mod_neg(r) be a mapping operation that maps a 196 string r to an encoding of an element P in J. Common choices would 197 be the combination of map_to_base and map_to_curve methods as defined 198 in the hash2curve draft [HASH2CURVE]. Note that we don't require and 199 RECOMMEND cofactor clearing here since this complexity is already 200 included in the definition of the scalar multiplication operation 201 calar_mult_cc above. Additionally requiring cofactor clearing also 202 in map_to_group_mod_neg() would result in efficiency loss. 204 || denotes concatenation of strings. We also let len(S) denote the 205 length of a string in bytes. Finally, let nil represent an empty 206 string, i.e., len(nil) = 0. 208 Let H(m) be a hash function from arbitrary strings m to bit strings 209 of a fixed length. Common choices for H are SHA256 or SHA512 210 [RFC6234]. H is assumed to segment messages m into blocks m_i of 211 byte length H_block. E.g. the blocks used in SHA512 have a size of 212 128 bytes. 214 Let strip_sign_information(P) be function that takes a string 215 encoding of an element P in J and strips any information regarding 216 the sign of P, such that strip_sign_information(P) = 217 strip_sign_information(-P). For short Weierstrass (Montgomery) 218 curves this function will return a string encoding the x-coordinate 219 (u-coordinate). The purpose of defining this function is for 220 allowing for x-coordinate only scalar multiplication algorithms. The 221 sign is to be stripped before generating the intermediate session key 222 ISK. 224 With ISK we denote the intermediate session key output string 225 provided by CPace that is generated by a hash operation on the 226 Diffie-Hellman result. It is RECOMMENDED to apply ISK to a KDF 227 function prior to using the key in a higher-level protocol. 229 KDF(Q) is a key-derivation function that takes an string and derives 230 key of length L. A common choice for a KDF would be HMAC-SHA512. 232 With DSI we denote domain-separation identifier strings that may be 233 prepended to the inputs of Hash and KDF functions. 235 Let A and B be two parties. A and B may also have digital 236 representations of the parties' identities such as Media Access 237 Control addresses or other names (hostnames, usernames, etc). We 238 denote the parties' representation and the parties themselves both by 239 using the identifiers A and B. 241 With CI we denote a string that SHALL be formed by the concatenation 242 of the identifiers A and B and an an OPTIONAL associated data string. 243 AD includes information which A and B might want to authenticate in 244 the protocol execution. CI = A || B || AD; . One first example of 245 CI data is an encoding of the concatenation of IP addresses and port 246 numbers of both parties. AD might include a list of supported 247 protocol versions if CPace were used in a higher-level protocol which 248 negotiates use of a particular version. Including this list would 249 ensure that both parties agree upon the same set of supported 250 protocols and therefore prevent downgrade attacks. 252 We also assume that A and B share a common encoding of a password 253 related string PRS. Typically PRS is a low-entropy secret such as a 254 user-supplied password (pw) or a personal identification number. 255 Note that CPace is NOT RECOMMENDED to be used in conjunction with 256 user datbases that include more than one user account. CPace does 257 not provide mechanisms for agreeing on user names, deriving salt 258 values and agreeing on workload parameters, as required by the memory 259 hard iterated hash functions that should be used for such databases. 260 In such settings it is RECOMMENDED to use CPace as a subcomponent of 261 the higher-level AuCPace protocol. 263 Let sid be a session id byte string chosen for each protocol session 264 before protocol execution; The length len(sid) SHOULD be larger or 265 equal to 16 bytes. 267 With ZPAD we denote a zero-padding string that is appended to PRS 268 such that DSI||PRS has a length of at least H_block. CPace aims at 269 mixing in entropy of PRS into the full internal state of the hash 270 function before any adversary-known variable information (ADVI) 271 enters the hashing algorithm. ADVI such as party identities or 272 session IDs might be partially controlled by an adversary. 273 Correlations of ADVI with the bare PRS string are considered to be 274 easier exploitable by side-channel methods in comparison to a pre- 275 hashed representation of PRS. 277 3.2. Protocol Flow 279 CPace is a one round protocol to establish an intermediate shared 280 secret ISK with implicit mutual authentication. Prior to invocation, 281 A and B are provisioned with public (CI) and secret information (PRS) 282 as prerequisite for running the protocol. During the first round, A 283 sends a public share Ya to B, and B responds with its own public 284 share Yb. Both A and B then derive a shared secret ISK. ISK is 285 meant to be used for producing encryption and authentication keys by 286 a KDF function outside of the scope of CPace. Prior to entering the 287 protocol, A and B agree on a sid string. sid is typically pre- 288 established by a higher-level protocol invocing CPace. If no such 289 sid is available from a higher-level protocol, a suitable approach is 290 to let A choose a fresh random sid string and send it to B together 291 with Ya. This method is shown in the setup protocol section below. 293 This sample trace is shown below. 295 A B 296 | (setup protocol | 297 (sample sid) | and sid) | 298 |----------------->| 299 --------------------------------------- 300 | | 301 (compute Ya) | Ya | 302 |----------------->| 303 | Yb | (compute Yb) 304 |<-----------------| 305 | (verify data) | 306 | (derive ISK) | 308 3.3. CPace 310 Both parties start with agreed values on the sid string, the channel 311 identifier CI and the password-related string PRS. 313 The channel identifier, CI, SHOULD include an encoding of the 314 communication channel used by both parties A and B, such as, e.g., IP 315 and port numbers of both parties. 317 To begin, A calculates a generator G = map_to_group_mod_neg(DSI1 || 318 PRS || ZPAD || sid || CI). 320 A picks ya randomly and uniformly according to the requirement of the 321 group J and calculates Ya=scalar_mult_cc (G,ya). A then transmits Ya 322 to B. 324 B picks yb randomly and uniformly. B then calculates G = 325 map_to_group_mod_neg(DSI1 || PRS || ZPAD || sid || CI) and Yb = 326 scalar_mult_cc(G,yb). B then calculates K = scalar_mult_ccv(Ya,yb). 327 B MUST abort if K is the encoding of the neutral element I. 328 Otherwise B sends Yb to A and proceeds as follows. B strips the sign 329 information from K, Ya and Yb to obtain the strings Ks, Yas and Ybs 330 by using the strip_sign_information() function. B returns ISK = 331 H(DSI2 || sid || Ks || Yas || Ybs). 333 Upon reception of Yb, A calculates K = scalar_mult_ccv(Yb,ya). A 334 MUST abort if K is the neutral element I. If K is different from I, 335 A strips the sign information from K, Ya and Yb and returns ISK = 336 H(DSI2 || sid || Ks || Yas || Ybs). 338 K and Ks are shared values, though they MUST NOT be used as a shared 339 secret key. Note that calculation of ISK from Ks includes the 340 protocol transcript and prevents key malleability with respect to 341 man-in-the-middle attacks from active adversaries. 343 Upon completion of this protocol, the session key ISK returned by A 344 and B will be identical by both parties if and only if the supplied 345 input parameters sid, PRS and CI match on both sides and the 346 information on the public elements in J were not modified by an 347 adversary. 349 4. Ciphersuites 351 This section documents CPACE ciphersuite configurations. A 352 ciphersuite is REQUIRED to specify all of, 354 o a group modulo negation J with an associated 355 encode_group_element_mod_neg function 357 o scalar_mult_cc(P,s) and scalar_mult_ccv(P,s) functions operating 358 on encodings of elements P in J 360 o a mapping function map_to_group_mod_neg(r) converting byte strings 361 r into elements in J 363 o a strip_sign_information(Q) function operating on string 364 representations of elements Q 366 o a hash function H 368 o and domain separation strings DSI1, DSI2 370 Currently, detailed specifications are available for CPACE- 371 X25519-ELLIGATOR2_SHA512-SHA512 and CPACE-P256-SSWU_SHA256-SHA256. 372 These cipher suites are specifically designed for suitability also 373 with constrained hardware. It is recommended that cipher suites for 374 short Weierstrass curves are specified in line with the corresponding 375 definitions for NIST-P256. Cipher suites for modern Montgomery or 376 Edwards curves are recommended to be specified in line with the 377 definitions for Curve25519. 379 +------------+--------------------------+------------------+ 380 | J | map_to_group_mod_neg | KDF | 381 +------------+--------------------------+------------------+ 382 | X25519 | ELLIGATOR2_SHA512 | SHA512 [RFC6234] | 383 | | | | 384 | NIST P-256 | SSWU_SHA256 [HASH2CURVE] | SHA256 [RFC6234] | 385 +------------+--------------------------+------------------+ 387 Table 1: CPace Ciphersuites 389 4.1. CPACE-X25519-ELLIGATOR2_SHA512-SHA512 391 This cipher suite targets particularly constrained targets and 392 implements specific optimizations. It uses the group of points on 393 the Montgomery curve Curve25519 for constructing J. The base field F 394 is the prime field built upon the prime 2^255 - 19. The Diffie- 395 Hellmann protocol X25519 and the group are specified in [RFC7748]. 396 The encode_group_element_mod_neg(P) is implemented by the 397 encodeUCoordinate(P) function defined in [RFC7748]. The neutral 398 element I is encoded as a 32 byte zero-filled string. 400 The domain separation strings are defined as DSI1 = "CPace25519-1", 401 DSI2 = "CPace25519-2" (twelve-byte ASCII encoding without ANSI-C 402 style trailing zeros). 404 Both, scalar_mult_cc and scalar_mult_ccv, are implemented by the 405 X25519 function specified in [RFC7748]. 407 The secret scalars ya and yb used for X25519 shall be sampled as 408 uniformly distributed 32 byte strings. 410 The map_to_group_mod_neg function is implemented as follows. First 411 the byte length of the ZPAD zero-padding string is determined such 412 that len(ZPAD) = max(0, H_block_SHA512 - len(DSI1 || PRS)), with 413 H_block_SHA512 = 128 bytes. Then a byte string u is calculated by 414 use of u = SHA512(DSI1||PRS||ZPAD||sid||CI). The resulting string is 415 interpreted as 512-bit integer in little-endian format according to 416 the definition of decodeLittleEndian() from [RFC7748]. The resulting 417 integer is then reduced to the base field as input to the Elligator2 418 map specified in [HASH2CURVE] to yield the secret generator G = 419 Elligator2(u). 421 CPace25519 returns a session key ISK of 64 bytes length by a single 422 invocation of SHA512(DSI2||sid||K||Ya||Yb). Since the encoding does 423 not incorporate the sign from the very beginning Qs = 424 strip_sign_information(Q) == Q for this cipher suite. 426 The following sage code could be used as reference implementation for 427 the mapping and key derivation functions. 429 431 def littleEndianStringToInteger(k): 432 bytes = [ord(b) for b in k] 433 return sum((bytes[i] << (8 * i)) for i in range(len(bytes))) 435 def map_to_group_mod_neg_CPace25519(sid, PRS, CI): 436 m = hashlib.sha512() 437 p = 2^255 - 19 439 H_block_SHA512 = 128 440 DSI1 = b"CPace25519-1" 441 ZPAD_len = max(0,H_block_SHA512 - len(CI) - len(PRS)) 442 ZPAD = ZPAD_len * "\0" 444 m.update(DSI1) 445 m.update(PRS) 446 m.update(ZPAD) 447 m.update(sid) 448 m.update(CI) 449 u = littleEndianStringToInteger(m.digest()) 450 return map_to_curve_elligator2_curve25519(u % p) 452 def generate_ISK_CPace25519(sid,K,Ya,Yb): 453 m = hashlib.sha512(b"CPace25519-2") 454 m.update(sid) 455 m.update(K) 456 m.update(Ya) 457 m.update(Yb) 458 return m.digest() 460 462 The definitions above aim at making the protocol suitable for 463 outsourcing CPace to secure elements (SE) where nested hash function 464 constructions such as defined in [RFC5869] have to be considered to 465 be particularly costly. As a result, the task of generating session 466 keys by a strong KDF function is left out of the scope of the CPace 467 protocol. This fact is expressed by the naming of the intermediate 468 shared Key ISK. The definitions above regarding the mapping deviate 469 from the definition in the encode_to_curve function from [HASH2CURVE] 470 by significantly reducing the amount of hash invocations. Moreover, 471 the CPace protocol specification, unlike the hash-to-curve draft 472 specification also considers the risk of side-channel leakage during 473 the hashing of PRS by introducing the ZPAD padding. Mitigating 474 attacks of an adversary that analyzes correlations between publicly 475 known information with the low-entropy PRS strings was considered 476 relevant in important settings. We also avoid the overhead of 477 redundant cofactor clearing, by making the Diffie-Hellman protocol 478 responsible for this task (and not the mapping algorithm). Due to 479 its use in Ed25519 [RFC8032], SHA512 is considered to be the natural 480 hash choice for Curve25519. The 512 bit output of SHA512 moreover 481 allows for removing any statistical bias stemming from the non- 482 canonical base field representations, such that the overhead of the 483 HKDF_extract/HKDF_expand sequences from [HASH2CURVE] are considered 484 not necessary (in line with the assessments regarding Curve25519 in 485 [HASH2CURVE]). 487 4.2. CPACE-P256-SSWU_SHA256-SHA256 489 This cipher suite targets applications that do not as agressively 490 focus on efficiency, bandwidth and code size as the Curve25519 491 implementation. Instead it aims at reusing existing encoding and 492 curve standards wherever possible. 494 It uses the group of points on the NIST P-256 curve which is defined 495 in short Weierstrass form for constructing J [RFC5480]. The base 496 field F is the prime field built upon the Solinas prime p = 497 2^256-2^224+2^192+2^96-1. Encoding of full group elements requires 498 both, x and y coordinates. In order to facilitate point validation 499 and in order to be in line with recent TLS 1.3 requirements, 500 implementations MUST encode both, x and y coordinates. It is 501 RECOMMENDED to use the uncompressed format from [SEC1] using the 0x04 502 octet prefix. The strip_sign_information() function returns the 503 substring from the SEC1 representation encoding the x-coordinate of 504 the curve point. 506 NIST P-256 is of prime order and does not require cofactor clearing. 507 The scalar_cofactor_clearing function is the identity function with 508 scalar_cofactor_clearing(s) == s 510 The domain separation strings are defined as DSI1 = "CPace-P256-1", 511 DSI2 = "CPace-P256-2". 513 For the scalar_mult_cc function operating on the internally generated 514 points, a conventional scalar multiplication on P-256 is used, i.e. 515 without the need of further verification checks. The scalar_mult_ccv 516 function that operates on remotely generated points includes the 517 mandatory verification as follows. First from the encoded point the 518 x and y coordinates are decoded. These points are used for verifying 519 the curve equation. If the point is not on the curve, 520 scalar_mult_ccv returns the neutral element I. If the point is on 521 the curve, scalar_mult_ccv calls scalar_mult_cc and returns the 522 result of the scalar multiplication. 524 For P-256, the map_to_group_mod_neg function is implemented as 525 follows. The zero-padding string length is calculated as len(ZPAD) = 526 max(0, H_block_SHA256 - len(DSI1 || PRS)) with H_block_SHA256 = 64. 527 For the mapping to the curve, a 32 byte string U1 = SHA256(DSI1 || 528 PRS || ZPAD || sid || CI) is calculated. From U1 a second 32 byte 529 value is calculated as U2 = SHA256(U1). The concatenation of U1 and 530 U2 is interpreted as a 512 bit integer u by use of the u = 531 OS2IP(U1 || U2) function from [HASH2CURVE]. This value is reduced to 532 a 32 byte representation of a field element fu = u % p. The 533 coordinates (x,y) in F of the secret generator G are calculated as 534 (x,y) = map_to_curve_simple_swu_3mod4(fu) function from [HASH2CURVE]. 536 As hash function H SHA256 is chosen, returning a session key ISK of 537 32 bytes length with ISK=SHA256(DSI2 || sid || Ks || Yas || Ybs). 539 The following sage code could be used as reference implementation for 540 the mapping and key derivation functions. 542 544 def map_to_group_mod_neg_CPace_P256(sid, PRS, CI): 545 m = hashlib.sha256() 547 H_block_SHA256 = 64 548 DSI1 = b"CPace-P256-1" 549 ZPAD_len = max(0,H_block_SHA256 - len(CI) - len(PRS)) 550 ZPAD = ZPAD_len * "\0" 552 m.update(DSI1) 553 m.update(PRS) 554 m.update(ZPAD) 555 m.update(sid) 556 m.update(CI) 557 U1 = m.digest() 558 U2 = hashlib.sha256(U1).digest() 559 u = OS2I(U1 + U2) 560 return map_to_curve_simple_swu_3mod4(u) 562 def generate_ISK_CPace_P256(sid,K,Ya,Yb): 563 m = hashlib.sha256(b"CPace-P256-2") 564 m.update(sid) 565 m.update(strip_sign_information(K)) 566 m.update(strip_sign_information(Ya)) 567 m.update(strip_sign_information(Yb)) 568 return m.digest() 570 572 Similarly to the Curve25519 implementation, the definitions above aim 573 at making the protocol suitable for outsourcing to secure elements 574 where hash function invocations have to be considered to be 575 particularly costly. As a result, the task of generating session 576 keys by a strong KDF function is left out of the scope of the CPace 577 protocol. The naming of ISK as intermediate shared key reflects this 578 fact. Also the method for calculating the generator has been 579 optimized for reducing the number of hash calculations in comparison 580 to the suggestions [HASH2CURVE]. 582 5. Security Considerations 584 A security proof of CPace is found in [cpace_paper]. 586 Elements received from a peer MUST be checked by a proper 587 implementation of the scalar_mult_ccv method. Failure to properly 588 validate group elements can lead to attacks. The Curve25519-based 589 cipher suite employs the twist security feature of the curve for 590 point validation. As such, it is mandatory to check that all low- 591 order points on both the curve and the twist are mapped on the 592 neutral element by the X25519 function. Corresponding test vectors 593 are provided in the appendix. 595 The choices of random numbers MUST be uniform. Randomly generated 596 values (e.g., ya and yb) MUST NOT be reused. 598 CPace is NOT RECOMMENDED to be used in conjunction with applications 599 supporting different username/password pairs. In this case it is 600 RECOMMENDED to use CPace as building block of the augmented AuCPace 601 protocol. 603 If CPace is used as a building block of higher-level protocols, it is 604 RECOMMENDED that sid is generated by the higher-level protocol and 605 passed to CPace. It is RECOMMENDED sid, is generated by sampling 606 ephemeral random strings. 608 Since CPace is designed to be used as a building block in higher- 609 level protocols and for compatibility with constrained hardware, it 610 does not by itself include a strong KDF construction. CPace uses a 611 simple hash operation for generating its intermediate key ISK. It is 612 RECOMMENDED that the ISK is post-processed by a KDF according the 613 needs of the higher-level protocol. In case that the CPace protocol 614 is delegated to a secure element hardware, it is RECOMMENDED that the 615 main processing unit applies a KDF to the externally generated ISK. 617 In case that side-channel attacks are to be considered practical for 618 a given application, it is RECOMMENDED to focus side-channel 619 protections such as masking and redundant execution (faults) on the 620 process of calculating the secret generator G. The most critical 621 aspect to consider is the processing of the first block of the hash 622 that includes the PRS string. The CPace protocol construction 623 considers the fact that side-channel protections of hash functions 624 might be particularly resource hungry. For this reason, CPace aims 625 at minimizing the number of hash functions invocations in the 626 specified mapping method. 628 CPace is proven secure under the hardness of the computational 629 Simultaneous Diffie-Hellmann (SDH) assumption in the group J (as 630 defined in [VTBPEKE]). Still, even for the event that large-scale 631 quantum computers (LSQC) will become available, CPace forces an 632 active adversary to solve one CDH per password guess. Using the 633 wording suggested by Steve Thomas on the CFRG mailing list, CPace is 634 "quantum-annoying". 636 6. IANA Considerations 638 No IANA action is required. 640 7. Acknowledgments 642 Thanks to the members of the CFRG for comments and advice. Any 643 comment and advice is appreciated. 645 Comments are specifically invited regarding the following aspect. 646 The CPace mapping function design is based on the following 647 assessments. 1.) Masked, hardware-side-channel-protected hash 648 function implementations should be considered highly desirable for 649 the calculation of the generators G if an implementation might be 650 exposed to physical attacks. 2.) The complexity of such protected 651 hash implementations (possibly with lots of boolean-arithmetic 652 masking conversions) was assessed critical for constrained hardware. 653 Hash operation complexity was also assessed to be critical for secure 654 element chipsets that often were assessed to run hash operations in 655 software without hardware accellerator support. 657 This assessment is not in line with the assumptions for the hash-to- 658 curve-05 draft. As a consequence, this draft aimed at more 659 aggressively reducing the number of nested hash function invocations 660 in comparison to the suggestions of the hash-to-curve-05 draft. 662 8. References 664 8.1. Normative References 666 [HASH2CURVE] 667 Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and 668 C. Wood, "draft-irtf-cfrg-hash-to-curve-05", 2019. 670 IRTF draft standard 672 [IEEE1363] 673 IEEE, ""Standard Specifications for Public Key 674 Cryptography", IEEE 1363", 2000. 676 IEEE 1363 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, 680 DOI 10.17487/RFC2119, March 1997, 681 . 683 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 684 "Elliptic Curve Cryptography Subject Public Key 685 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 686 . 688 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 689 Key Derivation Function (HKDF)", RFC 5869, 690 DOI 10.17487/RFC5869, May 2010, 691 . 693 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 694 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 695 DOI 10.17487/RFC6234, May 2011, 696 . 698 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 699 for Security", RFC 7748, DOI 10.17487/RFC7748, January 700 2016, . 702 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 703 Signature Algorithm (EdDSA)", RFC 8032, 704 DOI 10.17487/RFC8032, January 2017, 705 . 707 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 708 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 709 May 2017, . 711 [SEC1] SEC, "STANDARDS FOR EFFICIENT CRYPTOGRAPHY, "SEC 1: 712 Elliptic Curve Cryptography", version 2.0", May 2009. 714 8.2. Informative References 716 [cpace_paper] 717 Haase, B. and B. Labrique, "AuCPace. PAKE protocol 718 tailored for the use in the internet of things.", Feb 719 2018. 721 eprint.iacr.org/2018/286 723 [VTBPEKE] Pointcheval, D. and G. Wang, "VTBPEKE: Verifier-based Two- 724 Basis Password ExponentialKey Exchange", 2017. 726 Proceedings of the 2017 {ACM} on Asia Conference on 727 Computer and Communications Security, AsiaCCS 2017 729 Appendix A. CPace25519 Test Vectors 731 The test vectors for CPace25519 consist of three blocks. 733 First test vectors for X25519 are provided which is used as combined 734 scalar multiplication, cofactor clearing and verification function. 735 Specifically, test vectors for the small order points are provided 736 for checking that all small order points are mapped to the neutral 737 element 739 Then test vectors for the Elligator2 primitive are provided. 741 Then test vectors for the encoding of the secret generator are 742 provided combining the hash operation and the encoding of the 743 generator. 745 Finally test vectors for a honest party protocol execution are 746 provided, including derivation of the session key ISK. 748 A.1. X25519 test vectors 749 ########################### /X25519 ############################### 750 Test vectors for X25519 include three values: 751 - The scalar encoding prior to co-factor clearing and clamping, s 752 - The little-endian byte string encoding of the input point, u 753 - The expected little-endian byte string encoding of the result, r 755 Test vector for X25519 with a coordinate on J: 756 s: a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4 757 u: e6db6867583030db3594c1a424b15f7c726624ec26b3353b10a903a6d0ab1c4c 758 r: c3da55379de9c6908e94ea4df28d084f32eccf03491c71f754b4075577a28552 760 Test vector for X25519 with a coordinate on the twist J': 761 s: 4b66e9d4d1b4673c5ad22691957d6af5c11b6421e0ea01d42ca4169e7918ba0d 762 u: e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a413 763 r: 95cbde9476e8907d7aade45cb4b873f88b595a68799fa152e6f8f7647aac7957 765 Test vectors for X25519 with coordinates on J and J' that MUST all 766 yield the neutral element (0) independent of s: 768 s: a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4 770 u: 0000000000000000000000000000000000000000000000000000000000000000 771 u: 0100000000000000000000000000000000000000000000000000000000000000 772 u: e0eb7a7c3b41b8ae1656e3faf19fc46ada098deb9c32b1fd866205165f49b800 773 u: 5f9c95bca3508c24b1d0b1559c83ef5b04445cc4581c8e86d8224eddd09f1157 774 u: ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f 775 u: edffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f 776 u: eeffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f 777 u: cdeb7a7c3b41b8ae1656e3faf19fc46ada098deb9c32b1fd866205165f49b880 778 u: 4c9c95bca3508c24b1d0b1559c83ef5b04445cc4581c8e86d8224eddd09f11d7 779 u: d9ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 780 u: daffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 781 u: dbffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 783 r: 0000000000000000000000000000000000000000000000000000000000000000 785 ########################### X25519/ ############################### 787 A.2. Elligator2 test vectors 789 Two test vectors are provided 790 #################### /Elligator 2 ################################## 792 Vector set 1 as little endian byte strings: 793 in: bc149a46d293b0aeea34581349d72f8a5a96cd531102d67379cd9bfadd4ec800 794 out:66b68f7575cd282403fc2bd323ff04601203c1ec5516ce247f7c0adbef05d367 796 Vector set 1 as base 10 numbers: 797 in: 35391373371110637358764021258915994089392966 798 2186061014226937583985831318716 799 out: 46961069109971370193035504450677895166687682 800 601074157241352710439876254742118 802 #################################################################### 804 Vector set 2 as little endian byte strings: 805 in: 89cf55d4b5d3f84b1634957ac503a32b84ba11471a96b227bca70a0c3bf26375 806 out:1db163c86ceca7621903c9412d6dc71b4ed263b687eed092b194b5e540bba308 808 Vector set 2 as base 10 numbers: 810 in: 530971929581761349677698694411105058011053992421528586742712709 811 85522606362505 812 out: 390779123641965710057372702362153599533842156764537839663973068 813 2305857171741 815 #################### Elligator 2/ ################################## 817 A.3. Test vectors for the secret generator G 818 ###################### /Secret generator G ######################### 819 Inputs: 820 DSI1 = 'CPace25519-1' 821 PRS = 'password' 822 sid = SHA512('sid'), bytes 0 to 15 823 A = 'Ainitiator' 824 B = 'Bresponder' 825 AD = 'AD' 826 #################################################################### 827 Outputs and intermediate results: 829 DSI1 = 435061636532353531392d31 string ('CPace25519-1') of len(12) 830 PRS = 70617373776f7264 ('password') string of len(8) 831 ZPAD = 98 zero bytes (before mixing in variable data) 832 sid = 7e4b4791d6a8ef019b936c79fb7f2c57 string of len(16) 833 CI = 41696e69746961746f7242726573706f6e6465724144 834 ('AinitiatorBresponderAD') string of len(22) 836 u = SHA512(DSI1||PRS||ZPAD||sid||CI) as 512 bit little-endian int: 837 (0xced4bf3254970eaec9f304ed422d8fde59e8c4abb0a27c675b4820a0c2c8fd92 838 << 256) 839 + 0x6dd2899f728ed1620e01e3d7fb9f5cd86e06ee4b5d552bde1524e0cb1e9344e0 840 u as reduced base field element coordinate: 841 0x2166eb1800faff5408149f0fce62b7d9c6941fc79573a335a1d9b8a80868ed26 842 u encoded as little endian byte string: 843 26ed6808a8b8d9a135a37395c71f94c6d9b762ce0f9f140854fffa0018eb6621 845 Elligator2 output G as base field element coordinate: 846 0x307760941be97d7c68b037cb9d22d69838b60e194c50ded8b85873f9e1395126 847 Elligator2 output G encoded as little endian byte string: 848 265139e1f97358b8d8de504c190eb63898d6229dcb37b0687c7de91b94607730 850 ###################### Secret generator G/ ######################### 852 A.4. Test vectors for CPace DH 853 ##################### /CPace Diffie-Hellman ######################## 854 Inputs: 856 Elligator2 output G as base field element coordinate: 857 0x307760941be97d7c68b037cb9d22d69838b60e194c50ded8b85873f9e1395126 858 Elligator2 output G encoded as little endian byte string: 859 265139e1f97358b8d8de504c190eb63898d6229dcb37b0687c7de91b94607730 861 Secret scalar ya=SHA512('ya'), bytes 0...31, as integer: 862 0xbfec93334144994275a3eba9eb0adf3fe40d54e400d105d59724bee398b722d1 863 ya encoded as little endian byte string: 864 d122b798e3be2497d505d100e4540de43fdf0aeba9eba375429944413393ecbf 866 Secret scalar yb=SHA512('yb'), bytes 0...31, as integer: 867 0xb16a6ff3fcaf874cb59058493cb1f28b3e20084ad6d46fcd3c053284d60cecc0 868 yb encoded as little endian byte string: 869 c0ec0cd68432053ccd6fd4d64a08203e8bf2b13c495890b54c87affcf36f6ab1 871 #################################################################### 872 Outputs: 874 Public point Ya as integer: 875 0x79f9f2c1245fd8c4ab38bc75082f2daf6f47ca53fd5f0de7af72fee9c7ddd993 876 Ya encoded as little endian byte string: 877 93d9ddc7e9fe72afe70d5ffd53ca476faf2d2f0875bc38abc4d85f24c1f2f979 879 Public point Yb as integer: 880 0x18ac9063b4419695db48028d2eda7b2b2e649d22f56a5987eba9f05941de1c74 881 Yb encoded as little endian byte string: 882 741cde4159f0a9eb87596af5229d642e2b7bda2e8d0248db959641b46390ac18 884 DH point K as integer: 885 0x276896a227a09f389a04b9656099aa05ef8ec2b394cf32cc50cca9ae56334215 886 K encoded as little endian byte string: 887 15423356aea9cc50cc32cf94b3c28eef05aa996065b9049a389fa027a2966827 889 ##################### CPace Diffie-Hellman/ ######################## 891 A.5. Test vectors for intermediate session key generation 892 #################### /Session Key derivation ####################### 893 Inputs: 895 DSI2 = 435061636532353531392d32 string ('CPace25519-2') of len(12) 896 sid = 7e4b4791d6a8ef019b936c79fb7f2c57 string of len(16) 898 strings of length 32: 899 K = 15423356aea9cc50cc32cf94b3c28eef05aa996065b9049a389fa027a2966827 900 Ya= 93d9ddc7e9fe72afe70d5ffd53ca476faf2d2f0875bc38abc4d85f24c1f2f979 901 Yb= 741cde4159f0a9eb87596af5229d642e2b7bda2e8d0248db959641b46390ac18 903 #################################################################### 905 string of length 64: 906 ISK = SHA512(DSI2 || sid || K || Ya || Yb) 907 = de0be1eeb7e6453d8c961353cd333694866f5432f24b0d4ed393cb6473e835df 908 265ce72613effa3368a907031d897c733d300dfdb364ff66d270b404cdfbcb0a 910 #################### Session Key derivation/ ####################### 912 Authors' Addresses 914 Michel Abdalla 915 DI, Ecole Normale Superieure, Paris 917 Email: michel.abdalla@ens.fr 919 Bjoern Haase 920 Endress + Hauser Liquid Analysis 922 Email: bjoern.m.haase@web.de 924 Julia Hesse 925 IBM, Zuerich Research Laboratory 927 Email: JHS@zurich.ibm.com