]> DFINITY - Zurich

michel.abdalla@gmail.com

Endress + Hauser Liquid Analysis - Gerlingen

bjoern.m.haase@web.de

IBM Research Europe - Zurich

JHS@zurich.ibm.com

Internet-Draft This document describes CPace which is a protocol for two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. This method was tailored for constrained devices, is compatible with any group of both prime- and non-prime order, and comes with a security proof providing composability guarantees. Discussion Venues Discussion of this document takes place on the Crypto Forum Research Group mailing list (cfrg@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction This document describes CPace which is a protocol for two parties for deriving a strong shared secret from a shared low-entropy secret (password) without exposing the secret to offline dictionary attacks. The CPace design was tailored for efficiency on constrained devices such as secure-element chipsets and considers mitigations with respect to adversaries that might become capable of breaking the discrete logarithm problem on elliptic curves by quantum computers. CPace comes with both game-based and simulation-based proofs, where the latter provides composability guarantees that let CPace run securely in concurrent settings.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Definition CPace

Setup For CPace both communication partners need to agree on a common cipher suite. Cipher suites consist of a combination of a hash function H and an elliptic curve environment G. We assume both G and H to come with associated constants and functions as detailed below. To access these we use an object-style notation such as, e.g., H.b_in_bytes and G.sample_scalar().

Hash function H With H we denote a hash function. Common choices for H are SHA-512 or SHAKE-256 . (I.e. the hash function outputs octet strings, and not group elements.) For considering both, variable-output-length hashes and fixed-length output hashes, we use the following convention. In case that the hash function is specified for a fixed-size output, we define H.hash(m,l) such that it returns the first l octets of the output. We use the following notation for referring to the specific properties of a hash function H:

• H.hash(m,l) is a function that operates on an input octet string m and returns a hashing result of l octets.
• H.b_in_bytes denotes the default output size in bytes corresponding to the symmetric security level of the hash function. E.g. H.b_in_bytes = 64 for SHA-512 and SHAKE-256 and H.b_in_bytes = 32 for SHA-256 and SHAKE-128. We use the notation H.hash(m) = H.hash(m, H.b_in_bytes) and let the hash operation output the default length if no explicit length parameter is given.
• H.bmax_in_bytes denotes the maximum output size in octets supported by the hash function. In case of fixed-size hashes such as SHA-256, this is the same as H.b_in_bytes, while there is no such limit for hash functions such as SHAKE-256.
• H.s_in_bytes denotes the input block size used by H. For instance, for SHA-512 the input block size s_in_bytes is 128, while for SHAKE-256 the input block size amounts to 136 bytes.

Group environment G The group environment G specifies an elliptic curve group (also denoted G for convenience) and associated constants and functions as detailed below. In this document we use multiplicative notation for the group operation.

• G.calculate_generator(H,PRS,CI,sid) denotes a function that outputs a representation of a generator (referred to as "generator" from now on) of the group which is derived from input octet strings PRS, CI, and sid and with the help of the hash function H.
• G.sample_scalar() is a function returning a representation of a scalar (referred to as "scalar" from now on) appropriate as a private Diffie-Hellman key for the group.
• G.scalar_mult(y,g) is a function operating on a scalar y and a group element g. It returns an octet string representation of the group element Y = g^y.
• G.I denotes a unique octet string representation of the neutral element of the group. G.I is used for detecting and signaling certain error conditions.
• G.scalar_mult_vfy(y,g) is a function operating on a scalar y and a group element g. It returns an octet string representation of the group element g^y. Additionally, scalar_mult_vfy specifies validity conditions for y,g and g^y and outputs G.I in case they are not met.
• G.DSI denotes a domain-separation identifier string which SHALL be uniquely identifying the group environment G.

Inputs

• PRS denotes a password-related octet string which is a MANDATORY input for all CPace instantiations and needs to be available to both parties. Typically PRS is derived from a low-entropy secret such as a user-supplied password (pw) or a personal identification number, e.g. by use of a password-based key derivation function PRS = PBKDF(pw).
• CI denotes an OPTIONAL octet string identifying a communication channel that needs to be available to both parties. CI can be used for binding a CPace execution to one specific channel. Typically CI is obtained by concatenating strings that uniquely identify the protocol partner's identities, such as their networking addresses.
• sid denotes an OPTIONAL octet string serving as session identifier that needs to be available to both parties. In application scenarios where a higher-level protocol has established a unique sid value, this parameter can be used to ensure strong composability guarantees of CPace, and to bind a CPace execution to the application.
• ADa and ADb denote OPTIONAL octet strings containing arbitrary associated data, each available to one of the parties. They are not required to be equal, and are publicly transmitted as part of the protocol flow. ADa and ADb can for instance include party identifiers or protocol version information (to avoid, e.g., downgrade attacks). In a setting with initiator and responder roles, the information ADa sent by the initiator can be used by the responder for identifying which among possibly several different PRS to use for the CPace session.

Notation

• bytes1 || bytes2 denotes concatenation of octet strings.
• oCat(bytes1,bytes2) denotes ordered concatenation of octet strings, which places the lexiographically larger octet string first. (Explicit code for this function is given in the appendix.)
• concat(MSGa,MSGb) denotes a concatenation method allows both parties to concatenate CPace's protocol messages in the same way. In applications where CPace is used without clear initiator and responder roles, i.e. where the ordering of messages is not enforced by the protocol flow, concat(MSGa,MSGb) = oCat(MSGa,MSGb) SHALL be used. In settings where the protocol flow enforces ordering, concat(MSGa,MSGb) SHOULD BE implemented such that the later message is appended to the earlier message, i.e., concat(MSGa,MSGb) = MSGa||MSGb if MSGa is sent first.
• len(S) denotes the number of octets in a string S.
• nil denotes an empty octet string, i.e., len(nil) = 0.
• prepend_len(octet_string) denotes the octet sequence that is obtained from prepending the length of the octet string to the string itself. The length shall be prepended by using an LEB128 encoding of the length. This will result in a single-byte encoding for values below 128. (Test vectors and reference implementations are given in the appendix.)
• prefix_free_cat(a0,a1, ...) denotes a function that outputs the prefix-free encoding of all input octet strings as the concatenation of the individual strings with their respective length prepended: prepend_len(a0) || prepend_len(a1) || ... . Such prefix-free encoding of multiple substrings allows for parsing individual subcomponents of a network message. (Test vectors and reference implementations are given in the appendix.)
• sample_random_bytes(n) denotes a function that returns n octets uniformly distributed between 0 and 255.
• zero_bytes(n) denotes a function that returns n octets with value 0.

Notation for group operations We use multiplicative notation for the group, i.e., X^2 denotes the element that is obtained by computing X*X, for group element X and group operation *.

The CPace protocol CPace is a one round protocol between two parties, A and B. At invocation, A and B are provisioned with PRS,G,H and OPTIONAL public CI,sid,ADa (for A) and CI,sid,ADb (for B). A sends a message MSGa to B. MSGa contains the public share Ya and OPTIONAL associated data ADa (i.e. an ADa field that MAY have a length of 0 bytes). Likewise, B sends a message MSGb to A. MSGb contains the public share Yb and OPTIONAL associated data ADb (i.e. an ADb field that MAY have a length of 0 bytes). Both A and B use the received messages for deriving a shared intermediate session key, ISK. Naming of this key as "intermediate" session key highlights the fact that it is RECOMMENDED to process ISK by use of a suitable strong key derivation function KDF (such as defined in ) first, before using the key in a higher-level protocol.

Session identifier establishment It is RECOMMENDED to establish a unique session identifier sid in the course of the higher-level protocol that invokes CPace, by concatenating random bytes produced by A with random bytes produced by B. In settings where such establishment is not an option, we can let initiator A choose a fresh random sid and send it to B together with the first message. This method works whenever the message produced by party A comes first. The sid string SHOULD HAVE a length of at least 8 bytes and it MAY also be the empty string, nil. I.e., use of the sid string is OPTIONAL.

Protocol flow Optional parameters and messages are denoted with []. | | Yb, [ADb] | |<-----------------| verify data | | verify data derive ISK | | derive ISK --------------------------------------- output ISK output ISK ]]>

