]> Nexus - San Francisco

michel.abdalla@gmail.com

Endress + Hauser Liquid Analysis - Gerlingen

bjoern.m.haase@web.de

IBM Research Europe - Zurich

juliahesse2@gmail.com

CFRG 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 and can be used on groups 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 aims at avoiding common implementation pitfalls already by design, such as avoiding incentives for insecure execution-time speed optimizations. For smooth integration into different cryptographic library ecosystems, this document provides a variety of cipher suites.
• Post-quantum annoyance: CPace comes with measures to slow down adversaries 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 of 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 appendix provides code and test vectors of all of the functions defined for CPace.

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. I.e. with CPace the parties start the protocol with a shared secret octet string, namely the password-related string (PRS). 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 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 to B and B sends one message to A. 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 if and only if both sides did initiate the protocol using the same protocol inputs, specifically the same PRS and the same value for the input parameters CI, ADa, ADb and sid that will be specified in section . This specification considers different application scenarios. This includes applications aiming at anonymous key exchange and applications that need to rely on verification of identities of one or both communication partners. Moreover, when identities are used, they may or may not need to be kept confidential. Depending on the application's requirements, identity information regarding the communication partners may have to be mandatorily integrated in the input parameters CI, ADa, ADb and the protocol may have to be executed with clear initiator and responder roles (see ). The naming of ISK 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.

CPace inputs For accommodating different application settings, CPace offers the following inputs which, depending on the application scenario, MAY also be the empty string:

• Party identity strings (A,B). In CPace, each party can be given a party identity string which might be a device name, a user name, or an URL. CPace offers two alternative options for authenticating the party identifiers in the course of the protocol run (see ).
• 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. CI could for instance include networking addresses of both parties or party identity strings or service port number identifiers. 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. Both parties will only establish a common session key if they initiated the protocol with the same view of CI.
• Associated data fields (ADa and ADb). These fields can be used for authenticating associated data alongside the CPace protocol. The ADa and ADb will be sent in clear text as part of the protocol messages. ADa and ADb will become authenticated in a CPace protocol run as both parties will only agree on a common key if they have had the same view on ADa and ADb. Applications that need to rely on the identity of the communication partner may have to integrate identity information in ADa and/or 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 appropriate PRS (respectively password) for this identity. ADa and ADb could also include application protocol version information (e.g. to avoid downgrade attacks).
• Session identifier (sid). If both parties have access to the same unique public octet string sid being specific for a communication session before starting the protocol, it is RECOMMENDED to use this sid value as an additional input for the protocol as this provides security advantages and will bind the CPace run to this communication session (see ).

