]>
CPace, a balanced composable PAKE
DFINITY  Zurich
michel.abdalla@gmail.com
Endress + Hauser Liquid Analysis  Gerlingen
bjoern.m.haase@web.de
IBM Research Europe  Zurich
JHS@zurich.ibm.com
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 bydesign, 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 mitigations with respect to adversaries that become capable of breaking the discrete logarithm problem on elliptic curves.
Outline of this document

describes the expected properties of an application using CPace, and discusses in particular which 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 final section provides explicit reference implementations and test vectors of all of the
functions defined for CPace in the appendix.
As this document is primarily written for implementers and application designers, we would like to refer the 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. CPace requires a shared secret octet string, the passwordrelated string (PRS), is available for both parties A and B. 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 passwordbased key derivation function.
Applications with clients and servers where the server side is storing account and password information in its persistent memory are recommended to use augmented PAKE protocols such as OPAQUE .
In the course of the CPace protocol, A sends one message MSGa to B and B sends one message MSGb to A. CPace does not mandate any ordering of these two messages. We use the term "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 only if both sides did initiate the protocol using the same protocol inputs, specifically the same PRS string and the same value for the optional input parameters CI, ADa, ADb and sid that will be specified in the upcoming sections.
The naming of ISK key as "intermediate" session key highlights the fact that it is RECOMMENDED that applications process ISK by use of a suitable strong key derivation function KDF (such as defined in ) before using the key in a higherlevel protocol.
Optional CPace inputs
For accomodating different application settings, CPace offers the following OPTIONAL inputs, i.e. inputs which MAY also be the empty string:

Channel identifier (CI). CI can be used to bind a session key exchanged with CPace to a specific networking channel which interconnects the protocol parties. Both parties are required to have the same view of CI. CI will not be publicly sent on the wire and may also include confidential information.

Associated data fields (ADa and ADb).
These fields can be used to authenticate public associated data alongside the CPace protocol. The values ADa (and ADb, respectively) are guaranteed to be authenticated in case both parties agree on a key.
ADa and ADb can for instance include party identities or protocol
version information of an application protocol (e.g. to avoid downgrade attacks).
If party identities are not encoded as part of CI, party identities SHOULD be included in ADa and ADb
(see ).
In a setting with clear initiator and responder roles, identity information in ADa
sent by the initiator can be used by the responder for choosing the right PRS string (respectively password) for this identity.

Session identifier (sid).
CPace comes with a security analysis in the framework of universal composability.
This framework allows for modular analysis of a larger application protocol which uses CPace as a building block. For such analysis
the CPace protocol is bound to a specific session of the larger protocol by use of a sid string that is globally unique. As a result, when used with a unique sid, CPace instances remain secure when running concurrently with other CPace instances, and even arbitrary other protocols.
For this reason, it is RECOMMENDED that applications establish a unique session identifier sid
prior to running the CPace protocol. This can be implemented by concatenating random bytes produced by A
with random bytes produced by B. If such preceding round is not an option but
parties are assigned clear initiatorresponder roles, it is RECOMMENDED to let the initiator A choose a fresh
random sid and send it to B together with the first message.
If a sid string is used it SHOULD HAVE a length of at least 8 bytes.
Responsibilities of the application layer
The following tasks are out of the scope of this document and left to the application layer

Setup phase:

The application layer is responsible for the handshake that makes parties agree on a common CPace cipher suite.

The application layer needs to specify how to encode the CPace byte strings Ya / Yb and ADa / ADb defined in section
for transfer over the network.
For CPace it is RECOMMENDED to encode network messages by using MSGa = lv_cat(Ya,ADa) and MSGb = lv_cat(Yb,ADb)
using the lengthvalue concatenation function lv_cat
speficied in .
This document provides test vectors for lv_catencoded messages.
Alternative network encodings, e.g., the encoding method
used for the client hello and server hello messages of the TLS protocol, MAY be used
when considering the guidance given in .

