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