Optional CPace outputs If a session identifier is not available as input at protocol start CPace can optionally produce a unique public session identifier sid_output as output that might be helpful for the application for actions subsequent to the CPace protocol step (see , ).

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.
• This document does not specify which encodings applications use for the mandatory PRS input and the 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 along the guidelines of . In the symmetric setting, transcripts ordered string concatenation must be used for generating protocol transcripts. In this document we will provide test vectors for both the initiator-responder and the symmetric setting.

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-512_SSWU_NU_ from on curve NIST-P521 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

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 additive 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 a hash function H.
• G.sample_scalar() is a function returning a representation of an integer (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 = y*g.
• 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 y*g. Additionally, scalar_mult_vfy specifies validity conditions for y,g and y*g and outputs G.I in case they are not met.
• G.DSI denotes a domain-separation identifier octet string which SHALL be uniquely identifying the group environment G.

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. 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 the first l octets of the hash of m.
• H.b_in_bytes denotes the minimum output size in bytes for collision resistance for the security level target 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. This number denotes the maximum number of bytes that can be processed in a single block before applying the compression function or permutation becomes necessary. (See also for the corresponding block size concepts). For instance, for SHA-512 the input block size s_in_bytes is 128 as the compression function can process up to 128 bytes, while for SHAKE-256 the input block size amounts to 136 bytes before the permutation of the sponge state needs to be applied.

Notation for string operations

• bytes1 || bytes2 denotes concatenation of octet strings.
• len(S) denotes the number of octets in an octet string S.
• This document uses quotation marks "" both for general language (e.g. for citation of notation used in other documents) and as syntax for specifying octet strings as in b"CPace25519". We use a preceding lowercase letter b"" in front of the quotation marks if a character sequence is representing an octet string sequence. I.e., we use the notation convention for byte string representations with single-byte ASCII character encodings from the python programming language. b"" denotes the empty string of length 0.
• LEB128 denotes an algorithm that converts an integer to a variable sized string. The algorithm encodes 7 bits per byte starting with the least significant bits in bits #0 to #6. As long as significant bits remain, bit #7 will be set. This will result in a single-byte encoding for values below 128. Test vectors and reference code for LEB128 encoding are available in the appendix.
• 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 is encoded using LEB128. Test vectors and code for prepend_len are available 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 reference code is available in the appendix.
• sample_random_bytes(n) denotes a function that returns n octets, each of which is to be independently sampled from a uniform distribution between 0 and 255.
• zero_bytes(n) denotes a function that returns n octets with value 0.
• o_cat(bytes1,bytes2) denotes a function for ordered concatenation of octet strings. It places the lexicographically larger octet string first and prepends the two bytes from the octet string b"oc" to the result. Reference code for this function is available in the appendix.
• transcript(Ya,ADa, Yb,ADb) denotes a function outputting an octet string for the protocol transcript. 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_oc(Ya,ADa, Yb,ADb) = o_cat(lv_cat(Ya,ADa),lv_cat(Yb, ADb)) SHALL be used. In the initiator-responder setting, the implementation transcript_ir(Ya,ADa, Yb,ADb) = lv_cat(Ya,ADa) || lv_cat(Yb, ADb) SHALL be used.

Notation for group operations We use additive notation for the group, i.e., 2*X 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 and H. Parties will also be provisioned with CI,sid,ADa (for A) and CI,sid,ADb (for B) which will default to the empty string b"" if not used. Party identifiers SHALL be integrated into CI and/or ADa and ADb following the guidelines in . A sends the public share Ya and associated data ADa to B. Likewise, B sends the public share Yb and associated data ADb to A. Both A and B use the received messages for deriving a shared intermediate session key, ISK.

Protocol flow | | 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 Ya and 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 Yb and associated data ADb to A. B then computes K = G.scalar_mult_vfy(yb,Ya). B MUST abort if K=G.I. Otherwise B calculates ISK = H.hash(lv_cat(G.DSI || b"_ISK", sid, K)||transcript(Ya,ADa,Yb,ADb)). B returns ISK and terminates. Likewise upon reception of the message from B, A computes K = G.scalar_mult_vfy(ya,Yb). A MUST abort if K=G.I. Otherwise A calculates ISK = H.hash(lv_cat(G.DSI || b"_ISK", sid, K) || transcript(Ya,ADa,Yb,ADb)). 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 the transcript views of both parties match.

Implementation of recommended CPace cipher suites

Common function for computing generators The different cipher suites for CPace defined in the upcoming sections share the following method for deterministically combining the individual strings PRS, CI, sid and the domain-separation identifier DSI to a generator string:

• generator_string(DSI, PRS, CI, sid, s_in_bytes) denotes a function that returns the string lv_cat(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 DSI and PRS together with the zero padding field completely fills at least the first input block (of length s_in_bytes) of the hash. As a result for the common case of short PRS the number of bytes to hash becomes independent of the actual length of the password (PRS). (Code 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 a short 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 and that there is no limitation regarding the maximum length of the PRS string.

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 = b"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 = b"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.

Code for the functions above is available in the appendix.

Verification tests For single-coordinate Montgomery ladders on Montgomery curves, verification tests according to SHALL check for proper handling of the abort conditions, when a party is receiving 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 may 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 an element-derivation function that maps a byte string to a group element. 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 = b"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 = b"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(y * (_g)), 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( y * decode(X) ).
• 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 = element_derivation(gen_str_hash) using the element derivation 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 check for proper handling of the abort conditions, when a party is receiving encodings of the neutral element or receives 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 function. encode_to_curve must map an octet string 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 sub steps 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 identity 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 G.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 and returns 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,DST) we denote a mapping function from . I.e. a function that maps octet string str to a point on the group using the domain separation tag DST. 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 octet string. G.DSI which SHALL BE obtained by the concatenation of b"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 = b"CPaceP384_XMD:SHA-384_SSWU_NU_".

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

• G.DST denotes the domain-separation tag value to use in conjunction with the encode_to_curve function from . G.DST shall be obtained by concatenating G.DSI and b"_DST".
• G.sample_scalar() SHALL return a value between 1 and (G.group_order - 1). The sampling SHALL BE indistinguishable from uniform random selection between 1 and (G.group_order - 1). It is RECOMMENDED to use a constant-time rejection sampling algorithm 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, G.DST) is returned, using the selected suite 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 s*X or the point (-s)*X 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 s*X or (-s)*X as both points s*X and (-s)*X 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 s*X is the neutral element) or the secret shared value "z" defined in (otherwise). "z" SHALL be encoded by using the big-endian encoding of the x-coordinate of the result point s*X 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 check for proper handling of the abort conditions, when a party is receiving an encoding 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 point encodings within the messages of party A and B and introduce this in a protocol run. It SHALL be verified that the abort condition is properly handled. 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. The security analysis in extends the analysis from by covering the case that no pre-agreed session identifier is available. also shows how a unique session id sid_output can be generated along with the protocol for applications that do not have a session identifier input available.