This document does not specify which encodings applications use for the mandatory PRS input and the optional inputs
CI, sid, ADa and ADb. If PRS is a 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 must be generated using ordered string concatenation. 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.
In case that the hash function is specified for a fixedsize output, we define H.hash(m,l) such
that it returns the first l octets of the output.
We use the following notation for referring to the specific properties of a hash function H:

H.hash(m,l) is a function that operates on an input octet string m and returns a hashing result of l octets.

H.b_in_bytes denotes the 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 the 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 = g*y.

G.I denotes a unique octet string representation of the neutral element of the group. G.I is used for detecting and signaling certain error conditions.

G.scalar_mult_vfy(y,g) is a function operating on
a scalar y and a group element g. It returns an octet string
representation of the group element g*y. Additionally, scalar_mult_vfy specifies validity conditions for y,g and g*y and outputs G.I in case they are not met.

G.DSI denotes a domainseparation identifier octet string which SHALL be uniquely identifying the group environment G.
Notation for string operations

bytes1  bytes2 and denotes concatenation of octet strings.

len(S) denotes the number of octets in an octet string S.

nil denotes an empty octet string, i.e., len(nil) = 0.

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 preceeding 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 for byte string representations with singlebyte ASCII character encodings from the python programming language.

prepend_len(octet_string) denotes the octet sequence that is obtained from prepending
the length of the octet string to the string itself. The length shall be prepended by using an LEB128 encoding of the length.
This will result in a singlebyte encoding for values below 128. (Test vectors and reference implementations
for prepend_len and the LEB128 encodings are given in the appendix.)

lv_cat(a0,a1, ...) is the "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 a reference implementations are given in the appendix.

network_encode(Y,AD) denotes the function specified by the application layer that outputs an octet string encoding
of the input octet strings Y and AD
for transfer on the network. The implementation of MSG = network_encode(Y,AD) SHALL allow the receiver party to parse MSG for the
individual subcomponents Y and AD.
For CPace we RECOMMEND to implement network_encode(Y,AD) as network_encode(Y,AD) = lv_cat(Y,AD).
Other encodings, such as the network encoding used for the clienthello and serverhello messages in TLS MAY also be used when
following the guidance given in the security consideration section.

sample_random_bytes(n) denotes a function that returns n octets, each of which is to be independently sampled from an 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 lexiographically larger octet
string first and prepends the two bytes from the octet string b"oc" to the result. (Explicit reference code for this function is given in the appendix.)

transcript(MSGa,MSGb) denotes function outputing a string for the protocol transcript with messages MSGa and MSGb.
In applications where CPace is used without clear initiator and responder roles, i.e. where the ordering of messages is
not enforced by the protocol flow, transcript(MSGa,MSGb) = o_cat(MSGa,MSGb) SHALL be used.
In the initiatorresponder setting transcript(MSGa,MSGb) SHALL BE implemented such that the later message is appended to the
earlier message, i.e., transcript(MSGa,MSGb) = MSGaMSGb if MSGa is sent first.
Notation for group operations
We use additive notation for the group, i.e., X*2 denotes the element that is obtained by computing X+X, for group element X and group operation +.
The CPace protocol
CPace is a one round protocol between two parties, A and B. At invocation, A and B are provisioned with PRS,G,H and OPTIONAL CI,sid,ADa (for A) and CI,sid,ADb (for B).
A sends a message MSGa to B. MSGa contains the public share Ya
and OPTIONAL associated data ADa (i.e. an ADa field that MAY have a length of 0 bytes).
Likewise, B sends a message MSGb to A. MSGb contains the public share Yb
and OPTIONAL associated data ADb (i.e. an ADb field that MAY have a length of 0 bytes).
Both A and B use the received messages for deriving a shared intermediate session key, ISK.
Protocol flow
Optional parameters and messages are denoted with [].

 Yb,[ADb] 
verify inputs < verify inputs
derive ISK   derive ISK