CPace protocol instructions A computes a generator g = G.calculate_generator(H,PRS,CI,sid), scalar ya = G.sample_scalar() and group element Ya = G.scalar_mult (ya,g). A then transmits MSGa = prefix_free_cat(Ya, ADa) with optional associated data ADa to B. ADa MAY have length zero. B computes a generator g = G.calculate_generator(H,PRS,CI,sid), scalar yb = G.sample_scalar() and group element Yb = G.scalar_mult(yb,g). B sends MSGb = prefix_free_cat(Yb, ADb) to A. Note that as prefix_free_cat prepends the respectively length of the input fields, the receivers can parse MSGa and MSGb for subcomponents. Upon reception of MSGa, B checks that MSGa was properly generated by prefix_free_cat. I.e. it checks that the actual length of MSGa matches the sum of the decoded prepended lengths for Ya and ADa. If this parsing fails, then B MUST abort. (Testvectors of examples for invalid messages are given in the appendix.) B then computes K = G.scalar_mult_vfy(yb,Ya). B MUST abort if K=G.I. Otherwise B returns ISK = H.hash(prefix_free_cat(G.DSI || "_ISK", sid, K)||concat(MSGa, MSGb)). B returns ISK and terminates. Upon reception of MSGb, A parses MSGb for Yb and ADb. I.e. it checks that the actual length of MSGb matches the sum of the decoded prepended lengths for Yb and ADb. If this parsing fails, then A MUST abort. A then computes K = G.scalar_mult_vfy(ya,Yb). A MUST abort if K=G.I. Otherwise A returns ISK = H.hash(prefix_free_cat(G.DSI || "_ISK", sid, K) || concat(MSGa, MSGb). A returns ISK and terminates. The session key ISK returned by A and B is identical if and only if the supplied input parameters PRS, CI and sid match on both sides and transcript view (containing of MSGa and MSGb) of both parties match. We note that the above protocol instructions implement a parallel setting with no specific initiator/responder and no assumptions about the order in which messages arrive. If implemented as initiator-responder protocol, the responder, say, B, starts with computation of the generator only upon reception of MSGa.

CPace cipher suites This section documents RECOMMENDED CPace cipher suite configurations. Any cipher suite configuration for CPace is REQUIRED to specify

• A group environment G specified by
  • Functions G.sample_scalar(), G.scalar_mult(), G.scalar_mult_vfy() and G.calculate_generator()
  • A neutral element G.I
  • A domain separation identifier string G.DSI unique for this cipher suite.
• A hash function H specified by
  • Function H.hash()
  • Constants H.b_in_bytes, H.bmax_in_bytes and H.s_in_bytes

For naming cipher suites we use the convention "CPACE-G-H". Currently, test vectors are available for the following RECOMMENDED cipher suites:

• CPACE-X25519-SHA512. This suite uses curve G_X25519 defined in and SHA-512 as hash function.
• CPACE-X448-SHAKE256. This suite uses curve G_X448 defined in and SHAKE-256 as hash function.
• CPACE-P256_XMD:SHA-256_SSWU_NU_-SHA256. This suite instantiates G as specified in using the encode_to_curve function P256_XMD:SHA-256_SSWU_NU_ from on curve NIST-P256, and hash function SHA-256.
• CPACE-P384_XMD:SHA-384_SSWU_NU_-SHA384. This suite instantiates G as specified in using the encode_to_curve function P384_XMD:SHA-384_SSWU_NU_ from on curve NIST-P384 with H = SHA-384.
• CPACE-P521_XMD:SHA-512_SSWU_NU_-SHA512. This suite instantiates G as specified in using the encode_to_curve function P521_XMD:SHA-384_SSWU_NU_ from on curve NIST-P384 with H = SHA-512.
• CPACE-RISTR255-SHA512. This suite uses G_ristretto255 defined in and H = SHA-512.
• CPACE-DECAF448-SHAKE256 This suite uses G_decaf448 defined in and H = SHAKE-256.

CPace can securely be implemented on further elliptic curves when following the guidance given in .

Implementation of recommended CPace cipher suites

Common function for computing generators The different cipher suites for CPace defined in the upcoming sections share the same method for deterministically combining the individual strings PRS, CI, sid and the domain-separation identifier DSI to a generator string that we describe here. Let CPACE-G-H denote the cipher suite.

• generator_string(G.DSI, PRS, CI, sid, s_in_bytes) denotes a function that returns the string prefix_free_cat(G.DSI, PRS, zero_bytes(len_zpad), CI, sid).
• len_zpad = MAX(0, s_in_bytes - len(prepend_len(PRS)) - len(prepend_len(G.DSI)) - 1)

The zero padding of length len_zpad is designed such that the encoding of G.DSI and PRS together with the zero padding field completely fills the first input block (of length s_in_bytes) of the hash. As a result the number of bytes to hash becomes independent of the actual length of the password (PRS). (A reference implementation and test vectors are provided in the appendix.) The introduction of a zero-padding within the generator string also helps mitigating attacks of a side-channel adversary that analyzes correlations between publicly known variable information with the low-entropy PRS string. Note that the hash of the first block is intentionally made independent of session-specific inputs, such as sid or CI.

CPace group objects G_X25519 and G_X448 for single-coordinate Ladders on Montgomery curves In this section we consider the case of CPace when using the X25519 and X448 Diffie-Hellman functions from operating on the Montgomery curves Curve25519 and Curve448 . CPace implementations using single-coordinate ladders on further Montgomery curves SHALL use the definitions in line with the specifications for X25519 and X448 and review the guidance given in . For the group environment G_X25519 the following definitions apply:

• G_X25519.field_size_bytes = 32
• G_X25519.field_size_bits = 255
• G_X25519.sample_scalar() = sample_random_bytes(G.field_size_bytes)
• G_X25519.scalar_mult(y,g) = G.scalar_mult_vfy(y,g) = X25519(y,g)
• G_X25519.I = zero_bytes(G.field_size_bytes)
• G_X25519.DSI = "CPace255"

CPace cipher suites using G_X25519 MUST use a hash function producing at least H.b_max_in_bytes >= 32 bytes of output. It is RECOMMENDED to use G_X25519 in combination with SHA-512. For X448 the following definitions apply:

• G_X448.field_size_bytes = 56
• G_X448.field_size_bits = 448
• G_X448.sample_scalar() = sample_random_bytes(G.field_size_bytes)
• G_X448.scalar_mult(y,g) = G.scalar_mult_vfy(y,g) = X448(y,g)
• G_X448.I = zero_bytes(G.field_size_bytes)
• G_X448.DSI = "CPace448"

CPace cipher suites using G_X448 MUST use a hash function producing at least H.b_max_in_bytes >= 56 bytes of output. It is RECOMMENDED to use G_X448 in combination with SHAKE-256. For both G_X448 and G_X25519 the G.calculate_generator(H, PRS,sid,CI) function shall be implemented as follows.

• First gen_str = generator_string(G.DSI,PRS,CI,sid, H.s_in_bytes) SHALL BE calculated using the input block size of the chosen hash function.
• This string SHALL then BE hashed to the required length gen_str_hash = H.hash(gen_str, G.field_size_bytes). Note that this implies that the permissible output length H.maxb_in_bytes MUST BE larger or equal to the field size of the group G for making a hashing function suitable.
• This result is then considered as a field coordinate using the u = decodeUCoordinate(gen_str_hash, G.field_size_bits) function from which we repeat in the appendix for convenience.
• The result point g is then calculated as (g,v) = map_to_curve_elligator2(u) using the function from . Note that the v coordinate produced by the map_to_curve_elligator2 function is not required for CPace and discarded. The appendix repeats the definitions from for convenience.

In the appendix we show sage code that can be used as reference implementation.

Verification tests For single-coordinate Montgomery ladders on Montgomery curves verification tests according to SHALL consider the u coordinate values that encode a low-order point on either, the curve or the quadratic twist. In addition to that in case of G_X25519 the tests SHALL also verify that the implementation of G.scalar_mult_vfy(y,g) produces the expected results for non-canonical u coordinate values with bit #255 set, which also encode low-order points. Corresponding test vectors are provided in the appendix.

CPace group objects G_Ristretto255 and G_Decaf448 for prime-order group abstractions In this section we consider the case of CPace using the Ristretto255 and Decaf448 group abstractions . These abstractions define an encode and decode function, group operations using an internal encoding and a one-way-map. With the group abstractions there is a distinction between an internal representation of group elements and an external encoding of the same group element. In order to distinguish between these different representations, we prepend an underscore before values using the internal representation within this section. For Ristretto255 the following definitions apply:

• G_Ristretto255.DSI = "CPaceRistretto255"
• G_Ristretto255.field_size_bytes = 32
• G_Ristretto255.group_size_bits = 252
• G_Ristretto255.group_order = 2^252 + 27742317777372353535851937790883648493

CPace cipher suites using G_Ristretto255 MUST use a hash function producing at least H.b_max_in_bytes >= 64 bytes of output. It is RECOMMENDED to use G_Ristretto255 in combination with SHA-512. For decaf448 the following definitions apply:

• G_Decaf448.DSI = "CPaceDecaf448"
• G_Decaf448.field_size_bytes = 56
• G_Decaf448.group_size_bits = 445
• G_Decaf448.group_order = l = 2^446 - 1381806680989511535200738674851542 6880336692474882178609894547503885

CPace cipher suites using G_Decaf448 MUST use a hash function producing at least H.b_max_in_bytes >= 112 bytes of output. It is RECOMMENDED to use G_Decaf448 in combination with SHAKE-256. For both abstractions the following definitions apply:

• It is RECOMMENDED to implement G.sample_scalar() as follows.
  • Set scalar = sample_random_bytes(G.group_size_bytes).
  • Then clear the most significant bits larger than G.group_size_bits.
  • Interpret the result as the little-endian encoding of an integer value and return the result.
• Alternatively, if G.sample_scalar() is not implemented according to the above recommendation, it SHALL be implemented using uniform sampling between 1 and (G.group_order - 1). Note that the more complex uniform sampling process can provide a larger side-channel attack surface for embedded systems in hostile environments.
• G.scalar_mult(y,_g) SHALL operate on a scalar y and a group element _g in the internal representation of the group abstraction environment. It returns the value Y = encode((_g)^y), i.e. it returns a value using the public encoding.
• G.I = is the public encoding representation of the identity element.
• G.scalar_mult_vfy(y,X) operates on a value using the public encoding and a scalar and is implemented as follows. If the decode(X) function fails, it returns G.I. Otherwise it returns encode( decode(X)^y ).
• The G.calculate_generator(H, PRS,sid,CI) function SHALL return a decoded point and SHALL BE implemented as follows.
  • First gen_str = generator_string(G.DSI,PRS,CI,sid, H.s_in_bytes) is calculated using the input block size of the chosen hash function.
  • This string is then hashed to the required length gen_str_hash = H.hash(gen_str, 2 * G.field_size_bytes). Note that this implies that the permissible output length H.maxb_in_bytes MUST BE larger or equal to twice the field size of the group G for making a hash function suitable.
  • Finally the internal representation of the generator _g is calculated as _g = one_way_map(gen_str_hash) using the one-way map function from the abstraction.

Note that with these definitions the scalar_mult function operates on a decoded point _g and returns an encoded point, while the scalar_mult_vfy(y,X) function operates on an encoded point X (and also returns an encoded point).

Verification tests For group abstractions verification tests according to SHALL consider encodings of the neutral element and an octet string that does not decode to a valid group element.

CPace group objects for curves in Short-Weierstrass representation The group environment objects G defined in this section for use with Short-Weierstrass curves, are parametrized by the choice of an elliptic curve and by choice of a suitable encode_to_curve(str) function. encode_to_curve(str) must map an octet string str to a point on the curve.

Curves and associated functions Elliptic curves in Short-Weierstrass form are considered in . allows for both, curves of prime and non-prime order. However, for the procedures described in this section any suitable group MUST BE of prime order. The specification for the group environment objects specified in this section closely follow the ECKAS-DH1 method from . I.e. we use the same methods and encodings and protocol substeps as employed in the TLS protocol family. For CPace only the uncompressed full-coordinate encodings from (x and y coordinate) SHOULD be used. Commonly used curve groups are specified in and . A typical representative of such a Short-Weierstrass curve is NIST-P256. Point verification as used in ECKAS-DH1 is described in Annex A.16.10. of . For deriving Diffie-Hellman shared secrets ECKAS-DH1 from specifies the use of an ECSVDP-DH method. We use ECSVDP-DH in combination with the identy map such that it either returns "error" or the x-coordinate of the Diffie-Hellman result point as shared secret in big endian format (fixed length output by FE2OSP without truncating leading zeros).

Suitable encode_to_curve methods All the encode_to_curve methods specified in are suitable for CPace. For Short-Weierstrass curves it is RECOMMENDED to use the non-uniform variant of the SSWU mapping primitive from if a SSWU mapping is available for the chosen curve. (We recommend non-uniform maps in order to give implementations the flexibility to opt for x-coordinate-only scalar multiplication algorithms.)

Definition of the group environment G for Short-Weierstrass curves In this paragraph we use the following notation for defining the group object G for a selected curve and encode_to_curve method:

• With group_order we denote the order of the elliptic curve which MUST BE a prime.
• With is_valid(X) we denote a method which operates on an octet stream according to of a point on the group and returns true if the point is valid or false otherwise. This is_valid(X) method SHALL be implemented according to Annex A.16.10. of . I.e. it shall return false if X encodes either the neutral element on the group or does not form a valid encoding of a point on the group.
• With encode_to_curve(str) we denote a selected mapping function from . I.e. a function that maps octet string str to a point on the group. considers both, uniform and non-uniform mappings based on several different strategies. It is RECOMMENDED to use the nonuniform variant of the SSWU mapping primitive within .
• G.DSI denotes a domain-separation identifier string. G.DSI which SHALL BE obtained by the concatenation of "CPace" and the associated name of the cipher suite used for the encode_to_curve function as specified in . E.g. when using the map with the name "P384_XMD:SHA-384_SSWU_NU_" on curve NIST-P384 the resulting value SHALL BE G.DSI = "CPaceP384_XMD:SHA-384_SSWU_NU_".

Using the above definitions, the CPace functions required for the group object G are defined as follows.

• G.sample_scalar() SHALL return a value between 1 and (G.group_order - 1). The value sampling MUST BE uniformly random. It is RECOMMENDED to use rejection sampling for converting a uniform bitstring to a uniform value between 1 and (G.group_order - 1).
• G.calculate_generator(H, PRS,sid,CI) function SHALL be implemented as follows.
  • First gen_str = generator_string(G.DSI,PRS,CI,sid, H.s_in_bytes) is calculated.
  • Then the output of a call to encode_to_curve(gen_str) is returned, using the selected function from .
• G.scalar_mult(s,X) is a function that operates on a scalar s and an input point X. The input X shall use the same encoding as produced by the G.calculate_generator method above. G.scalar_mult(s,X) SHALL return an encoding of either the point X^s or the point X^(-s) according to . Implementations SHOULD use the full-coordinate format without compression, as important protocols such as TLS 1.3 removed support for compression. Implementations of scalar_mult(s,X) MAY output either X^s or X^(-s) as both points X^s and X^(-s) have the same x-coordinate and result in the same Diffie-Hellman shared secrets K. (This allows implementations to opt for x-coordinate-only scalar multiplication algorithms.)
• G.scalar_mult_vfy(s,X) merges verification of point X according to A.16.10. and the the ECSVDP-DH procedure from . It SHALL BE implemented as follows:
  • If is_valid(X) = False then G.scalar_mult_vfy(s,X) SHALL return "error" as specified in A.16.10 and 7.2.1.
  • Otherwise G.scalar_mult_vfy(s,X) SHALL return the result of the ECSVDP-DH procedure from (section 7.2.1). I.e. it shall either return "error" (in case that X^s is the neutral element) or the secret shared value "z" (otherwise). "z" SHALL be encoded by using the big-endian encoding of the x-coordinate of the result point X^s according to .
• We represent the neutral element G.I by using the representation of the "error" result case from as used in the G.scalar_mult_vfy method above.

Verification tests For Short-Weierstrass curves verification tests according to SHALL consider encodings of the point at infinity and an encoding of a point not on the group.

Implementation verification Any CPace implementation MUST be tested against invalid or weak point attacks. Implementation MUST be verified to abort upon conditions where G.scalar_mult_vfy functions outputs G.I. For testing an implementation it is RECOMMENDED to include weak or invalid points in MSGa and MSGb and introduce this in a protocol run. It SHALL be verified that the abort condition is properly handled. Moreover any implementation MUST be tested with respect invalid encodings of MSGa and MSGb where the length of the message does not match the specified encoding (i.e. where the sum of the prepended length information does not match the actual length of the message). Corresponding test vectors are given in the appendix for all recommended cipher suites.

Security Considerations A security proof of CPace is found in . This proof covers all recommended cipher suites included in this document. In the following sections we describe how to protect CPace against several attack families, such as relay-, length extension- or side channel attacks. We also describe aspects to consider when deviating from recommended cipher suites.

Party identifiers and relay attacks If unique strings identifying the protocol partners are included either as part of the channel identifier CI, the session id sid or the associated data fields ADa, ADb, the ISK will provide implicit authentication also regarding the party identities. Incorporating party identifier strings is important for fending off relay attacks. Such attacks become relevant in a setting where several parties, say, A, B and C, share the same password PRS. An adversary might relay messages from a honest user A, who aims at interacting with user B, to a party C instead. If no party identifier strings are used, and B and C use the same PRS value, A might be establishing a common ISK key with C while assuming to interact with party B. Including and checking party identifiers can fend off such relay attacks.

Hashing and key derivation In order to prevent analysis of length extension attacks on hash functions, all hash input strings in CPace are designed to be prefix-free strings which have the length of individual substrings prepended, enforced by the prefix_free_cat() function. This choice was made in order to make CPace suitable also for hash function instantiations using Merkle-Damgard constructions such as SHA-256 or SHA-512 along the lines of . In case that an application whishes to use another form of encoding, the guidance given in SHOULD BE considered. Although already K is a shared value, it MUST NOT itself be used as an application key. Instead, ISK MUST BE used. Leakage of K to an adversary can lead to offline dictionary attacks. As noted already in it is RECOMMENDED to process ISK by use of a suitable strong key derivation function KDF (such as defined in ) first, before using the key in a higher-level protocol.

Key confirmation In many applications it is advisable to add an explicit key confirmation round after the CPace protocol flow. However, as some applications might only require implicit authentication and as explicit authentication messages are already a built-in feature in many higher-level protocols (e.g. TLS 1.3) the CPace protocol described here does not mandate use of a key confirmation on the level of the CPace sub-protocol. Already without explicit key confirmation, CPace enjoys weak forward security under the sCDH and sSDH assumptions . With added explicit confirmation, CPace enjoys perfect forward security also under the strong sCDH and sSDH assumptions . Note that in it was shown that an idealized variant of CPace also enjoys perfect forward security without explicit key confirmation. However this proof does not explicitly cover the recommended cipher suites in this document and requires the stronger assumption of an algebraic adversary model. For this reason, we recommend adding explicit key confirmation if perfect forward security is required. When implementing explicit key confirmation, it is recommended to use an appropriate message-authentication code (MAC) such as HMAC or CMAC using a key mac_key derived from ISK. One suitable option that works also in the parallel setting without message ordering is to proceed as follows.

• First calculate mac_key as as mac_key = H.hash(b"CPaceMac" || ISK).
• Then let each party send an authenticator tag Ta, Tb that is calculated over the protocol message that it has sent previously. I.e. let party A calculate its transmitted authentication code Ta as Ta = MAC(mac_key, MSGa) and let party B calculate its transmitted authentication code Tb as Tb = MAC(mac_key, MSGb).
• Let the receiving party check the remote authentication tag for the correct value and abort in case that it's incorrect.

Sampling of scalars For curves over fields F_p where p is a prime close to a power of two, we recommend sampling scalars as a uniform bit string of length field_size_bits. We do so in order to reduce both, complexity of the implementation and reducing the attack surface with respect to side-channels for embedded systems in hostile environments. The effect of non-uniform sampling on security was demonstrated to be begning in for the case of Curve25519 and Curve448. This analysis however does not transfer to most curves in Short-Weierstrass form. As a result, we recommend rejection sampling if G is as in .

Single-coordinate CPace on Montgomery curves The recommended cipher suites for the Montgomery curves Curve25519 and Curve448 in rely on the following properties :

• The curve has order (p * c) with p prime and c a small cofactor. Also the curve's quadratic twist must be of order (p' * c') with p' prime and c' a cofactor.
• The cofactor c' of the twist MUST BE EQUAL to or an integer multiple of the cofactor c of the curve.
• Both field order q and group order p MUST BE close to a power of two along the lines of , Appendix E.
• The representation of the neutral element G.I MUST BE the same for both, the curve and its twist.
• The implementation of G.scalar_mult_vfy(y,X) MUST map all c low-order points on the curve and all c' low-order points on the twist to G.I.

Montgomery curves other than the ones recommended here can use the specifications given in , given that the above properties hold.

Nonce values Secret scalars ya and yb MUST NOT be reused. Values for sid SHOULD NOT be reused since the composability guarantees established by the simulation-based proof rely on the uniqueness of session ids . If CPace is used in a concurrent system, it is RECOMMENDED that a unique sid is generated by the higher-level protocol and passed to CPace. One suitable option is that sid is generated by concatenating ephemeral random strings contributed by both parties.

Side channel attacks All state-of-the art methods for realizing constant-time execution SHOULD be used. In case that side channel attacks are to be considered practical for a given application, it is RECOMMENDED to pay special attention on computing the secret generator G.calculate_generator(PRS,CI,sid). The most critical substep to consider might be the processing of the first block of the hash that includes the PRS string. The zero-padding introduced when hashing the sensitive PRS string can be expected to make the task for a side-channel attack somewhat more complex. Still this feature alone is not sufficient for ruling out power analysis attacks.

Quantum computers CPace is proven secure under the hardness of the strong computational Simultaneous Diffie-Hellmann (sSDH) and strong computational Diffie-Hellmann (sCDH) assumptions in the group G (as defined in ). These assumptions are not expected to hold any longer when large-scale quantum computers (LSQC) are available. Still, even in case that LSQC emerge, it is reasonable to assume that discrete-logarithm computations will remain costly. CPace with ephemeral session id values sid forces the adversary to solve one computational Diffie-Hellman problem per password guess . In this sense, using the wording suggested by Steve Thomas on the CFRG mailing list, CPace is "quantum-annoying".

IANA Considerations No IANA action is required.

Acknowledgements Thanks to the members of the CFRG for comments and advice. Any comment and advice is appreciated.

References Normative References Standards for Efficient Cryptography Group (SECG) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cloudflare, Inc. Cornell Tech Cloudflare, Inc. Stanford University Cloudflare, Inc. This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448. Informative References n.d. n.d. n.d. University of Luxembourg New York University University of Luxembourg New York University National Institute of Standards and Technology (NIST) Standards for Efficient Cryptography Group (SECG) Federal Information Processing Standard, FIPS This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard (AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.

CPace function definitions

Definition and test vectors for string utility functions

prepend_len function > 7) if length == 0: break; return length_encoded + data ]]>

