]>
CPace, a balanced composable PAKE
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
InternetDraft
This document describes CPace which is a protocol that allows two
parties that share a lowentropy 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 nonprime 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 PasswordAuthenticatedKeyEstablishment (PAKE)
protocol for two parties where both parties derive a cryptographic key
of high entropy from a shared secret of lowentropy.
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 resourceconstrained 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 executiontime speed optimizations. For smooth integration into different cryptographic library ecosystems, this document provides a variety of cipher suites.

Postquantum 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 applicationlevel 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 theoryinclined 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.
Highlevel application perspective
CPace enables balanced passwordauthenticated key establishment. I.e. with CPace the parties start the protocol with a shared secret octet string, namely the passwordrelated string (PRS).
PRS can be a lowentropy secret itself, for instance a cleartext 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. CPace does not mandate any ordering of these two messages. We use the term "initiatorresponder" 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 optional input parameters CI, ADa, ADb and sid that will be specified in section .
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 higherlevel protocol.
Optional CPace inputs
For accommodating different application settings, CPace offers the following OPTIONAL inputs, i.e. inputs which 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.
The RECOMMENDED option is to integrate both, A and B, into the channel identifier string CI. This option is to be
preferred as A and B will be kept
confidential and as this provides security advantages (see and ).
Integrating A,B into CI, however, requires that both parties know the party identity string of the communication partner
before starting the protocol. If this requirement is not fulfilled in an application setting then CPace offers the alternative of
integrating A as part of the optional input ADa and B as part of the optional input ADb. If the key exchange is successful, parties are guaranteed to learn each other's identity 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.
CI could for instance include networking addresses of both parties or party identity strings.
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.
If an application cannot integrate the party identities (A,B) as part of CI, A SHOULD BE included in ADa and B SHOULD BE included in ADb instead
(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 optional inputs
CI, sid, ADa and ADb. If PRS is a cleartext password or an octet string derived from a cleartext password,
e.g. by use of a keyderivation function, the cleartext password SHOULD BE encoded according to .

The application needs to settle whether CPace is used in the initiatorresponder or the symmetric setting, as in the symmetric
setting transcripts ordered string concatenation must be used for generating protocol transcripts and when integrating
the identity strings A and B into the channel identifier CI.
In this document we will provide test vectors for both, initiatorresponder 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 "CPACEGH". We RECOMMEND the following cipher suites:

CPACEX25519SHA512. This suite uses the group environment G_X25519 defined in and SHA512 as hash function.
This cipher suite comes with the smallest messages on the wire and a low computational cost.

CPACEP256_XMD:SHA256_SSWU_NU_SHA256.
This suite instantiates the group environment G as specified in using the encode_to_curve function P256_XMD:SHA256_SSWU_NU_
from on curve NISTP256, and hash function SHA256.
The following RECOMMENDED cipher suites provide higher security margins.

CPACEX448SHAKE256. This suite uses the group environment G_X448 defined in and SHAKE256 as hash function.

CPACEP384_XMD:SHA384_SSWU_NU_SHA384.
This suite instantiates G as specified in using the encode_to_curve function P384_XMD:SHA384_SSWU_NU_
from on curve NISTP384 with H = SHA384.

CPACEP521_XMD:SHA512_SSWU_NU_SHA512.
This suite instantiates G as specified in using the encode_to_curve function P521_XMD:SHA512_SSWU_NU_
from on curve NISTP521 with H = SHA512.
CPace can also securely be implemented using the cipher suites CPACERISTR255SHA512 and CPACEDECAF448SHAKE256 defined in
. gives guidance on how to implement CPace on further elliptic curves.
Definitions and notation
Hash function H
Common choices for H are SHA512 or SHAKE256 . (I.e., the hash function
outputs octet strings, and not group elements.)
For considering both variableoutputlength hashes and fixedoutputlength 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 SHA512 and SHAKE256 and H.b_in_bytes = 32 for
SHA256 and SHAKE128. 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 fixedsize
hashes such as SHA256, this is the same as H.b_in_bytes, while there is no such limit for hash functions such as SHAKE256.

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 SHA512 the input block size s_in_bytes is 128 as the compression function can process up to 128 bytes,
while for SHAKE256 the input block size amounts to 136 bytes before the permutation of the sponge state needs to be applied.
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 DiffieHellman 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 domainseparation identifier octet string which SHALL be uniquely identifying the group environment G.
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 singlebyte 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 singlebyte 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 "lengthvalue" 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,Yb,ADa,ADb) = o_cat(lv_cat(Ya,ADa),lv_cat(Yb, ADb)) SHALL be used.
In the initiatorresponder setting the implementation transcript_ir(Ya,Yb,ADa,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 OPTIONAL CI,sid,ADa (for A) and CI,sid,ADb (for B) which will default to the empty
string b"" if not used.
A sends the public share Ya and optional associated data ADa to B.
Likewise, B sends the public share Yb and optional associated data ADb to A.
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 Ya and
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 Yb and optional 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 domainseparation 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 zeropadding within the generator string also helps mitigating attacks of a sidechannel adversary that
analyzes correlations between publicly known variable information with a short lowentropy PRS string.
Note that the hash of the first block is intentionally made independent of sessionspecific 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 singlecoordinate Ladders on Montgomery curves
In this section we consider the case of CPace when using the X25519 and X448 DiffieHellman functions
from operating on the Montgomery curves Curve25519 and Curve448 .
CPace implementations using singlecoordinate 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 SHA512.
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 SHAKE256.
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 singlecoordinate 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 loworder
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 noncanonical u coordinate values with bit #255 set, which may also encode loworder points.
Corresponding test vectors are provided in the appendix.
CPace group objects G_Ristretto255 and G_Decaf448 for primeorder 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 elementderivation 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 SHA512.
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 SHAKE256.
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 littleendian 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 sidechannel 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 ShortWeierstrass representation
The group environment objects G defined in this section for use with ShortWeierstrass 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 ShortWeierstrass form are considered in .
allows for both, curves of prime and nonprime 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 ECKASDH1 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 fullcoordinate encodings from (x and y coordinate) SHOULD be used.
Commonly used curve groups are specified in and . A typical representative of such a ShortWeierstrass curve is NISTP256.
Point verification as used in ECKASDH1 is described in Annex A.16.10. of .
For deriving DiffieHellman shared secrets ECKASDH1 from specifies the use of an ECSVDPDH method. We use ECSVDPDH in combination with the identity map such that it either returns "error" or the xcoordinate of the DiffieHellman 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 ShortWeierstrass curves it is RECOMMENDED to use the nonuniform variant of the SSWU
mapping primitive from if a SSWU mapping is available for the chosen curve. (We recommend nonuniform maps in order to give implementations
the flexibility to opt for xcoordinateonly scalar multiplication algorithms.)
Definition of the group environment G for ShortWeierstrass 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 nonuniform mappings based on several different strategies. It is RECOMMENDED to use the nonuniform variant of the SSWU mapping primitive within .

G.DSI denotes a domainseparation 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:SHA384_SSWU_NU_
on curve NISTP384 the resulting value SHALL BE G.DSI = b"CPaceP384_XMD:SHA384_SSWU_NU_".
Using the above definitions, the CPace functions required for the group object G are defined as follows.

G.DST denotes the domainseparation 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 constanttime 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 fullcoordinate 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 xcoordinate and
result in the same DiffieHellman shared secrets K.
(This allows implementations to opt for xcoordinateonly scalar multiplication algorithms.)

G.scalar_mult_vfy(s,X) merges verification of point X according to A.16.10. and the the ECSVDPDH 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 ECSVDPDH 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 bigendian encoding of the xcoordinate 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 ShortWeierstrass 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 preagreed 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 and relay attacks
If unique strings identifying the protocol partners are included either as part of the channel identifier CI or the associated data
fields ADa, ADb, then 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 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.
Including and checking party identifiers can fend off such relay attacks.
The following guidance SHOULD be followed regarding party identifiers.

If an application layer has party identifiers available, it SHOULD integrate party identifiers in the CPace protocol run, either within CI or ADa/ADb.

The application SHOULD give preference to the option of integrating party identifiers in CI. This avoids the need of an explicit check for the identity strings.

Otherwise A SHOULD integrate its party identifiers in ADa and ADb, such that A integrates its identifier in ADa and B integrates its party identifier as part of ADb.
In this case the application layer will have to add an explicit check for the identity string of the actual communication partner for fending off relay attacks.
Hashing protocol transcripts
CPace prepends the length of all variablesize input strings before hashing data.
Prepending the length of
all variablesize input strings results in a socalled prefixfree encoding of transcript strings, using terminology introduced in . This property allows for disregarding lengthextension imperfections that come with the commonly used MerkleDamgard 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 higherlevel 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 builtin feature in many higherlevel 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 messageauthentication 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 higherlevel protocols such as TLS1.3
When integrating CPace into a higherlevel protocol such as TLS1.3 it is recommended to use ISK
as shared secret (which might otherwise be generated as part of a DiffieHellman key exchange output for other cipher suites).
Note that unlike the shared secret of a DiffieHellman 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 helloretry message and a repeated clienthello 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 clienthello message and Yb into the serverhello message. Also party identifiers
might best be added to the clienthello and serverhello messages as part of extension fields.
It is recommended to use the full octet stream encoding of the
clienthello message as parameter ADa. Likewise it is recommended to use the encoding of the serverhello 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 metainformation 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 sidechannels for embedded systems in hostile environments.
demonstrated that nonuniform sampling did not negatively impact security for the case of Curve25519 and Curve448.
This analysis however does not transfer to most curves in ShortWeierstrass 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 loworder points on the curve and all c' loworder 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 simulationbased proof rely on the uniqueness of session ids .
If the higherlevel 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 stateofthe art methods for realizing constanttime execution SHOULD be used.
Special care is RECOMMENDED specifically for elliptic curves in ShortWeierstrass form
as important standard documents including describe curve operations with
nonconstanttime 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 zeropadding introduced when hashing the sensitive PRS string can be expected to make
the task for a sidechannel attack somewhat more complex. Still this feature alone is not sufficient for ruling out power analysis attacks.
Even though the calculate_generator operation might be considered to form the primary target for sidechannel attacks as information on longterm secrets might be exposed,
also the subsequent operations on ephemeral values, such as scalar
sampling and scalar multiplication should be protected from sidechannels.
Quantum computers
CPace is proven secure under the hardness of the strong computational Simultaneous DiffieHellmann (sSDH) and strong computational DiffieHellmann (sCDH)
assumptions in the group G (as defined in ).
These assumptions are not expected to hold any longer when largescale quantum computers (LSQC) are available.
Still, even in case that LSQC emerge, it is reasonable to assume that discretelogarithm computations will remain costly. CPace with ephemeral preestablished session id values
sid forces the adversary to solve one computational DiffieHellman problem per password guess .
If party identifiers are included as part of CI then the adversary is forced to solve one computational DiffieHellman 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 "quantumannoying".
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 base64encoded 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
SEC 1: Elliptic Curve Cryptography
Standards for Efficient Cryptography Group (SECG)
Standard Specifications for Public Key Cryptography, IEEE 1363
Key words for use in RFCs to Indicate Requirement Levels
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.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
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.
Elliptic Curves for Security
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 ~128bit and ~224bit security level, respectively, and are generated deterministically based on a list of required properties.
The ristretto255 and decaf448 Groups
This memo specifies two primeorder groups, ristretto255 and
decaf448, suitable for safely implementing higherlevel and complex
cryptographic protocols. The ristretto255 group can be implemented
using Curve25519, allowing existing Curve25519 implementations to be
reused and extended to provide a primeorder 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
The 'quantum annoying' property of passwordauthenticated key exchange protocols.
n.d.
Algebraic Adversaries in the Universal Composability Framework.
n.d.
Security analysis of CPace
n.d.
Bare PAKE: Universally Composable Key Exchange from Just Passwords
n.d.
MerkleDamgaard Revisited: How to Construct a Hash Function
University of Luxembourg
New York University
University of Luxembourg
New York University
SHA3 Standard: PermutationBased Hash and ExtendableOutput Functions
National Institute of Standards and Technology (NIST)
SEC 2: Recommended Elliptic Curve Domain Parameters
Standards for Efficient Cryptography Group (SECG)
CPace reference implementation (sage)
Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
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.
The OPAQUE Augmented PAKE Protocol
AWS
Meta
Cloudflare, Inc.
This document describes the OPAQUE protocol, an augmented (or
asymmetric) passwordauthenticated key exchange (aPAKE) that supports
mutual authentication in a clientserver setting without reliance on
PKI and with security against precomputation 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.
HMACbased ExtractandExpand Key Derivation Function (HKDF)
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.
Hashing to Elliptic Curves
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.
US Secure Hash Algorithms (SHA and SHAbased HMAC and HKDF)
Federal Information Processing Standard, FIPS
HMAC: KeyedHashing for Message Authentication
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, SHA1, 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 Transport Layer Security (TLS) Protocol Version 1.2
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. [STANDARDSTRACK]
The Transport Layer Security (TLS) Protocol Version 1.3
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.
Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation
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 AESCMAC Algorithm
The National Institute of Standards and Technology (NIST) has recently specified the Cipherbased Message Authentication Code (CMAC), which is equivalent to the OneKey CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128bit Advanced Encryption Standard (AES). This new authentication algorithm is named AESCMAC. The purpose of this document is to make the AESCMAC 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
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 nonsquare field element Z which shall be calculated
as follows.
The values of the nonsquare 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 ucoordinate of a Montgomery curve with curve parameter A.
Test vectors
Test vector for CPace using group X25519 and hash SHA512
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 SHAKE256
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 noncanonicaly 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 (noncanonical)
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 SHA512
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 SHAKE256
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 P256 and hash SHA256
Test vectors for calculate_generator with group NIST P256
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 P384 and hash SHA384
Test vectors for calculate_generator with group NIST P384
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 P521 and hash SHA512
Test vectors for calculate_generator with group NIST P521
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