Party identifiers The protocol assures that both communication partners have had the same view on the communication transcripts and the inputs CI and sid. If CPace is instantiated without identity strings for A or B in its inputs it will anonymously create a key with any party using the same PRS and sid values and cannot give any further guarantee regarding the identity of the communication partner. A protocol instance running on a party P might even be communicating with a second protocol instance also running on P.

Guidance regarding party identifier integration If an application layer's security relies on CPace for checking party identities, it SHALL integrate the party identifiers that are to be checked in the CPace protocol run within CI or ADa/ADb as specified below.

• If CPace is used in initiator-responder mode, identity strings that are to be authenticated and that are available for both communication partners at protocol start SHOULD be integrated as part of CI. If both party identifiers are integrated into CI, the encoding MUST associate the initiator and responder roles with the respective identity strings. It is recommended to place the initiator`s identity first and the responder`s identity second. Party identity information included in CI will be kept confidential.
• Party identities that are not included in CI identity and are to be authenticated by CPace SHALL be integrated in ADa/ADb, such that A integrates its party identifier in ADa and B integrates its party identifier in ADb. In this case, the application layer SHALL make the recipient check the party identifier string of the remote communication partner. Note that identities communicated in ADa or ADb will not be kept confidential.

If ADa and ADb are not guaranteed to be unique, then CPace SHALL be used in initator-responder mode. If CPace is to be run in the symmetric mode without initiator and responder roles, the application can always enforce uniqueness of ADa and ADb for all sessions by adding further information such as random data.

Rationale for the above guidance Incorporating party identifier strings is important for fending off attacks based on relaying messages. Such attacks become for example relevant in a setting where several parties, say, A, B and C, share the same password PRS. An adversary might relay messages from an 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 share the same PRS value, then A might be using CPace for establishing a common ISK key with C while assuming to interact with party B. If a party A is allowing for multiple concurrent sessions, the adversary may also mount an attack relaying messages of A looped back to A such that A actually shares a key with itself . Integration of party identity strings in CI is to be preferred. This way, the identities may be kept confidential. If both identities are to be integrated in CI, this is only possible if clear initiator and responder roles are assigned and the encoding of the identities associates the role with the identity string. Integration of identity strings in CI also avoids the need of the security-critical subsequent check for the identity strings, which might be omitted or implemented incorrectly without notice. Integration of identities into CI also strengthens the security properties with respect to attacks based on quantum computers . Applications that integrate identity strings in ADa and/or ADb shall carefully verify implementations for correctness of the implemented identity checks that the application must carry out after the CPace run. When adding randomness guaranteeing for unique values of ADa and ADb then a party running the application can detect for loopback attacks by checking that the received remote value of ADa/ADb doesn't show up in the list of active local concurrent protocol sessions . If no unique value in ADa and ADb is available or if maintaining state information regarding the list of concurrently active local protocol instances for verification is impractical in a given application setting, then the loopback attack may be prevented by assigning initiator and responder role and mandating that a given party implements either the initiator or responder role for a given PRS password but not both roles with the same (PRS,sid) value set. Note that the requirement on party identifiers may differ from what might be intuitively expected as information on the application service such as service identifiers, port-ids and role information (e.g. client or server role) should be included as part of the party identity. For instance, if computers A and B allow for running a protocol with different roles (e.g. both might run several client and a server instances concurrently on different ports) then a relay attack may successfully generate protocol confusion. E.g. a client instance on A may be maliciously redirected to a second client instance on B while it expects to be connecting to a server on B. This will work if client and server instances on B share the same PRS secret and the identity strings do not include information on the respective roles.