prepend_len test vectors

prefix_free_cat function

Testvector for prefix_free_cat()

Examples for invalid encoded messages The following messages are examples which have invalid encoded length fields. I.e. they are examples where parsing for the sum of the length of subfields as expected for a message generated for the prefix free concatenation does not give the correct length of the message. Parties MUST abort upon reception of such invalid messages as MSGa or MSGb.

Definition of generator_string function.

Definitions and test vector ordered concatenation

Definitions for lexiographical ordering For ordered concatenation lexiographical ordering of byte sequences is used: bytes2 using lexiographical ordering." min_len = min (len(bytes1), len(bytes2)) for m in range(min_len): if bytes1[m] > bytes2[m]: return True; elif bytes1[m] < bytes2[m]: return False; return len(bytes1) > len(bytes2) ]]>

Definitions for ordered concatenation With the above definition of lexiographical ordering ordered concatenation is specified as follows.

Test vectors ordered concatenation

Decoding and Encoding functions according to RFC7748 > 8*i) & 0xff) for i in range((bits+7)/8)]) ]]>

Elligator 2 reference implementation The Elligator 2 map requires a non-square field element Z which shall be calculated as follows. The values of the non-square Z only depend on the curve. The algorithm above results in a value of Z = 2 for Curve25519 and Z=-1 for Ed448. The following code maps a field element r to an encoded field element which is a valid u-coordinate of a Montgomery curve with curve parameter A.