output ISK output ISK
]]>
CPace protocol instructions
A computes a generator g = G.calculate_generator(H,PRS,CI,sid), scalar ya = G.sample_scalar() and group element Ya = G.scalar_mult (ya,g). A then transmits MSGa = network_encode(Ya, ADa) with
optional associated data ADa to B.
B computes a generator g = G.calculate_generator(H,PRS,CI,sid), scalar yb = G.sample_scalar() and group element Yb = G.scalar_mult(yb,g). B sends MSGb = network_encode(Yb, ADb) with optional associated data ADb to A.
Upon reception of MSGa, B checks that MSGa was properly generated in conformity with the chosen encoding of network messages (notably correct length fields).
If this parsing fails, then B MUST abort. (Testvectors of examples for invalid messages when using lv_cat() as network_encode function for
CPace are given in the appendix.)
B then computes K = G.scalar_mult_vfy(yb,Ya). B MUST abort if K=G.I.
Otherwise B calculates
ISK = H.hash(lv_cat(G.DSI  b"_ISK", sid, K)transcript(MSGa, MSGb)). B returns ISK and terminates.
Likewise upon reception of MSGb, A parses MSGb for Yb and ADb and checks for a valid encoding.
If this parsing fails, then A MUST abort. A then computes K = G.scalar_mult_vfy(ya,Yb). A MUST abort if K=G.I.
Otherwise A calculates
ISK = H.hash(lv_cat(G.DSI  b"_ISK", sid, K)  transcript(MSGa, MSGb)). A returns ISK and terminates.
The session key ISK returned by A and B is identical if and only if the supplied input parameters PRS, CI and sid match on both sides and transcript view (containing of MSGa and MSGb) of both parties match.
(Note that in case of a symmetric protocol execution without clear initiator/responder roles, transcript(MSGa, MSGb) needs to be implemented using ordered concatenation for generating a matching view by both parties.)
Implementation of recommended CPace cipher suites
Common function for computing generators
The different cipher suites for CPace defined in the upcoming sections share the same method for deterministically combining the individual strings PRS, CI, sid and the domainseparation identifier DSI to a generator string that we describe here.

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). (A reference implementation 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.
In the appendix we show sage code that can be used as reference implementation.
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((_g) * y), i.e. it returns a value using the public encoding.

G.I = is the public encoding representation of the identity element.

G.scalar_mult_vfy(y,X) operates on a value using the public encoding and a scalar and is implemented as follows. If the decode(X) function fails, it returns G.I. Otherwise it returns encode( decode(X) * y ).

The G.calculate_generator(H, PRS,sid,CI) function SHALL return a decoded point and SHALL BE implemented as follows.

First gen_str = generator_string(G.DSI,PRS,CI,sid, H.s_in_bytes) is calculated using the input block size of the chosen hash function.

This string is then hashed to the required length gen_str_hash = H.hash(gen_str, 2 * G.field_size_bytes). Note that this
implies that the permissible output length H.maxb_in_bytes MUST BE larger or equal to twice the field size of the group
G for making a
hash function suitable.

Finally the internal representation of the generator _g is calculated as _g = 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 substeps 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 identy 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 X*s or the point X*(s) 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 X*s or X*(s) as both points X*s and X*(s) 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 X*s is the neutral element) or the secret shared value "z" (otherwise). "z" SHALL be encoded by using
the bigendian encoding of the xcoordinate of the result point X*s according to .