Hashing protocol transcripts CPace prepends the length of all variable-size input strings before hashing data. Prepending the length of all variable-size input strings 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 .

Key derivation A CPace implementation SHALL output ISK but MUST NOT expose K, because a leaked K may enable offline dictionary attack on the password, and a matching value for K does not provide authentication of ADa and ADb. 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 key confirmation. 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 mac_key = H.hash(b"CPaceMac" || sid || ISK).
• Then let each party send an authenticator tag calculated over the protocol message that it has sent previously. I.e. let party A calculate its authentication tag Ta as Ta = MAC(mac_key, lv_cat(Ya,ADa)) and let party B calculate its authentication tag Tb as Tb = MAC(mac_key, lv_cat(Yb,ADb)).
• Let the receiving party check the remote authentication tag for the correct value and abort in case that it's incorrect.

Integrating CPace in higher-level protocols such as TLS1.3 When integrating CPace into a higher-level protocol such as TLS1.3 it is recommended to use ISK as shared secret (which might otherwise be generated as part of a Diffie-Hellman key exchange output for other cipher suites). Note that unlike the shared secret of a Diffie-Hellman protocol run, ISK will also provide mutual implicit authentication of the protocol partners. For providing explicit authentication, it is recommended to add a key confirmation round along the lines in , such as e.g. done in the "Finished" messages in TLS1.3 . If an embedding protocol uses more than two messages (e.g. four message TLS1.3 flows involving a hello-retry message and a repeated client-hello message) it is suggested that the CPace layer only considers the two messages used for the CPace run. I.e., it is suggested that authenticating the full message sequence involving also the additional messages that might precede the two CPace messages is done under the responsibility of the embedding application protocol. This could be done by integrating the full protocol transcript as part of a final explicit key confirmation round (as commonly done by TLS 1.3 as part of the "Finished" messages). Alternatively, information on communication rounds preceding the CPace flows can also be integrated as part of the CI field, as this will authenticate the information and will not require both communication partners to keep state information regarding preceding messages in memory until after the CPace run. In case of TLS 1.3 it is suggested to integrate Ya into the client-hello message and Yb into the server-hello message. Also party identifiers might best be added to the client-hello and server-hello messages as part of extension fields. It is recommended to use the full octet stream encoding of the client-hello message as parameter ADa. Likewise it is recommended to use the encoding of the server-hello message for the parameter ADb. This approach has the drawback that the public points Ya and Yb might show up redundantly duplicated in the hashing operation for CPace's transcript strings but has the advantage of simplicity and the advantage that all meta-information in the extension fields within the client- and server hello fields will always become authenticated as part of the ISK.

Calculating a session identifier alongside with the CPace run If CPace was run with an empty string sid available as input, both parties can produce a public session identifier string sid_output = H.hash(b"CPaceSidOutput" || transcript(Ya,ADa,Yb,ADb)) which will be unique for honest parties .

Sampling of scalars For curves over fields F_q where q 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 the attack surface with respect to side-channels for embedded systems in hostile environments. demonstrated that non-uniform sampling did not negatively impact security 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 . Alternatively an algorithm designed along the lines of the hash_to_field() function from can also be used. There, oversampling to an integer significantly larger than the curve order is followed by a modular reduction to the group order.

Preconditions for using the simplified CPace specification from The security of the algorithms used for 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 curve MUST BE equal to or an integer multiple of the cofactor c' of the curve's quadratic twist. Also, importantly, the implementation of the scalar_mult and scalar_mult_vfy functions must ensure that all scalars actually used for the group operation are integer multiples of c (e.g. such as asserted by the specification of the decodeScalar functions in ).
• Both field order q and group order p MUST BE close to a power of two along the lines of , Appendix E. Otherwise the simplified scalar sampling specified in needs to be changed.
• 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.

Algorithms for curves other than the ones recommended here can be based on the principles from 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 the higher-level protocol that integrates CPace is able to establish a unique sid identifier for the communication session, it is RECOMMENDED that this is passed to CPace as sid parameter. One suitable option for generating sid is concatenation of ephemeral random strings contributed by both parties.

