]> 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 that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices, is compatible with any cyclic group of prime- and non-prime order. 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 balanced Password-Authenticated-Key-Establishment (PAKE) protocol for two parties where both parties derive a cryptographic key of high entropy from a shared secret of low-entropy. CPace protects the passwords against offline dictionary attacks by requiring adversaries to actively interact with a protocol party and by allowing for at most one single password guess per active interaction. The CPace design was tailored considering the following main objectives:

• Efficiency: Deployment of CPace is feasible on resource-constrained devices.
• Versatility: CPace supports different application scenarios via versatile input formats, and by supporting applications with and without clear initiator and responder roles.
• Implementation error resistance: CPace avoids common implementation pitfalls already by-design, and it does not offer incentives for insecure speed-ups. For smooth integration into different cryptographic library ecosystems, this document provides a variety of cipher suites.
• Post-quantum annoyance: CPace comes with mitigations with respect to adversaries that become capable of breaking the discrete logarithm problem on elliptic curves.

Outline of this document

• describes the expected properties of an application using CPace, and discusses in particular which application-level aspects are relevant for CPace's security.
• gives an overview over the recommended cipher suites for CPace which were optimized for different types of cryptographic library ecosystems.
• introduces the notation used throughout this document.
• specifies the CPace protocol.
• The final section provides explicit reference implementations and test vectors of all of the functions defined for CPace in the appendix.

As this document is primarily written for implementers and application designers, we would like to refer the theory-inclined reader to the scientific paper which covers the detailed security analysis of the different CPace instantiations as defined in this document via the cipher suites.

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.

High-level application perspective CPace enables balanced password-authenticated key establishment. CPace requires a shared secret octet string, the password-related string (PRS), is available for both parties A and B. PRS can be a low-entropy secret itself, for instance a clear-text password encoded according to , or any string derived from a common secret, for instance by use of a password-based key derivation function. Applications with clients and servers where the server side is storing account and password information in its persistent memory are recommended to use augmented PAKE protocols such as OPAQUE . In the course of the CPace protocol, A sends one message MSGa to B and B sends one message MSGb to A. CPace does not mandate any ordering of these two messages. We use the term "initiator-responder" for CPace where A always speaks first, and the term "symmetric" setting where anyone can speak first. CPace's output is an intermediate session key (ISK), but any party might abort in case of an invalid received message. A and B will produce the same ISK value only if both sides did initiate the protocol using the same protocol inputs, specifically the same PRS string and the same value for the optional input parameters CI, ADa, ADb and sid that will be specified in the upcoming sections. The naming of ISK key as "intermediate" session key highlights the fact that it is RECOMMENDED that applications process ISK by use of a suitable strong key derivation function KDF (such as defined in ) before using the key in a higher-level protocol.

Optional CPace inputs For accomodating different application settings, CPace offers the following OPTIONAL inputs, i.e. inputs which MAY also be the empty string:

• Channel identifier (CI). CI can be used to bind a session key exchanged with CPace to a specific networking channel which interconnects the protocol parties. Both parties are required to have the same view of CI. CI will not be publicly sent on the wire and may also include confidential information.
• Associated data fields (ADa and ADb). These fields can be used to authenticate public associated data alongside the CPace protocol. The values ADa (and ADb, respectively) are guaranteed to be authenticated in case both parties agree on a key. ADa and ADb can for instance include party identities or protocol version information of an application protocol (e.g. to avoid downgrade attacks). If party identities are not encoded as part of CI, party identities SHOULD be included in ADa and ADB (see ). In a setting with clear initiator and responder roles, identity information in ADa sent by the initiator can be used by the responder for choosing the right PRS string (respectively password) for this identity.
• Session identifier (sid). CPace comes with a security analysis in the framework of universal composability. This framework allows for modular analysis of a larger application protocol which uses CPace as a building block. For such analysis the CPace protocol is bound to a specific session of the larger protocol by use of a sid string that is globally unique. As a result, when used with a unique sid, CPace instances remain secure when running concurrently with other CPace instances, and even arbitrary other protocols. For this reason, it is RECOMMENDED that applications establish a unique session identifier sid prior to running the CPace protocol. This can be implemented by concatenating random bytes produced by A with random bytes produced by B. If such preceding round is not an option but parties are assigned clear initiator-responder roles, it is RECOMMENDED to let the initiator A choose a fresh random sid and send it to B together with the first message. If a sid string is used it SHOULD HAVE a length of at least 8 bytes.

Responsibilities of the application layer The following tasks are out of the scope of this document and left to the application layer

• Setup phase:
  • The application layer is responsible for the handshake that makes parties agree on a common CPace cipher suite.
  • The application layer needs to specify how to encode the CPace byte strings Ya/Yb and ADa/ADb defined in section for transfer over the network. For CPace it is RECOMMENDED to encode network messages by using MSGa = lv_cat(Ya,ADa) and MSGb = lv_cat(Yb,ADb) using the length-value concatenation function lv_cat speficied in . This document provides test vectors for lv_cat-encoded messages. Alternative network encodings, e.g., the encoding method used for the client hello and server hello messages of the TLS protocol, MAY be used when considering the guidance given in .