We represent the neutral element G.I by using the representation of the "error" result case from as used in the G.scalar_mult_vfy method above.
Verification tests
For 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 MSGa and MSGb and introduce this
in a protocol run. It SHALL be verified that the abort condition is properly handled.
Moreover regarding the network format any implementation MUST be tested with respect to invalid encodings of MSGa and MSGb.
E.g. when lv_cat is used as network format for encoding MSGa and MSGb,
the sum of the prepended lengths of the fields must be verified to match the actual length of the message.
Tests SHALL verify that a party aborts in case that incorrectly encoded messages are received.
Corresponding test vectors are given in the appendix for all recommended cipher suites.
Security Considerations
A security proof of CPace is found in . This proof covers all recommended cipher suites included in this document.
In the following sections we describe how to protect CPace against several attack families, such as relay, length extension or side channel attacks. We also describe aspects to consider when deviating from recommended cipher suites.
Party identifiers and relay attacks
If unique strings identifying the protocol partners are included either as part of the channel identifier CI, the session id sid or the associated data fields ADa, ADb, the ISK will provide implicit authentication also regarding the party identities. Incorporating party identifier strings
is important for fending off relay attacks.
Such attacks become relevant in a setting where several parties, say, A, B and C, share the same password PRS. An adversary might relay messages from a honest user A, who aims at interacting with user B, to a party C instead. If no party identifier strings are used, and B and C use the same PRS value, A might be establishing a common ISK key with C while assuming to interact with party B.
Including and checking party identifiers can fend off such relay attacks.
Network message encoding and hashing protocol transcripts
It is RECOMMENDED to encode the (Ya,ADa) and (Yb,ADb) fields on the network by using network_encode(Y,AD) = lv_cat(Y,AD). I.e. we RECOMMEND
to prepend an encoding of the length of the subfields. 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.
Other alternative network encoding formats which prepend an encoding of the length of variablesize data fields in the protocol
messages are equally suitable.
This includes, e.g., the typelengthvalue format specified in the DER encoding standard (X.690) or the protocol message encoding used in the TLS protocol family for the TLS clienthello or serverhello messages.
In case that an application uses another form of network message encoding which is not prefixfree,
the guidance given in SHOULD BE considered (e.g. by replacing hash functions with the HMAC constructions from).
Key derivation
Although already K is a shared value, it MUST NOT itself be used as an application key. Instead, ISK MUST BE used. Leakage of K to an adversary can lead to offline dictionary attacks.
As noted already in it is RECOMMENDED to process ISK
by use of a suitable strong key derivation function KDF (such as defined in ) first,
before using the key in a 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
use of a key confirmation on the level of the CPace subprotocol.
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"  ISK).

Then let each party send an authenticator tag Ta, Tb that is calculated over the protocol message that it has sent previously. I.e.
let party A calculate its transmitted authentication code Ta as Ta = MAC(mac_key, MSGa) and let party B calculate its transmitted
authentication code Tb as Tb = MAC(mac_key, MSGb).

