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