Test vectors

Test vector for CPace using group X25519 and hash SHA-512

Test vectors for calculate_generator with group X25519

Test vector for MSGa

Test vector for MSGb

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Corresponding ANSI-C initializers

Test vectors for G_X25519.scalar_mult_vfy: low order points Test vectors for which G_X25519.scalar_mult_vfy(s_in,ux) must return the neutral element or would return the neutral element if bit #255 of field element representation was not correctly cleared. (The decodeUCoordinate function from RFC7748 mandates clearing bit #255 for field element representations for use in the X25519 function.).

Test vector for CPace using group X448 and hash SHAKE-256

Test vectors for calculate_generator with group X448

Test vector for MSGa

Test vector for MSGb

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Corresponding ANSI-C initializers

Test vectors for G_X448.scalar_mult_vfy: low order points Test vectors for which G_X448.scalar_mult_vfy(s_in,ux) must return the neutral element. This includes points that are non-canonicaly encoded, i.e. have coordinate values larger than the field prime. Weak points for X448 smaller than the field prime (canonical) Weak points for X448 larger or equal to the field prime (non-canonical) Expected results for X448 resp. G_X448.scalar_mult_vfy Test vectors for scalar_mult with nonzero outputs

Test vector for CPace using group ristretto255 and hash SHA-512