• This document does not specify which encodings applications use for the mandatory PRS input and the optional inputs CI, sid, ADa and ADb. If PRS is a clear-text password or an octet string derived from a clear-text password, e.g. by use of a key-derivation function, the clear-text password SHOULD BE encoded according to .
• The application needs to settle whether CPace is used in the initiator-responder or the symmetric setting, as in the symmetric setting transcripts must be generated using ordered string concatenation. In this document we will provide test vectors for both, initiator-responder and symmetric settings.

CPace cipher suites In the setup phase of 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. For naming cipher suites we use the convention "CPACE-G-H". We RECOMMEND the following cipher suites:

• CPACE-X25519-SHA512. This suite uses the group environment G_X25519 defined in and SHA-512 as hash function. This cipher suite comes with the smallest messages on the wire and a low computational cost.
• CPACE-P256_XMD:SHA-256_SSWU_NU_-SHA256. This suite instantiates the group environment 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.

The following RECOMMENDED cipher suites provide higher security margins.

• CPACE-X448-SHAKE256. This suite uses the group environment G_X448 defined in and SHAKE-256 as hash function.
• 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 can also securely be implemented using the cipher suites CPACE-RISTR255-SHA512 and CPACE-DECAF448-SHAKE256 defined in . gives guidance on how to implement CPace on further elliptic curves.

Definitions and notation

Hash function H 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-output-length 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.

Notation for string operations

• bytes1 || bytes2 and denotes concatenation of octet strings.
• 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 for prepend_len and the LEB128 encodings are given in the appendix.)
• lv_cat(a0,a1, ...) is the "length-value" encoding function which returns the concatenation of the input strings with an encoding of their respective length prepended. E.g. lv_cat(a0,a1) returns prepend_len(a0) || prepend_len(a1). The detailed specification of lv_cat and a reference implementations are given in the appendix.
• network_encode(Y,AD) denotes the function specified by the application layer that outputs an octet string encoding of the input octet strings Y and AD for transfer on the network. The implementation of MSG = network_encode(Y,AD) SHALL allow the receiver party to parse MSG for the individual subcomponents Y and AD. For CPace we RECOMMEND to implement network_encode(Y,AD) as network_encode(Y,AD) = lv_cat(Y,AD). Other prefix-free encodings, such as the network encoding used for the client-hello messages in TLS MAY also be used. We give guidance in the security consideration sections. but here the guidance given in the security consideration section MUST be considered.
• 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.
• oCat(bytes1,bytes2) denotes ordered concatenation of octet strings, which places the lexiographically larger octet string first. (Explicit reference code for this function is given in the appendix.)
• transcript(MSGa,MSGb) denotes function outputing a string for the protocol transcript with messages MSGa and MSGb. 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, transcript(MSGa,MSGb) = oCat(MSGa,MSGb) SHOULD be used. In the initiator-responder setting transcript(MSGa,MSGb) SHOULD BE implemented such that the later message is appended to the earlier message, i.e., transcript(MSGa,MSGb) = MSGa||MSGb if MSGa is sent first.

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 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.

Protocol flow Optional parameters and messages are denoted with []. | | Yb,[ADb] | verify inputs |<-----------------| verify inputs 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 = network_encode(Ya, ADa) with optional associated data ADa to B. 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 = network_encode(Yb, ADb) with optional associated data ADb to A. Upon reception of MSGa, B checks that MSGa was properly generated conform with the chosen encoding of network messages (notably correct length fields). If this parsing fails, then B MUST abort. (Testvectors of examples for invalid messages when using lv_cat() as network_encode function for CPace 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)||transcript(MSGa, MSGb)). B returns ISK and terminates. Likewise upon reception of MSGb, A parses MSGb for Yb and ADb and checks for a valid encoding. 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(lv_cat(G.DSI || "_ISK", sid, K) || transcript(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. Note that in case of a symmetric protocol execution without clear initiator/responder roles, ordered concatenation needs to be used for generating a matching view of the transcript by both parties.

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 lv_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.

Network message encoding and hashing protocol transcripts It is RECOMMENDED to encode the (Ya,ADa) and (Yb,ADb) fields on the network by using network_encode(Y,AD) = lv_cat(Y,AD). I.e. we RECOMMEND to prepend an encoding of the length of the subfields. As the length of the variable-size input strings are prepended this results in a so-called prefix-free encoding of transcript strings, using terminology introduced in . This property allows for disregarding length-extension imperfections that come with the commonly used Merkle-Damgard hash function constructions such as SHA256 and SHA512. Other alternative network encoding formats which prepend an encoding of the length of variable-size data fields in the protocol messages are equally suitable. This includes, e.g., the type-length-value format specified in the DER encoding standard (X.690) or the protocol message encoding used in the TLS protocol family for the TLS client-hello or server-hello messages. In case that an application whishes to use another form of network message encoding which is not prefix-free, the guidance given in SHOULD BE considered (e.g. by replacing hash functions with the HMAC constructions from).

Key derivation 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. Algorand Foundation Novi Research Cloudflare, Inc. This document describes the OPAQUE protocol, a secure asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol and one instantiation based on 3DH. 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. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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) This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613. 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. Federal Information Processing Standard, FIPS 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

lv_cat function

Testvector for lv_cat()

Examples for messages not obtained from a lv_cat-based encoding 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 using lv_cat(Y,AD) 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.