Side channel attacks All state-of-the art methods for realizing constant-time execution SHOULD be used. Special care is RECOMMENDED specifically for elliptic curves in Short-Weierstrass form as important standard documents including describe curve operations with non-constant-time algorithms. 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. The mapping algorithm that converts the generator string to a elliptic curve point SHALL execute in constant time. In suitable constant-time methods are available for any elliptic curve. Even though the calculate_generator operation might be considered to form the primary target for side-channel attacks as information on long-term secrets might be exposed, also the subsequent operations on ephemeral values, such as scalar sampling and scalar multiplication should be protected from side-channels.

Large-characteristic finite fields This document intentionally specifies CPace only for use on elliptic curve groups and the security proofs in only cover this case explicitly. For group environments built upon safe primes additional security analysis will be required. For instance exponential equivalence attacks may become practical when short exponents are used.

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 pre-established session id values sid forces the adversary to solve one computational Diffie-Hellman problem per password guess . If party identifiers are included as part of CI then the adversary is forced to solve one computational Diffie-Hellman problem per password guess and party identifier pair. For this reason it is RECOMMENDED to use the optional inputs sid if available in an application setting. For the same reason it is RECOMMENDED to integrate party identity strings A,B into CI. 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.

Reference implementation and test vector generation The reference implementation that was used for deriving test vectors is available at . The embedded base64-encoded test vectors will decode to JSON files having the test vector's octet strings encoded as base16 (i.e. hexadecimal) strings.

Acknowledgements We would like to thank the participants on the CFRG list 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. 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. 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 describes the OPAQUE protocol, an Augmented (or Asymmetric) Password-Authenticated Key Exchange (aPAKE) protocol 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. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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 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 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. 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

Testvectors as JSON file encoded as BASE64

lv_cat function

Testvector for lv_cat()

Testvectors as JSON file encoded as BASE64

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

Testvectors as JSON file encoded as BASE64

Definitions for transcript_ir function

Test vectors transcript_ir function

Testvectors as JSON file encoded as BASE64

Definitions for transcript_oc function

Test vectors for transcript_oc function

Testvectors as JSON file encoded as BASE64

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

Testvectors as JSON file encoded as BASE64

Test vector for message from A

Test vector for message from B

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Test vector for optional output of session id

Corresponding C programming language initializers

Testvectors as JSON file encoded as BASE64

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

Testvectors as JSON file encoded as BASE64

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

Test vectors for calculate_generator with group X448

Testvectors as JSON file encoded as BASE64

Test vector for message from A

Test vector for message from B

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Test vector for optional output of session id

Corresponding C programming language initializers

Testvectors as JSON file encoded as BASE64

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

Testvectors as JSON file encoded as BASE64

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

Test vectors for calculate_generator with group ristretto255

Testvectors as JSON file encoded as BASE64

Test vector for message from A

Test vector for message from B

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Test vector for optional output of session id

Corresponding C programming language initializers

Testvectors as JSON file encoded as BASE64

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 message of A or B the protocol MUST abort.

Testvectors as JSON file encoded as BASE64

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

Test vectors for calculate_generator with group decaf448

Testvectors as JSON file encoded as BASE64

Test vector for message from A

Test vector for message from B

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Test vector for optional output of session id

Corresponding C programming language initializers

Testvectors as JSON file encoded as BASE64

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 message of A or B the protocol MUST abort.

Testvectors as JSON file encoded as BASE64

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

Test vectors for calculate_generator with group NIST P-256

Testvectors as JSON file encoded as BASE64

Test vector for message from A

Test vector for message from B

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Test vector for optional output of session id

Corresponding C programming language initializers

Testvectors as JSON file encoded as BASE64

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 messages of A or B the protocol MUST abort.

Testvectors as JSON file encoded as BASE64

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

Test vectors for calculate_generator with group NIST P-384

Testvectors as JSON file encoded as BASE64

Test vector for message from A

Test vector for message from B

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Test vector for optional output of session id

Corresponding C programming language initializers

Testvectors as JSON file encoded as BASE64

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 messages of A or B the protocol MUST abort.

Testvectors as JSON file encoded as BASE64

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

Test vectors for calculate_generator with group NIST P-521

Testvectors as JSON file encoded as BASE64

Test vector for message from A

Test vector for message from B

Test vector for secret points K

Test vector for ISK calculation initiator/responder

Test vector for ISK calculation parallel execution

Test vector for optional output of session id

Corresponding C programming language initializers

Testvectors as JSON file encoded as BASE64

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 messages of A or B the protocol MUST abort.

Testvectors as JSON file encoded as BASE64