Let the receiving party check the remote authentication tag for the correct value and abort in case that it's incorrect.
Sampling of scalars
For curves over fields F_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.
The effect of nonuniform sampling on security was demonstrated to be begnin in 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 allong 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 CPace is used in a concurrent system, it is RECOMMENDED that a unique sid is generated by the higherlevel protocol and passed to CPace. One suitable option is that sid is generated by concatenating ephemeral random strings contributed by both parties.
Side channel attacks
All 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 session id values
sid forces the adversary to solve one computational DiffieHellman problem per password guess .
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.
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.
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.
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.
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)
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.
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
]]>
Examples for messages not obtained from a lv_catbased encoding
The following messages are examples which have invalid encoded length fields. I.e. they are examples
where parsing for the sum of the length of subfields as expected for a message generated using lv_cat(Y,AD)
does not give the correct length of the message. Parties MUST abort upon reception of such invalid messages as MSGa or MSGb.
Definition of generator_string function.
Definitions and test vector ordered concatenation
Definitions for lexiographical ordering
For ordered concatenation lexiographical ordering of byte sequences is used:
bytes2 using lexiographical ordering."
min_len = min (len(bytes1), len(bytes2))
for m in range(min_len):
if bytes1[m] > bytes2[m]:
return True;
elif bytes1[m] < bytes2[m]:
return False;
return len(bytes1) > len(bytes2)
]]>
Definitions for ordered concatenation
With the above definition of lexiographical ordering ordered concatenation is specified as follows.
Test vectors ordered concatenation
Decoding and Encoding functions according to RFC7748
> 8*i) & 0xff)
for i in range((bits+7)/8)])
]]>
Elligator 2 reference implementation
The Elligator 2 map requires a 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
Test vector for secret points K
Test vector for ISK calculation initiator/responder
Test vector for ISK calculation parallel execution
Corresponding C programming language initializers
Test vectors for G_X25519.scalar_mult_vfy: low order points
Test vectors for which G_X25519.scalar_mult_vfy(s_in,ux) must return the neutral
element or would return the neutral element if bit #255 of field element
representation was not correctly cleared. (The decodeUCoordinate function from RFC7748 mandates clearing bit #255 for field element representations for use in the X25519 function.).
Test vector for CPace using group X448 and hash SHAKE256
Test vectors for calculate_generator with group X448
Test vector for secret points K
Test vector for ISK calculation initiator/responder
Test vector for ISK calculation parallel execution
Corresponding C programming language initializers
Test vectors for G_X448.scalar_mult_vfy: low order points
Test vectors for which G_X448.scalar_mult_vfy(s_in,ux) must return the neutral
element.
This includes points that are 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
Test vector for CPace using group ristretto255 and hash SHA512
Test vectors for calculate_generator with group ristretto255
Test vector for secret points K
Test vector for ISK calculation initiator/responder
Test vector for ISK calculation parallel execution
Corresponding C programming language initializers
Test case for scalar_mult with valid inputs
Invalid inputs for scalar_mult_vfy
For these test cases scalar_mult_vfy(y,.) MUST return the representation of the neutral element G.I. When points Y_i1 or Y_i2 are included in MSGa or MSGb the protocol MUST abort.
Test vector for CPace using group decaf448 and hash SHAKE256
Test vectors for calculate_generator with group decaf448
Test vector for secret points K
Test vector for ISK calculation initiator/responder
Test vector for ISK calculation parallel execution
Corresponding C programming language initializers
Test case for scalar_mult with valid inputs
Invalid inputs for scalar_mult_vfy
For these test cases scalar_mult_vfy(y,.) MUST return the representation of the neutral element G.I. When points Y_i1 or Y_i2 are included in MSGa or MSGb the protocol MUST abort.
Test vector for CPace using group NIST P256 and hash SHA256
Test vectors for calculate_generator with group NIST P256
Test vector for secret points K
Test vector for ISK calculation initiator/responder
Test vector for ISK calculation parallel execution
Corresponding C programming language initializers
Test case for scalar_mult_vfy with correct inputs
Invalid inputs for scalar_mult_vfy
For these test cases scalar_mult_vfy(y,.) MUST return the representation of the neutral element G.I. When including Y_i1 or Y_i2 in MSGa or MSGb the protocol MUST abort.
Test vector for CPace using group NIST P384 and hash SHA384
Test vectors for calculate_generator with group NIST P384
Test vector for secret points K
Test vector for ISK calculation initiator/responder
Test vector for ISK calculation parallel execution
Corresponding C programming language initializers
Test case for scalar_mult_vfy with correct inputs
Invalid inputs for scalar_mult_vfy
For these test cases scalar_mult_vfy(y,.) MUST return the representation of the neutral element G.I. When including Y_i1 or Y_i2 in MSGa or MSGb the protocol MUST abort.
Test vector for CPace using group NIST P521 and hash SHA512
Test vectors for calculate_generator with group NIST P521
Test vector for secret points K
Test vector for ISK calculation initiator/responder
Test vector for ISK calculation parallel execution
Corresponding C programming language initializers
Test case for scalar_mult_vfy with correct inputs
Invalid inputs for scalar_mult_vfy
For these test cases scalar_mult_vfy(y,.) MUST return the representation of the neutral element G.I. When including Y_i1 or Y_i2 in MSGa or MSGb the protocol MUST abort.