idnits 2.17.1 draft-haase-aucpace-01.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 (February 7, 2020) is 1530 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 B. Haase 3 Internet-Draft Endress + Hauser Liquid Analysis 4 Intended status: Informational February 7, 2020 5 Expires: August 10, 2020 7 (strong) AuCPace, an augmented PAKE 8 draft-haase-aucpace-01 10 Abstract 12 This document describes AuCPace which is an augmented PAKE protocol 13 for two parties. The protocol was tailored for constrained devices 14 and smooth migration for compatibility with legacy user credential 15 databases. It is designed to be compatible with any group of both 16 prime- and non-prime order and comes with a security proof providing 17 composability guarantees. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 10, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 55 3. Definitions for AuCPace . . . . . . . . . . . . . . . . . . . 3 56 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Access to server-side password verifiers databases . . . . . 7 58 4.1. User credential database and password verifier types . . 7 59 4.2. Encoding of passwords and user names . . . . . . . . . . 8 60 4.3. AuCPace database interface for retrieving password 61 verifiers . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.4. Derivation of the salt value for strong AuCPace . . . . . 9 63 4.5. Specification of the workload parameter sigma . . . . . . 10 64 4.6. Result of the database parameter lookup . . . . . . . . . 10 65 5. Authentication session . . . . . . . . . . . . . . . . . . . 11 66 5.1. Authentication Protocol Flow . . . . . . . . . . . . . . 11 67 5.2. AuCPace . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 6. Authentication of transactions . . . . . . . . . . . . . . . 14 69 6.1. Transaction Protocol Flow . . . . . . . . . . . . . . . . 14 70 6.2. AuCPace authenticated transactions . . . . . . . . . . . 15 71 7. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 15 72 7.1. CPACE-X25519-ELLIGATOR2_SHA512-SHA512 . . . . . . . . . . 16 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 78 11.2. Informative References . . . . . . . . . . . . . . . . . 23 79 Appendix A. AuCPace25519 Test Vectors . . . . . . . . . . . . . 23 80 A.1. Inverse X25519 test vectors . . . . . . . . . . . . . . . 23 81 A.2. Strong AuCPace25519 salt test vectors . . . . . . . . . . 24 82 A.3. Test vectors for AuCPace password verifier . . . . . . . 25 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 85 1. Introduction 87 This document describes AuCPace which is an augmented password- 88 authenticated key-establishment (PAKE) protocol for two parties. 89 Both sides the client B and the server A establish a high-entropy 90 session key SK, based on a secret (password) which may be of low 91 entropy for the client B and a password-verifier stored on the 92 server. The protocol is designed such that disclosing the secret to 93 offline dictionary attacks is prevented. Upon server compromise 94 (stealing A's database), the adversary must first succeed with a 95 dictionary search for the clear-text password before being able to 96 impersonate the client. 98 The protocol was tailored for constrained server devices. 99 Specifically, the computationally complex password hash operation is 100 refered to the clients. AuCPace is also designed for enabling a 101 smooth migration of legacy user credential databases. 103 AuCPace is designed to be compatible with any group of both prime- 104 and non-prime order and comes with a security proof providing 105 composability guarantees. AuCPace uses CPace as a building block 106 which is described in a separate internet draft document. 108 2. Requirements Notation 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. Definitions for AuCPace 118 3.1. Setup 120 Let C be a group in which there exists a subgroup of prime order p 121 where the computational simultaneous Diffie-Hellman (SDH) problem is 122 hard. C has order p*c where p is a large prime; c will be called the 123 cofactor. Let I be the unit element in C, e.g., the point at 124 infinity in if C is an elliptic curve group. We denote the 125 operations in the group using addition and multiplication operators, 126 e.g. P + (P + P) = P + 2 * P = 3 * P. We refer to a sequence of n 127 additions of an element in P as scalar multiplication by n. With B 128 we denote a generator of the prime-order subgroup in C that we call 129 the base point. 131 With F we denote a field that may be associated with C, e.g. the 132 prime base field used for representing the coordinates of points on 133 an elliptic curve. 135 We assume that for any element P in C there is a representation 136 modulo negation, encode_group_element_mod_neg(P) as a byte string 137 such that for any Q in C with Q != P and Q != -P, 138 encode_group_element_mod_neg(P) != encode_group_element_mod_neg(Q). 139 It is recommended that encodings of the elements P and -P share the 140 same result string. Common choices would be a fixed (per-group) 141 length encoding of the x-coordinate of points on an elliptic curve C 142 or its twist C' in Weierstrass form, e.g. according to [IEEE1363] in 143 case of short Weierstrass form curves. For curves in Montgomery form 144 correspondingly the u-coordinate would be encoded, as specified, 145 e.g., by the encodeUCoordinate function from [RFC7748]. 147 With J we denote the group modulo negation associated to C. Note 148 that in J the scalar multiplication operation is well defined since 149 scalar_multiply(P,s) == -scalar_multiply(-P,s) while arbitrary 150 additions of group elements are no longer available. 152 With J' be denote a second group modulo negation that might share the 153 byte-string encoding function encode_group_element_mod_neg with J 154 such for a given byte string either an element in J or J' is encoded. 155 If the x-coordinate of an elliptic curve point group is used for the 156 encoding, J' would commonly be corresponding to the group of points 157 on the elliptic curve's quadratic twist. Correspondingly, with p' we 158 denote the largest prime factor of the order of J' and its cofactor 159 with c'. 161 Let scalar_cofactor_clearing(s) be a cofactor clearing function 162 taking an integer input argument and returning an integer as result. 163 For any s, scalar_cofactor_clearing(s) is REQUIRED to be of the form 164 c * s1. I.e. it MUST return a multiple of the cofactor. An example 165 of such a function may be the cofactor clearing and clamping 166 functions decodeScalar25519 and decodeScalar448 as used in the X25519 167 and X448 protocols definitions of [RFC7748]. In case of prime-order 168 groups with c == 1, it is RECOMMENDED to use the identity function 169 with scalar_cofactor_clearing(s) = s. 171 Let scalar_mult_cc(P,s) be a joint "scalar multiplication and 172 cofactor clearing" function of an integer s and an string-encoded 173 value P, where P could represent an element either on J or J'. If P 174 is an element in J or J', the scalar_mult_cc function returns a 175 string encoding of an element in J or J' respectively, such that the 176 result of scalar_mult_cc(P,s) encodes (scalar_cofactor_clearing(s) * 177 P). 179 Let si = invert_scalar_mult_cc(P,s) be a function such that for any 180 point Z in the prime-order subgroup of J, 181 invert_scalar_mult_cc(scalar_mult_cc(Q,s),s) == Q. A typical 182 implemention will involve calculating the inverse in the prime field 183 mod p on the scalar generated by scalar_cofactor_clearing(s). 185 Let scalar_mult_ccv(P,s) be a "scalar multiplication cofactor 186 clearing and verify" function of an integer s and an encoding of a 187 group element P. Unlike scalar_mult_cc, scalar_mult_ccv additionally 188 carries out a verification that checks that the computational 189 simultaneous Diffie-Hellman problem (SDH) is hard in the subgroup (in 190 J or J') generated by the encoded element SP = scalar_mult_cc(P,s). 192 In case that the verification fails (SP might be of low order or on 193 the wrong curve), scalar_mult_ccv is REQUIRED to return the encoding 194 of the identity element I. Otherwise scalar_mult_ccv(P,S) is 195 REQUIRED to return the result of scalar_mult_cc(P,s). A common 196 choice for scalar_mult_ccv for Montgomery curves with twist security 197 would be the X25519 and X448 Diffie-Hellman functions as specified in 198 [RFC7748]. For curves in short Weierstrass form, scalar_mult_ccv 199 could be implemented by the combination of a point verification of 200 the input point with a scalar multiplication. Here scalar_mult_ccv 201 SHALL return the encoding of the neutral element I if the input point 202 P was not on the curve C. 204 Let P=map_to_group_mod_neg(r) be a mapping operation that maps a 205 string r to an encoding of an element P in J. Common choices would 206 be the combination of map_to_base and map_to_curve methods as defined 207 in the hash2curve draft [HASH2CURVE]. Note that we don't require and 208 RECOMMEND cofactor clearing here since this complexity is already 209 included in the definition of the scalar multiplication operation 210 calar_mult_cc above. Additionally requiring cofactor clearing also 211 in map_to_group_mod_neg() would result in efficiency loss. 213 || denotes concatenation of strings. We also let len(S) denote the 214 length of a string in bytes. Finally, let nil represent an empty 215 string, i.e., len(nil) = 0. 217 [f,g,h] denotes alternatives where exactly one of the comma-separated 218 options is to be chosen. 220 Let H(m) be a hash function from arbitrary strings m to bit strings 221 of a fixed length. Common choices for H are SHA256 or SHA512 222 [RFC6234]. H is assumed to segment messages m into blocks m_i of 223 byte length H_block. E.g. the blocks used in SHA512 have a size of 224 128 bytes. 226 Let strip_sign_information(P) be function that takes a string 227 encoding of an element P in J and strips any information regarding 228 the sign of P, such that strip_sign_information(P) = 229 strip_sign_information(-P). For short Weierstrass (Montgomery) 230 curves this function will return a string encoding the x-coordinate. 231 The purpose of defining this function is for allowing for 232 x-coordinate only scalar multiplication algorithms. The sign is to 233 be stripped before generating the intermediate session key ISK. 235 With ISK we denote the intermediate session key output string 236 provided by CPace that is generated by a hash operation on the 237 Diffie-Hellman result. 239 MAC(msg,key) is a message authentication code. Common examples are 240 HMAC_SHA512, a block cipher based MAC or a hash-function based tag. 242 AEAD(msg,key) is used for denoting an authenticated encryption 243 scheme. A common example would be AES128GCM or Salsa20Poly1305. 245 KDF(Q) is a key-derivation function that takes a string and derives 246 key of length L. Common choices for KDF are HMAC_SHA512. 248 With DSI we denote domain-separation identifier strings that may be 249 prepended to the inputs of Hash and KDF functions. 251 Let IHF(salt, username, pw, sigma) be an iterated hash function that 252 takes a salt value, a user name and a password as input. IHF is 253 designed to slow down brute-force attackers as controlled by a 254 workload parameter set sigma. State of the art iterated hash 255 functions are designed for requiring a large amount of memory for its 256 operation and will be referred to as memory-hard hash functions 257 (MHF). Scrypt [RFC7914] or Argon2 are common examples of a MHF 258 primitive. 260 With PRS we denote a string that is a required input of the CPace 261 subprotocol and generated by the AuCPace protocol. 263 Let A and B be two parties. A and B may also have digital 264 representations of the parties' identities such as Media Access 265 Control addresses or other names (hostnames, usernames, etc). We 266 denote the parties' representation and the parties themselves both by 267 using the identifiers A and B. 269 With CI we denote a string that is a required input of the CPace 270 subprotocol. CI is generated together with PRS by the AuCPace 271 augmentation layer. CI SHALL be formed by the concatenation of the 272 identifiers A and B and an associated data string AD, CI = A || B || 273 AD; 275 With uad we denote an optional string that is specifying user- 276 associated data in a password file entry, such as authorization 277 rights or permissions or account expiration dates. Specification of 278 this string is outside of the scope of the AuCPace protocol. 280 Let sid be a session id byte string chosen for each protocol session 281 before protocol execution; The length len(sid) SHOULD be larger or 282 equal to 16 bytes. 284 4. Access to server-side password verifiers databases 286 AuCPace is an asymmetric PAKE protocol. I.e. while one party, the 287 client B, is in possession of a clear-text password pw, the other 288 party, the server A, is not given access to the cleartext password 289 but only to a password verifier. The way how such a password 290 verifier is maintained by a server party is essential for the AuCPace 291 protocol construction. 293 4.1. User credential database and password verifier types 295 With respect to the use of user credantial databases, AuCPace is 296 flexible and supports three different database types. 298 Firstly, the conventional approach as used for logins without a PAKE 299 protocol is supported (as used e.g. for the password over https:/ 300 approach). Here the server stores a tuple of four elements in his 301 password database file, (username, uad, salt, w) with w = 302 IHF(username,pw,salt)). With uad, we denote user-accociated data 303 such as permissions. The salt value is a nonce used for the IHF 304 function. Upon a login request, the user transmits the username and 305 the clear-text password pw to the server. The server looks up the 306 database, retrieves the salt value, calculates the IHF function with 307 the given inputs and compares the result with the registered password 308 verifier w. We refer to this setting as "legacy password verifier 309 database" (LPVD) setting. 311 Secondly, AuCPace supports an AuCPace password verifier database 312 setting (APVD) setting. Here the database is already adapted for use 313 in conjunction with AuCPace. This setting differs from LPVD by the 314 fact that instead of the direct output of the IHF, w = 315 IHF(username,pw,salt), an AuCPace password verifier W is maintained 316 in the database. W is calculated from the legacy-style value w by W 317 = scalar_mult_cc(B,w). It is possible to calculate W from a LPVD 318 entry on the fly and without knowledge of the clear-text password 319 upon a remote login request. It is also easily possible to migrate 320 the format of a LPVD database to an APVD database by calling the 321 scalar multiplication function for each entry. 323 Thirdly, AuCPace supports the *strong* AuCPace password verifier 324 database setting (sAPVD) setting, which differs from APVD and LPVD by 325 the fact that the salt entry in the database, as used for the IHF, is 326 replaced by a salt-derivation parameter q, as will be detailed below. 327 With this strong AuCPace verifier type, the AuCPace protocol provides 328 the additional security guarantee of pre-computation attack 329 resistance. Note that migrating LPVD or APVD database records to 330 sAPVD entries is *not* possible, because calculating the strong sAPVD 331 password verifiers requires the clear-text passwords. 333 4.2. Encoding of passwords and user names 335 For AuCPace usernames and passwords are encoded as strings according 336 to the definitions of [RFC8265], i.e. case-preserving unicode 337 encoding SHALL be employed. 339 4.3. AuCPace database interface for retrieving password verifiers 341 In the course of the authentication protocoll, the AuCPace server 342 implementation will need to interface to an user credential database 343 for retrieving password verifiers. 345 Database lookup is implemented by use of string-encoded user names. 346 AuCPace needs an interface equivalent to a function pvr = 347 lookup_pw_verifier_record(username). I.e. a lookup returns a 348 password verfier record pvr, based on a username string. It is 349 REQUIRED that for the purpose of pvr record lookup in databases and 350 for the database contents, the "case preservation" according to 351 [RFC8265] is employed, both for the string encoding of the username 352 and the password. 354 The content in the pvr records will depend on the application 355 scenarios, LPVD, APVD and sAPVD as defined above. Password verifier 356 records pvr as returned from the database are REQUIRED to be composed 357 of the following components. 359 A password verifier from either one of the following two options 360 (w or W). 362 LPVD case: A binary encoding of the actual password verifier 363 that has been calculated as a function of the username, the 364 password, a salt value by use of an iterated hash function pv = 365 w = IHF(username,password,salt, sigma). 367 APVD and sAPVD cases: An encoding of an element in J, W = 368 scalarmult_cc(B,w), which has been calculated by a scalar 369 multiplication using the base point B. The secret scalar, w, 370 has been calculated by an iterated hash function just as in the 371 case above, w = IHF(username,password,salt, sigma). 373 sigma, a binary encoding specifying the type and the workload 374 parametrization of the iterated hash function IHF that has been 375 used for calculating w or W. 377 A salt derivation entry which is either 379 LPVD and APVD cases: a binary string encoding of the salt value 380 itself or, 381 sAPVD case: an encoding of a secret scalar q for a group scalar 382 multiplication such that the salt value used for calculating w 383 or W could be calculated from the tuple salt = 384 strong_AuCPace_salt_derivation(q,username,password). 386 In case that a database lookup on a server yields a legacy password 387 database record (LPVD case that includes an entry w), the AuCPace 388 implementation SHALL convert this record into a AuCPace database 389 record (APVD case) by replacing w with W=scalarmult_cc(B,w). 391 The AuCPace application protocol, thus, only needs to consider the 392 two different APVD and sAPVD scenarios. In case of the APVD 393 scenario, the salt value used for the IHF execution is returned by 394 the database lookup, while in the sAPVD case the salt value is 395 replaced by the secret scalar. 397 4.4. Derivation of the salt value for strong AuCPace 399 For strong AuCPace the salt value used for the IHF is not explicitly 400 included in the password verifier record pvr. Instead only the 401 parameter q is stored. q serves for deriving the salt value. In 402 order to determine the salt value, strong AuCPace uses a function 403 salt = strong_AuCPace_salt_derivation(q,username,password). This 404 function implements the following sequence of operations. 406 First Z, an element in J, is calculated by use of a Z = 407 map_username_password_to_J(username || password). function, e.g. 408 by use of a hash function such as SHA512 and a mapping such as 409 Elligator2. 411 The salt value is then determined by applying the scalar q and the 412 group element Z to the scalar multiplication function, salt = 413 strip_sign_information(scalarmult_cc(Z,q)). 415 Deriving the salt value, thus, requires access to all of, username, 416 clear text password and secret key q. If the database is stolen, an 417 adversary is not able to derive the salt value without having access 418 to the clear-text password. 420 Note that the method above which derives the salt directly from Z and 421 q will typically only be used when creating a new password database 422 entry. The AuCPace protocol uses a secret scalar r for, masking the 423 value of Z. The approach exploits the relation q * Z == ((Z * r) * 424 q) * (1/r). More explicitly the sequence is as follows: 426 The client, B, having access to the username and the clear-text 427 password calculates Z. It aims at deriving the salt value. 429 B samples a fresh scalar r and calculates U = scalarmult_cc(Z,r). 430 B sends U to A. 432 A fetches q from the database and calculates UQ = 433 scalarmult_cc(U,q). A sends UQ back to A. 435 B retrieves the salt by inverting the blinding with the scalar r 436 using salt = 437 strip_sign_information(invert_cofactor_cleared_scalar(UQ,r)). 439 4.5. Specification of the workload parameter sigma 441 AuCPace does not require the use of a specific iterated hash function 442 IHF. Still it is strongly RECOMMENDED to use AuCPace in conjunction 443 with state-of-the art memory-hard hash functions MHF with a secure 444 workload parametrization. The workload parameter sigma shall encode 445 all of the following. 447 The algorithm family, such as Argon2i, scrypt or PBKDF2-HMAC- 448 SHA256. 450 The workload parameter specification, e.g. the iteration count for 451 PBKDF2 or the parameters N,r and p of the scrypt algorithm. 453 4.6. Result of the database parameter lookup 455 Summing up, the lookup process for user credential data for AuCPace 456 SHALL provide all of the following information in the course of the 457 session establishment protocol. 459 The iterated hash function specification sigma. 461 A salt-derivation parameter and its type. The salt derivationn 462 parameter is either a salt scalar q or the salt value itself. 463 Correspondingly the type of the salt-derivation parameter is 464 either "AuCPace" or "strong AuCPace". 466 An AuCPace password verifier W = 467 scalarmult_cc(B,IHF(pwd,username,salt)). 469 For handling the case of failed lookups, if a given user name does 470 not have an entry, the database shall define a default parameter set 471 sigma_default and a default salt-derivation parameter for password 472 hashing. Moreover and a secret string database_seed shall be chosen 473 specifically for each distinct server A. In case of failed lookups 474 the following procedure SHALL be used. A random value w shall be 475 sampled. The password verifier W shall be calculated as W = 476 map_to_group(w). The parameters q or salt shall be respectively 477 calculated as [q,salt] = H(name || database_seed). 479 5. Authentication session 481 5.1. Authentication Protocol Flow 483 AuCPace is a protocol run between two parties, A and B, for 484 establishing a shared secret key with explicit mutual authentication. 485 AuCPace is implemented by four messages as indicated by the numbers 486 in the figure below. The roles of the two parties are different. 487 Party B, the client, is provided a user name and a password as input. 488 Party A, the server, has access to a user credentials database that 489 stores password verifiers. Both parties share a channel identifier 490 string CI characterizing the communication channel (e.g. information 491 on IP addresses and port numbers of both sides). 493 The channel identifier, CI, SHOULD include an encoding of the 494 identities of both parties A and B if these are available prior to 495 starting the communication protocol. 497 Both sides also share a common subsession ID (ssid) string. ssid 498 could be pre-established by a higher-level protocol invocing AuCPace. 499 If no such ssid is available from a higher-level protocol, a suitable 500 approach is including ssid in the first message from B to A as shown 501 in the figure below. 503 A B 504 | ssid | 505 |<1----------------| (sample ssid) 507 ---------- AuCPace protocol ----------- 508 In: ssid | | In: name, passw. 509 | name,U | ssid 510 |<1----------------| 511 DB lookup | | 512 |[UQ,salt],X,sigma | 513 det. CI,PRS |----------------2>| det. CI,PRS 514 --------------------------------------- 515 In: CI, PRS, || (CPace substep) || In: CI, PRS, 516 ssid || || ssid 517 || Ya || 518 ||----------------2>|| 519 || Yb || 520 Output: ISK ||<3----------------|| Output: ISK 521 --------------------------------------- 522 expl.auth. | Tb | expl.auth. 523 |<3----------------| 524 | Ta | 525 |----------------4>| 526 Output: SK | | Output: SK 528 5.2. AuCPace 530 Both parties start with agreed values on the ssid string. The server 531 side has access to a user credentials database. The client side 532 holds a user name, a clear-text password to be used for the 533 authentication session. Both sides share an encoding CI specifying 534 the communication channel, such as IP addresses and port numbers. 536 To begin, B calculates an element Z = 537 map_username_password_to_J(username || password) in J. 539 B then picks r randomly and uniformly according to the requirements 540 for group J scalars and calculates U = scalar_mult_cc(Z,r). 542 B then sends (name,U) to A. 544 A then queries its database for the user name and retrieves the 545 information as specified in section Section 4.6 , i.e. the set 546 (W,sigma,salt-derivation parameter [q,salt]). (Note that according 547 to the specification of the database lookup, such a set is provided, 548 even if there is no database entry for the given user name.) 549 A picks x randomly and uniformly according to the requirements for 550 group J scalaras and calculates X = scalarmult_cc(B,x) and WX = 551 scalarmult_ccv(W,x). A MUST abort if WX is the neutral element (this 552 indicates an error in the database contents). 554 A strips the sign information from WX to obtain WXs. A picks ya 555 randomly and uniformly. A then calculates G = 556 map_to_group_mod_neg(DSI1 || WXs || ZPAD || ssid || CI) and Ya = 557 scalar_mult_cc(G,ya). I.e. WXs takes over the role of CPace's PRS 558 string. 560 The following operations will variate, depending on the type of salt- 561 derivation entry in the database. 563 If the salt derivation parameter is for strong AuCPace, A 564 calculates UQ = scalarmult_cc(U,q) and sends (UQ,X,sigma,Ya) to B. 565 B then calculates salt as salt = 566 strip_sign_information(inverse_scalarmult_cc(UQ,r)). 568 If the salt derivation parameter is for AuCPace, A sends 569 (salt,X,sigma,Ya) to B. 571 B then calculates w = IHF(sigma,username,password, salt) and XW = 572 scalarmult_ccv(X,w). B MUST abort, if XW is the neutral element I. 574 B strips the sign information from XW to obtain XWs. B picks yb 575 randomly and uniformly. B then calculates G = 576 map_to_group_mod_neg(DSI1 || XWs || ZPAD || ssid || CI) and Yb = 577 scalar_mult_cc(G,yb). B then calculates K = scalar_mult_ccv(Ya,yb). 578 B MUST abort if K is the encoding of the neutral element I. 579 Otherwise B sends Yb to A and proceeds as follows. B strips the sign 580 information from K, Ya and Yb to obtain the strings Ks, Yas and Ybs 581 by using the strip_sign_information() function. B calculates ISK = 582 H(DSI2 || ssid || Ks || Yas || Ybs). 584 B calculates Tb = MAC(ISK,DSI4) and Ta_v = MAC(ISK,DSI3) and sends 585 (Yb,Tb) to A. 587 Upon reception of Yb, A calculates K = scalar_mult_ccv(Yb,ya). A 588 MUST abort if K is the neutral element I. If K is different from I, 589 A strips the sign information from K, Ya and Yb and calculates ISK = 590 H(DSI2 || ssid || Ks || Yas || Ybs). 592 A calculates Tb_v = MAC(ISK,DSI4) and Ta = MAC(ISK,DSI3). If the 593 received authentication tag Tb did not match the verification value 594 Tb_v A MUST abort. Otherwise A sends Ta to B and returns the session 595 key SK = KDF(DSI5 || ISK || ssid). 597 When B receives T_a it compares this to the verification value Ta_v. 598 B MUST abort if Ta != Ta_v. Otherwise B returns the session key SK = 599 KDF(DSI5 || ISK || ssid). 601 Upon completion of this protocol, the session key SK returned by A 602 and B will be identical by both parties if and only if the supplied 603 input parameters ssid and CI match on both sides and the password 604 verifier in the server database for the user was calculated from the 605 clear-text password used by B. 607 6. Authentication of transactions 609 The AuCPace protocol could also be used for interactive 610 "transactions" that require explicit authentication by use of a 611 password. One example of such a transaction is the request for 612 change of the user's password verifier which involves two components. 613 Firstly, verification of the transaction with the old password and, 614 secondly, the transfer of a payload MT containing a new password 615 verifier for the database. 617 Another example would be transactions that require special privileges 618 and need explicit password-based authentication (e.g. as in "sudo" 619 commands on unix operating systems). 621 The common feature of such transactions is the confidential transfer 622 of a transaction payload MT from the client to the server and the 623 authentication of the transaction based on proven knowledge of a 624 password. Upon sucessful authentication, the transaction as 625 specified by MT is processed and a response MR is generated. The 626 server then transfers MR to the client by use of an AEAD scheme. 628 6.1. Transaction Protocol Flow 630 The protocol flow corresponds to the session key generation above 631 with the difference that the authenticator messages Ta and Tb are 632 replaced by two transaction messages TMa and TMb. 634 Before starting the protocol, the client has setup a transaction 635 message MT. 637 As above, the channel identifier, CI, SHOULD include an encoding of 638 the identities of both parties A and B if these are available prior 639 to starting the communication protocol. 641 Both sides also share a common subsession ID (ssid) string. ssid 642 could be pre-established by a higher-level protocol invocing AuCPace. 643 If no such ssid is available from a higher-level protocol, a suitable 644 approach is including ssid in the first message from B to A as shown 645 in the figure below. 647 A B 648 | ssid | 649 |<1----------------| (sample ssid) 651 ---------- AuCPace protocol ----------- 652 In: ssid | | In: name, passw. 653 | name,U | ssid, MT 654 |<1----------------| 655 DB lookup | | 656 |[UQ,salt],X,sigma | 657 det. CI,PRS |----------------2>| det. CI,PRS 658 --------------------------------------- 659 In: CI, PRS, || (CPace substep) || In: CI, PRS, 660 ssid || || ssid 661 || Ya || 662 ||----------------2>|| 663 || Yb || 664 Output: ISK ||<3----------------|| Output: ISK 665 --------------------------------------- 666 expl.auth. | TMb | expl.auth. 667 |<3----------------| 668 process TMb | TMa | 669 |----------------4>| 670 | | process TMa 672 6.2. AuCPace authenticated transactions 674 The protocol flow is identical to the case of session key generation 675 except for the fact that the authenticators Ta and Tb are replaced by 676 TMa and TMb. TMa is generated by TMb = AEAD(MT,ISK), i.e. the 677 payload MT is encrypted and authenticated by use of ISK. If 678 verification of the authentication tag of TMb succeeds on the server 679 the transaction message is decrypted and executed. E.g. upon a 680 password change transaction message, the new password verifier would 681 be written to the database of the server. The result of the 682 transaction execution is encoded in a response message MR and TMa is 683 calculated as TMa = AEAD(MR,ISK). The client authenticates TMa and 684 returns the decrypted response message MR upon success. 686 7. Ciphersuites 688 This section documents AuCPace ciphersuite configurations. A 689 ciphersuite is REQUIRED to specify all of, 690 o a group modulo negation J with an associated 691 encode_group_element_mod_neg function 693 o scalar_mult_cc(P,s) and scalar_mult_ccv(P,s) functions operating 694 on encodings of elements P in J 696 o a mapping function map_to_group_mod_neg(r) converting byte strings 697 r into elements in J 699 o a strip_sign_information(Q) function operating on string 700 representations of elements Q 702 o a hash function H for generating the intermediate session key ISK 704 o A message authentication code MAC for authentication tag 705 generation. 707 o A key derivation function KDF for generating the final session key 708 SK 710 o and domain separation strings DSI1, DSI2, DSI3, DSI4, DSI5 712 Currently, detailed specifications are available for CPACE- 713 X25519-ELLIGATOR2_SHA512-SHA512. 715 +--------+----------------------+------------------+ 716 | J | map_to_group_mod_neg | KDF | 717 +--------+----------------------+------------------+ 718 | X25519 | ELLIGATOR2_SHA512 | SHA512 [RFC6234] | 719 +--------+----------------------+------------------+ 721 Table 1: CPace Ciphersuites 723 7.1. CPACE-X25519-ELLIGATOR2_SHA512-SHA512 725 This cipher suite targets particularly constrained targets and 726 implements specific optimizations. It uses the group of points on 727 the Montgomery curve Curve25519 for constructing J. The base field F 728 is the prime field built upon the prime p = 2^255 - 19. The Diffie- 729 Hellmann protocol X25519 and the group are specified in [RFC7748]. 730 The encode_group_element_mod_neg(P) is implemented by the 731 encodeUCoordinate(P) function defined in [RFC7748]. The neutral 732 element I is encoded as a 32 byte zero-filled string. 734 The domain separation strings are defined as DSI1 = "CPace25519-1", 735 DSI2 = "CPace25519-2", DSI3 = "AuCPace25-Ta", DSI4 = "AuCPace25-Tb", 736 DSI5 = "AuCPace25519". (ASCII encoding without ANSI-C style trailing 737 zeros). 739 Both, scalar_mult_cc and scalar_mult_ccv, are implemented by the 740 X25519 function specified in [RFC7748]. 742 The secret scalars ya and yb used for X25519 shall be sampled as 743 uniformly distributed 32 byte strings. 745 The QI = inverse_scalarmult_cc(Q,s) function is implemented as 746 follows. 748 cs = scalar_cofactor_clearing(s) 750 csi = 1 / (8 * cs) % p. 752 QI = UNCLAMPED_X25519(Q, 8 * si). 754 Where the unclamped X25519 function ommits the setting of bit #254 in 755 the scalar from [RFC7748]. 757 The map_to_group_mod_neg function for the CPace substep is 758 implemented as follows. First the byte length of the ZPAD zero- 759 padding string is determined such that len(ZPAD) = max(0, 760 H_block_SHA512 - len(DSI1 || PRS)), with H_block_SHA512 = 128 bytes. 761 Then a byte string u is calculated by use of u = 762 SHA512(DSI1||PRS||ZPAD||sid||CI). The resulting string is 763 interpreted as 512-bit integer in little-endian format according to 764 the definition of decodeLittleEndian() from [RFC7748]. The resulting 765 integer is then reduced to the base field as input to the Elligator2 766 map specified in [HASH2CURVE] to yield the secret generator G = 767 Elligator2(u). 769 The map_to_group_mod_neg function used for the strong AuCPace substep 770 for calculating the field element Z is implemented accordingly. 771 First the byte length of the ZPAD zero-padding string is determined 772 such that len(ZPAD) = max(0, H_block_SHA512 - len(DSI5 || password)), 773 with H_block_SHA512 = 128 bytes. Then a byte string u is calculated 774 by use of u = SHA512(DSI5||password||ZPAD||username). The resulting 775 string is interpreted as 512-bit integer in little-endian format 776 according to the definition of decodeLittleEndian() from [RFC7748]. 777 The resulting integer is then reduced to the base field as input to 778 the Elligator2 map specified in [HASH2CURVE] to yield the secret 779 generator Z = Elligator2(u). 781 AuCPace25519 calculates an intermediate session key ISK of 64 bytes 782 length by a single invocation of SHA512(DSI2||ISK). Since the 783 encoding does not incorporate the sign from the very beginning Qs = 784 strip_sign_information(Q) == Q for this cipher suite. 786 AuCPace25519 calculates authentication tags and session key SK from 787 ISK of 64 bytes length by a single invocation of Ta = 788 SHA512(DSI3||ISK), Tb = SHA512(DSI4||ISK) and SK = SHA512(DSI5||ISK). 790 The following sage code could be used as reference implementation for 791 the mapping and key derivation functions. 793 795 def littleEndianStringToInteger(k): 796 bytes = [ord(b) for b in k] 797 return sum((bytes[i] << (8 * i)) for i in range(len(bytes))) 799 def map_to_group_mod_neg_CPace25519(sid, PRS, CI): 800 m = hashlib.sha512() 801 p = 2^255 - 19 803 H_block_SHA512 = 128 804 DSI1 = b"CPace25519-1" 805 ZPAD_len = max(0,H_block_SHA512 - len(CI) - len(PRS)) 806 ZPAD = ZPAD_len * "\0" 808 m.update(DSI1) 809 m.update(PRS) 810 m.update(ZPAD) 811 m.update(sid) 812 m.update(CI) 813 u = littleEndianStringToInteger(m.digest()) 814 return map_to_curve_elligator2_curve25519(u % p) 816 def map_to_group_mod_neg_StrongAuCPace25519(username, password): 817 # Map username and password to field element Z 818 DSI = b"AuCPace25519" 819 F = GF(2^255 - 19) 820 m = hashlib.sha512() 821 H_block_SHA512 = 128 822 ZPAD_len = max(0,H_block_SHA512 - len(DSI) - len(password)) 823 ZPAD = ZPAD_len * "\0" 824 m.update(DSI) 825 m.update(password) 826 m.update(ZPAD) 827 m.update(username) 828 u = littleEndianStringToInteger(m.digest()) 829 u = F(u) 830 Z = map_to_curve_elligator2_curve25519(u) 831 return Z 833 def Inverse_X25519(u_string,scalar_string): 835 OrderSubgroup = 2^252 + 27742317777372353535851937790883648493 836 SF = GF(OrderSubgroup) 837 coFactor = SF(8) 838 scalar = clampScalar25519(scalar_string) 839 inverse_scalar = 1 / (SF(scalar) * coFactor) 840 inverse_scalar_shifted = Integer(inverse_scalar) * 8 841 return X25519(u_string,inverse_scalar_shifted,withClamping=0) 843 def generate_ISK_CPace25519(sid,K,Ya,Yb): 844 m = hashlib.sha512(b"CPace25519-2") 845 m.update(sid) 846 m.update(K) 847 m.update(Ya) 848 m.update(Yb) 849 return m.digest() 851 def MAC_SK_AuCPace25519(ISK): 852 DSI3 = b"AuCPace25-Ta" 853 DSI4 = b"AuCPace25-Tb" 854 DSI5 = b"AuCPace25519" 855 m = hashlib.sha512(DSI3) 856 m.update(ISK) 857 Ta = m.digest() 858 Ta = Ta[:16] 860 m = hashlib.sha512(DSI4) 861 m.update(ISK) 862 Tb = m.digest() 863 Tb = Tb[:16] 865 m = hashlib.sha512(DSI5) 866 m.update(ISK) 867 SK = m.digest() 869 return (Ta,Tb,SK) 871 873 Due to its use in Ed25519 [RFC8032], SHA512 is considered to be the 874 natural hash choice for Curve25519. The 512 bit output of SHA512 875 moreover allows for removing any statistical bias stemming from the 876 non-canonical base field representations, such that the overhead of 877 the HKDF_extract/HKDF_expand sequences from [HASH2CURVE] are 878 considered not necessary (in line with the assessments regarding 879 Curve25519 in [HASH2CURVE]). 881 8. Security Considerations 883 A security proof covering AuCPace is found in [HL18]. 885 Elements received from a peer MUST be checked by a proper 886 implementation of the scalar_mult_ccv method. Failure to properly 887 validate group elements can lead to attacks. The Curve25519-based 888 cipher suite employs the twist security feature of the curve for 889 point validation. As such, it is mandatory to check that all low- 890 order points on both the curve and the twist are mapped on the 891 neutral element by the X25519 function. Corresponding test vectors 892 are provided in the appendix. 894 The choices of random numbers MUST be uniform. Randomly generated 895 values (e.g., ya, r, q and yb) MUST NOT be reused. 897 User credential database lookups for AuCPace might not be executed in 898 non-constant time. In this case, AuCPace does not provide full 899 confidentiality with respect to hiding the presence or abscence of a 900 given user's entry in the database. The fact that in case of 901 abscence of a record random values are provided instead should be 902 considered only a mitigation regarding user-enumeration attacks. 904 If AuCPace is used as a building block of higher-level protocols, it 905 is RECOMMENDED that ssid is generated by the higher-level protocol 906 and passed to AuCPace. It is RECOMMENDED that ssid, is generated by 907 sampling ephemeral random strings. 909 AuCPace generates the session key SK by a hash function operation on 910 the intermediate session key ISK. If SK is possibly to be used for 911 many different sub-protocols and purposes, such as e.g. in TLS1.3, it 912 is RECOMMENDED to apply SK to a stronger KDF function, such as HKDF 913 from [RFC5869]. 915 In case that side-channel attacks are to be considered practical for 916 a given application, it is RECOMMENDED to focus side-channel 917 protections such as masking and redundant execution (faults) on the 918 process of calculating the secret generator G. The most critical 919 aspect to consider is the processing of the first block of the hash 920 that includes the PRS string. The CPace protocol construction 921 considers the fact that side-channel protections of hash functions 922 might be particularly resource hungry. For this reason, AuCPace aims 923 at minimizing the number of hash functions invocations in the 924 specified mapping method. 926 AuCPace is designed also for compatibility with legacy-style user- 927 credential databases which directly store the output of iterated hash 928 functions w = IHF(salt, username, password). If AuCPace is used in 929 this configuration, AuCPace provides only the security guarantees of 930 a balanced PAKE. I.e. in this case, user impersonation attacks 931 become feasible if the user credential database is stolen. It is 932 RECOMMENDED to migrate legacy-style databases to an AuCPace format, 933 by replacing w with W = scalarmult_cc(B,w). 935 It is RECOMMENDED to use password verifiers for "strong AuCPace" on 936 such a migrated database upon user password changes in order to 937 obtain pre-computation attack resistance. 939 AuCPace is proven secure under the hardness of the computational 940 simultaneous Diffie-Hellmann (SDH) problem in the group J as defined 941 in [VTBPEKE]. Still, even for the event that large-scale quantum 942 computers (LSQC) will become available, AuCPace forces an active 943 adversary to solve one CDH per password guess. Using the wording 944 suggested by Steve Tobtu on the CFRG mailing list, AuCPace is 945 "quantum-annoying". For the event that LSQC become ubiquitous, it is 946 suggested to consider the replacement of the group operations used in 947 AuCPace with a corresponding commutative group actions on isogenies, 948 such as suggested in [IsogenyPAKE]. CPace does not require arbitrary 949 group operations but only the operation set available in a group 950 modulo negation. This is considered to be a significant advantage 951 when using commutative isogeny-based group action cryptography as a 952 replacement for elliptic-curve Diffie-Hellmann. 954 Strong AuCPace is pre-computation attack resistant under the CDH and 955 One-More-DH assumption set. While the rest of the AuCPace protocol 956 is quantum-annoying, solving a single discrete logarithm problem will 957 reveal the salt-derivation parameter q to the adversary and allow him 958 for pre-computing a rainbow table for a given user name. In order to 959 provide resistance with respect to LSQC-based attacks, a post-quantum 960 instance of an olibvious pseudo-random function (OPRF) would have to 961 be used as replacement of the Diffie-Hellman OPRF construction as 962 used by strong AuCPace. 964 9. IANA Considerations 966 No IANA action is required. 968 10. Acknowledgments 970 Thanks to the members of the CFRG for comments and advice. 972 11. References 973 11.1. Normative References 975 [HASH2CURVE] 976 Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and 977 C. Wood, "draft-irtf-cfrg-hash-to-curve-05", 2019. 979 IRTF draft standard 981 [IEEE1363] 982 IEEE, ""Standard Specifications for Public Key 983 Cryptography", IEEE 1363", 2000. 985 IEEE 1363 987 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 988 Requirement Levels", BCP 14, RFC 2119, 989 DOI 10.17487/RFC2119, March 1997, 990 . 992 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 993 Key Derivation Function (HKDF)", RFC 5869, 994 DOI 10.17487/RFC5869, May 2010, 995 . 997 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 998 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 999 DOI 10.17487/RFC6234, May 2011, 1000 . 1002 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1003 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1004 2016, . 1006 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 1007 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 1008 August 2016, . 1010 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1011 Signature Algorithm (EdDSA)", RFC 8032, 1012 DOI 10.17487/RFC8032, January 2017, 1013 . 1015 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1016 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1017 May 2017, . 1019 11.2. Informative References 1021 [HL18] Haase, B. and B. Labrique, "AuCPace. PAKE protocol 1022 tailored for the use in the internet of things.", Feb 1023 2018. 1025 eprint.iacr.org/2018/286 1027 [IsogenyPAKE] 1028 Taraskin, O., Soukharev, V., Jao, D., and J. LeGrow, "An 1029 Isogeny-Based Password-Authenticated Key Establishment 1030 Protocol.", Sep. 2018. 1032 eprint.iacr.org/2018/886 1034 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, 1035 Enforcement, and Comparison of Internationalized Strings 1036 Representing Usernames and Passwords", RFC 8265, 1037 DOI 10.17487/RFC8265, October 2017, 1038 . 1040 [VTBPEKE] Pointcheval, D. and G. Wang, "VTBPEKE: Verifier-based Two- 1041 Basis Password ExponentialKey Exchange", 2017. 1043 Proceedings of the 2017 {ACM} on Asia Conference on 1044 Computer and Communications Security, AsiaCCS 2017 1046 Appendix A. AuCPace25519 Test Vectors 1048 A.1. Inverse X25519 test vectors 1049 ######################## /inverse X25519 ########################## 1051 Z : 1052 0x5d7189be6192ffccdb80902ac26c5d38592822a761c7268007200a232a4cd841 1053 r (random scalar input for X25519): 1054 0xe8a70b556490ecdbd52c2927464d4eff557807496af234fc496c9f4221bd4423 1055 U = X25519(Z,r): 1056 0x3e6377b3410a60d0ca65190963ad6dce3aeae178aafad369dc2a59c59acc3ceb 1057 IU = inverse_X25519(U) 1058 0x5d7189be6192ffccdb80902ac26c5d38592822a761c7268007200a232a4cd841 1060 Z : 1061 0x73583bc520f4b9e1245e29b92e6b12dc1c8bc0d9b018a1e2626875db2774974 1062 r (random scalar input for X25519): 1063 0xe22cb510bd45fc6cbcb929353777925d152c2a9a5b924715d7480aad8b64d447 1064 U = X25519(Z,r): 1065 0x545040a9ac1cc13a627dddc0ab4ef0b9128d54476aa98727bd45a86ea2d6de24 1066 IU = inverse_X25519(U) 1067 0x73583bc520f4b9e1245e29b92e6b12dc1c8bc0d9b018a1e2626875db2774974 1069 ######################## inverse X25519/ ########################## 1071 A.2. Strong AuCPace25519 salt test vectors 1072 ############ /salt derivation for strong AuCPace ################## 1074 DSI5 = 417543506163653235353139 string ('AuCPace25519') of len(12) 1075 pw = 70617373776f7264 ('password') string of len(8) 1076 ZPAD = 108 zero bytes 1077 name = 757365726e616d65 ('username') string of len(8) 1078 u = SHA512(DSI||password||ZPAD||username) as 512 bit int: 1079 0xfec497749d249426e4895e05d0bb4f565aa4423f33d19e6b20aa3837eb77d16e 1080 <<256 1081 + 0xb8f5b1b51c1557c088356d7ca09bd78f259f1d5f4041d466f4edd40f041a0bb3 1083 u as reduced base field element coordinate: 1084 0xa242d046f835586749962599c699e609a00f2c0f15f584dce322c5bf7e327be 1086 Z = Elligator2(u) as base field element coordinate: 1087 0x3c01681e4c6d4a43b527c789bcf6046b53ac14c516dfbbbb0f8916826b537f4b 1089 salt-derivation parameter q: 1090 0xf40546b4544bae5fcc564dc917407ee02300312c8fd558a0b37f48322277962e 1092 ZQ = X25519(Z,q): 1093 0x77412819cad958e14d4a4c09c129456b90733fd13f337ffed6c0a30f7c3a9a50 1095 Blinding scalar r: 1096 0x1698d57693a684a957ae0492bade0dfd6a261dfa2bb4a74c6b0b8b84acf082a8 1097 U = X25519(Z,r): 1098 0xaf2a058fbd974a6122f8316323060d808705701971666121477eba97386a977 1099 UQ = X25519(U,q): 1100 0x610270daff540b5b7adec057e0f8fa1bfe7687649d95f65560a77a2be70e6cb5 1101 ZQ = inverse_X25519(Z,r) 1102 0x77412819cad958e14d4a4c09c129456b90733fd13f337ffed6c0a30f7c3a9a50 1104 ############ salt derivation for strong AuCPace/ ################## 1106 A.3. Test vectors for AuCPace password verifier 1107 ###################### /Password verifier ######################### 1108 Inputs: 1110 Password: 'password', length 8 1111 User Name: 'username', length 8 1113 Z for username, password: 1114 0x3c01681e4c6d4a43b527c789bcf6046b53ac14c516dfbbbb0f8916826b537f4b 1115 q: 1116 0xf40546b4544bae5fcc564dc917407ee02300312c8fd558a0b37f48322277962e 1118 Salt value salt = X25519(Z,q): 1119 0x77412819cad958e14d4a4c09c129456b90733fd13f337ffed6c0a30f7c3a9a50 1121 #################################################################### 1123 Concatenated input to scrypt as password parameter: 1124 'passwordusername', length 16 1126 Salt value Z^q: 1127 0x77412819cad958e14d4a4c09c129456b90733fd13f337ffed6c0a30f7c3a9a50 1128 Password hash w from scrypt with N=1<<15, r=8, p=1 1129 0xd832084ac895c20b4893ba4541daeb41ee8ae6cf99788ac8fda4a125734eb5f2 1130 Password verifier W = X25519(B,w) 1131 0x12511fcfc70fe9c3a8e72b347d7de52927fc253b83edc8271a5e90ecdf958f57 1132 Server private key x = 1133 0x8b2389da423eb4f8979245d5b4527f92eacc1f3ad11581822d56498c44d4aba4 1134 Server Public key X = X25519(B,x) 1135 0x3e97ae1689d3b1c9fbd82e0cc036118f44279f58537a6b13b2db87e62682afd7 1136 Shared secret XW = X25519(W,x) 1137 0x3e97ae1689d3b1c9fbd82e0cc036118f44279f58537a6b13b2db87e62682afd7 1138 ###################### Password verifier/ ######################### 1140 Author's Address 1142 Bjoern Haase 1143 Endress + Hauser Liquid Analysis 1145 Email: bjoern.m.haase@web.de