Test vectors for calculate_generator with group ristretto255

Test vector for MSGa

Test vector for MSGb

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Corresponding ANSI-C initializers

Test case for scalar_mult with valid inputs

Invalid inputs for scalar_mult_vfy For these test cases scalar_mult_vfy(y,.) MUST return the representation of the neutral element G.I. When points Y_i1 or Y_i2 are included in MSGa or MSGb the protocol MUST abort.

Test vector for CPace using group decaf448 and hash SHAKE-256

Test vectors for calculate_generator with group decaf448

Test vector for MSGa

Test vector for MSGb

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Corresponding ANSI-C initializers

Test case for scalar_mult with valid inputs

Invalid inputs for scalar_mult_vfy For these test cases scalar_mult_vfy(y,.) MUST return the representation of the neutral element G.I. When points Y_i1 or Y_i2 are included in MSGa or MSGb the protocol MUST abort.

Test vector for CPace using group NIST P-256 and hash SHA-256

Test vectors for calculate_generator with group NIST P-256

Test vector for MSGa

Test vector for MSGb

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Corresponding ANSI-C initializers

Test case for scalar_mult_vfy with correct inputs

Invalid inputs for scalar_mult_vfy For these test cases scalar_mult_vfy(y,.) MUST return the representation of the neutral element G.I. When including Y_i1 or Y_i2 in MSGa or MSGb the protocol MUST abort.

Test vector for CPace using group NIST P-384 and hash SHA-384

Test vectors for calculate_generator with group NIST P-384

Test vector for MSGa

Test vector for MSGb

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Corresponding ANSI-C initializers

Test case for scalar_mult_vfy with correct inputs

Invalid inputs for scalar_mult_vfy For these test cases scalar_mult_vfy(y,.) MUST return the representation of the neutral element G.I. When including Y_i1 or Y_i2 in MSGa or MSGb the protocol MUST abort.

Test vector for CPace using group NIST P-521 and hash SHA-512

Test vectors for calculate_generator with group NIST P-521

Test vector for MSGa

Test vector for MSGb

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Corresponding ANSI-C initializers

Test case for scalar_mult_vfy with correct inputs

Invalid inputs for scalar_mult_vfy For these test cases scalar_mult_vfy(y,.) MUST return the representation of the neutral element G.I. When including Y_i1 or Y_i2 in MSGa or MSGb the protocol MUST abort.