]>
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 for two
parties that share a lowentropy secret (password) to derive a strong shared key without
disclosing the secret to offline dictionary attacks. This method was tailored for constrained devices,
is compatible with any group of both prime and nonprime order,
and comes with a security proof providing composability guarantees.
Discussion Venues
Discussion of this document takes place on the
Crypto Forum Research Group mailing list (cfrg@ietf.org),
which is archived at .
Source for this draft and an issue tracker can be found at
.
Introduction
This document describes CPace which is a protocol for two
parties for deriving a strong shared secret from a shared lowentropy secret (password) without
exposing the secret to offline dictionary attacks.
The CPace design was tailored for efficiency on constrained devices such as secureelement chipsets
and considers mitigations with respect to adversaries that might become
capable of breaking the discrete logarithm problem on elliptic curves by quantum computers.
CPace comes with both gamebased and simulationbased proofs, where the latter provides
composability guarantees that let CPace run securely in concurrent settings.
Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
Definition CPace
Setup
For CPace both communication partners need to agree on a common cipher suite. Cipher suites consist of a combination of
a hash function H and an elliptic curve environment G. We assume both G and H to come with associated constants and functions
as detailed below. To access these we use an objectstyle notation such as, e.g., H.b_in_bytes and G.sample_scalar().
Hash function H
With H we denote a hash function.
Common choices for H are SHA512 or SHAKE256 . (I.e. the hash function
outputs octet strings, and not group elements.)
For considering both, variableoutputlength hashes and fixedlength output 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 default output size in bytes corresponding to the symmetric
security level 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. For instance, for SHA512 the input block size s_in_bytes is 128,
while for SHAKE256 the input block size amounts to 136 bytes.
Group environment G
The group environment G specifies an elliptic curve group (also denoted G for convenience) and associated constants
and functions as detailed below. In this document we use multiplicative notation for the group operation.
 G.calculate_generator(H,PRS,CI,sid) denotes a function that outputs a representation of a generator (referred to as "generator" from now on) of the group
which is derived from input octet strings PRS, CI, and sid and with the help of the hash function H.
 G.sample_scalar() is a function returning a representation of a scalar (referred to as "scalar" from now on) appropriate as a
private 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 string which SHALL be uniquely identifying the group environment G.
Inputs
 PRS denotes a passwordrelated octet string which is a MANDATORY input for all CPace instantiations and needs to be available to both parties.
Typically PRS is derived from a lowentropy secret such as a usersupplied password (pw) or a personal
identification number, e.g. by use of a passwordbased key derivation function PRS = PBKDF(pw).
 CI denotes an OPTIONAL octet string identifying a communication channel that needs to be available to both parties. CI can be used for
binding a CPace execution to one specific channel. Typically CI is obtained by concatenating strings that
uniquely identify the protocol partner's identities, such as their networking addresses.
 sid denotes an OPTIONAL octet string serving as session identifier that needs to be available to both parties. In application scenarios
where a higherlevel protocol has established a unique sid value, this parameter can be used to ensure strong composability guarantees of CPace, and to bind a CPace execution to the application.
 ADa and ADb denote OPTIONAL octet strings containing arbitrary associated data, each available to one of the parties. They are not required to be equal, and are publicly transmitted as part of the protocol flow. ADa and ADb can for instance include party identifiers or protocol version information
(to avoid, e.g., downgrade attacks). In a setting with initiator and responder roles, the information ADa sent by the
initiator can be used by the responder for identifying which among possibly several different PRS to use for the CPace session.
Notation
 bytes1  bytes2 denotes concatenation of octet strings.
 oCat(bytes1,bytes2) denotes ordered concatenation of octet strings, which places the lexiographically larger octet string first. (Explicit code for this function is given in the appendix.)
 concat(MSGa,MSGb) denotes a concatenation method allows both parties to concatenate CPace's protocol messages in the same way. In applications where CPace is used without clear initiator and responder roles, i.e. where the ordering of messages is not enforced by the protocol flow, concat(MSGa,MSGb) = oCat(MSGa,MSGb) SHALL be used. In settings where the protocol flow enforces ordering, concat(MSGa,MSGb) SHOULD BE implemented such that the later message is appended to the earlier message, i.e., concat(MSGa,MSGb) = MSGaMSGb if MSGa is sent first.
 len(S) denotes the number of octets in a string S.
 nil denotes an empty octet string, i.e., len(nil) = 0.
 prepend_len(octet_string) denotes the octet sequence that is obtained from prepending
the length of the octet string to the string itself. The length shall be prepended by using an LEB128 encoding of the length.
This will result in a singlebyte encoding for values below 128. (Test vectors and reference implementations are given in the appendix.)
 prefix_free_cat(a0,a1, ...) denotes a function that outputs the prefixfree encoding of
all input octet strings as the concatenation of the individual strings with their respective
length prepended: prepend_len(a0)  prepend_len(a1)  ... . Such prefixfree encoding
of multiple substrings allows for parsing individual subcomponents of a network message. (Test vectors and reference implementations are given in the appendix.)
 sample_random_bytes(n) denotes a function that returns n octets
uniformly distributed between 0 and 255.
 zero_bytes(n) denotes a function that returns n octets with value 0.
Notation for group operations
We use multiplicative notation for the group, i.e., X^2 denotes the element that is obtained by computing X*X, for group element X and group operation *.
The CPace protocol
CPace is a one round protocol between two parties, A and B. At invocation, A and B are provisioned with PRS,G,H and OPTIONAL public CI,sid,ADa (for A) and CI,sid,ADb (for B).
A sends a message MSGa to B. MSGa contains the public share Ya
and OPTIONAL associated data ADa (i.e. an ADa field that MAY have a length of 0 bytes).
Likewise, B sends a message MSGb to A. MSGb contains the public share Yb
and OPTIONAL associated data ADb (i.e. an ADb field that MAY have a length of 0 bytes).
Both A and B use the received messages for deriving a shared intermediate session key, ISK.
Naming of this
key as "intermediate" session key highlights the fact that it is RECOMMENDED to process ISK
by use of a suitable strong key derivation function KDF (such as defined in ) first,
before using the key in a higherlevel protocol.
Session identifier establishment
It is RECOMMENDED to establish a unique session identifier sid in the course of the higherlevel protocol that invokes CPace, by concatenating random bytes produced by A with random bytes produced by B.
In settings where such establishment is not an option,
we can let initiator A choose a fresh random sid and send it to B together with the
first message. This method works whenever the message produced by party A comes first.
The sid string SHOULD HAVE a length of at least 8 bytes and it MAY also be the empty string, nil. I.e., use of the sid string is OPTIONAL.
Protocol flow
Optional parameters and messages are denoted with [].

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

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

A group environment G specified by
 Functions G.sample_scalar(), G.scalar_mult(), G.scalar_mult_vfy() and G.calculate_generator()
 A neutral element G.I
 A domain separation identifier string G.DSI unique for this cipher suite.

A hash function H specified by
 Function H.hash()
 Constants H.b_in_bytes, H.bmax_in_bytes and H.s_in_bytes
For naming cipher suites we use the convention "CPACEGH". Currently, test vectors are available for the following RECOMMENDED cipher suites:
 CPACEX25519SHA512. This suite uses curve G_X25519 defined in and SHA512 as hash function.
 CPACEX448SHAKE256. This suite uses curve G_X448 defined in and SHAKE256 as hash function.
 CPACEP256_XMD:SHA256_SSWU_NU_SHA256.
This suite instantiates G as specified in using the encode_to_curve function P256_XMD:SHA256_SSWU_NU_
from on curve NISTP256, and hash function SHA256.
 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:SHA384_SSWU_NU_
from on curve NISTP384 with H = SHA512.
 CPACERISTR255SHA512.
This suite uses G_ristretto255 defined in and H = SHA512.
 CPACEDECAF448SHAKE256
This suite uses G_decaf448 defined in and H = SHAKE256.
CPace can securely be implemented on further elliptic curves when following the guidance given in .
Implementation of recommended CPace cipher suites
Common function for computing generators
The different cipher suites for CPace defined in the upcoming sections share the same method for deterministically combining the individual strings PRS, CI, sid and the domainseparation identifier DSI to a generator string that we describe here. Let CPACEGH denote the cipher suite.
 generator_string(G.DSI, PRS, CI, sid, s_in_bytes) denotes a function that returns the string
prefix_free_cat(G.DSI, PRS, zero_bytes(len_zpad), CI, sid).
 len_zpad = MAX(0, s_in_bytes  len(prepend_len(PRS))  len(prepend_len(G.DSI))  1)
The zero padding of length len_zpad is designed such that the encoding of G.DSI and PRS together with the zero padding field completely
fills the first input block (of length s_in_bytes) of the hash.
As a result the number of bytes to hash becomes independent of the actual length of the password (PRS). (A reference implementation
and test vectors are provided in the appendix.)
The introduction of a zeropadding within the generator string also helps mitigating attacks of a sidechannel adversary that
analyzes correlations between publicly known variable information with the lowentropy PRS string.
Note that the hash of the first block is intentionally made independent of sessionspecific inputs, such as sid or CI.
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 = "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 = "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
consider the 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 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 a onewaymap. With the group abstractions there is a distinction between an internal representation
of group elements and an external encoding of the same group element. In order to distinguish between these
different representations, we prepend an underscore before values using the internal representation within this
section.
For Ristretto255 the following definitions apply:
 G_Ristretto255.DSI = "CPaceRistretto255"
 G_Ristretto255.field_size_bytes = 32
 G_Ristretto255.group_size_bits = 252
 G_Ristretto255.group_order = 2^252 + 27742317777372353535851937790883648493
CPace cipher suites using G_Ristretto255 MUST use a hash function producing at least H.b_max_in_bytes >= 64 bytes of output.
It is RECOMMENDED to use G_Ristretto255 in combination with SHA512.
For decaf448 the following definitions apply:
 G_Decaf448.DSI = "CPaceDecaf448"
 G_Decaf448.field_size_bytes = 56
 G_Decaf448.group_size_bits = 445
 G_Decaf448.group_order = l = 2^446 
1381806680989511535200738674851542
6880336692474882178609894547503885
CPace cipher suites using G_Decaf448 MUST use a hash function producing at least H.b_max_in_bytes >= 112 bytes of output.
It is RECOMMENDED to use G_Decaf448 in combination with 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 = one_way_map(gen_str_hash)
using the oneway map function from the abstraction.
Note that with these definitions the scalar_mult function operates on a decoded point _g and returns an encoded point,
while the scalar_mult_vfy(y,X) function operates on an encoded point X (and also returns an encoded point).
Verification tests
For group abstractions verification tests according to SHALL consider encodings of the neutral element and an octet string
that does not decode to a valid group element.
CPace group objects for curves in 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(str) function.
encode_to_curve(str) must map an octet string str to a point on the curve.
Curves and associated functions
Elliptic curves in 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 group_order we denote the order of the elliptic curve which MUST BE a prime.
 With is_valid(X) we denote a method which operates on an octet stream according to of a point on the group and returns true if the point is valid or false otherwise. This is_valid(X) method SHALL be implemented according to Annex A.16.10. of . I.e. it shall return false if X encodes either the neutral element on the group or does not form a valid encoding of a point on the group.
 With encode_to_curve(str) we denote a selected mapping function from . I.e. a function that maps
octet string str to a point on the group. considers both, uniform and 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 string. G.DSI which SHALL BE obtained by the concatenation of "CPace" and the associated name of the cipher suite used for the encode_to_curve function as specified in . E.g. when using the map with the name "P384_XMD:SHA384_SSWU_NU_"
on curve NISTP384 the resulting value SHALL BE G.DSI = "CPaceP384_XMD:SHA384_SSWU_NU_".
Using the above definitions, the CPace functions required for the group object G are defined as follows.
 G.sample_scalar() SHALL return a value between 1 and (G.group_order  1). The value sampling MUST BE uniformly random. It is RECOMMENDED to use rejection sampling for converting a uniform bitstring to a uniform value between 1 and (G.group_order  1).

G.calculate_generator(H, PRS,sid,CI) function SHALL be implemented as follows.
 First gen_str = generator_string(G.DSI,PRS,CI,sid, H.s_in_bytes) is calculated.
 Then the output of a call to encode_to_curve(gen_str) is returned, using the selected function from .
 G.scalar_mult(s,X) is a function that operates on a scalar s and an input point X. The input X shall use the same encoding as produced by the G.calculate_generator method above.
G.scalar_mult(s,X) SHALL return an encoding of either the point X^s or the point X^(s) according to . Implementations SHOULD use the 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 consider encodings of the point at infinity and an encoding of a point not on the group.
Implementation verification
Any CPace implementation MUST be tested against invalid or weak point attacks.
Implementation MUST be verified to abort upon conditions where G.scalar_mult_vfy functions outputs G.I.
For testing an implementation it is RECOMMENDED to include weak or invalid points in MSGa and MSGb and introduce this
in a protocol run. It SHALL be verified that the abort condition is properly handled.
Moreover any implementation MUST be tested with respect invalid encodings of MSGa and MSGb where the length of the message
does not match the specified encoding (i.e. where the sum of the prepended length information does not match the actual length
of the message).
Corresponding test vectors are given in the appendix for all recommended cipher suites.
Security Considerations
A security proof of CPace is found in . This proof covers all recommended cipher suites included in this document.
In the following sections we describe how to protect CPace against several attack families, such as relay, length extension or side channel attacks. We also describe aspects to consider when deviating from recommended cipher suites.
Party identifiers and relay attacks
If unique strings identifying the protocol partners are included either as part of the channel identifier CI, the session id sid or the associated data fields ADa, ADb, the ISK will provide implicit authentication also regarding the party identities. Incorporating party identifier strings
is important for fending off relay attacks.
Such attacks become relevant in a setting where several parties, say, A, B and C, share the same password PRS. An adversary might relay messages from a honest user A, who aims at interacting with user B, to a party C instead. If no party identifier strings are used, and B and C use the same PRS value, A might be establishing a common ISK key with C while assuming to interact with party B.
Including and checking party identifiers can fend off such relay attacks.
Hashing and key derivation
In order to prevent analysis of length extension attacks on hash functions, all hash input strings in CPace are designed to be prefixfree strings which have the length of individual substrings prepended, enforced by the prefix_free_cat() function.
This choice was made in order to make CPace suitable also for hash function instantiations using
MerkleDamgard constructions such as SHA256 or SHA512 along the lines of .
In case that an application whishes to use another form of encoding, the guidance given in SHOULD BE considered.
Although already K is a shared value, it MUST NOT itself be used as an application key. Instead, ISK MUST BE used. Leakage of K to an adversary can lead to offline dictionary attacks.
As noted already in it is RECOMMENDED to process ISK
by use of a suitable strong key derivation function KDF (such as defined in ) first,
before using the key in a 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 as mac_key = H.hash(b"CPaceMac"  ISK).
 Then let each party send an authenticator tag Ta, Tb that is calculated over the protocol message that it has sent previously. I.e.
let party A calculate its transmitted authentication code Ta as Ta = MAC(mac_key, MSGa) and let party B calculate its transmitted
authentication code Tb as Tb = MAC(mac_key, MSGb).
 Let the receiving party check the remote authentication tag for the correct value and abort in case that it's incorrect.
Sampling of scalars
For curves over fields F_p where p is a prime close to a power of two, we recommend sampling scalars as a uniform bit string of length field_size_bits. We do so in order to reduce both, complexity of the implementation and reducing the attack surface
with respect to sidechannels for embedded systems in hostile environments.
The effect of nonuniform sampling on security was demonstrated to be begning in for the case of Curve25519 and Curve448.
This analysis however does not transfer to most curves in ShortWeierstrass form. As a result, we recommend rejection sampling if G is as in .
Singlecoordinate CPace on Montgomery curves
The recommended cipher suites for the Montgomery curves Curve25519 and Curve448 in rely on the following properties :
 The curve has order (p * c) with p prime and c a small cofactor. Also the curve's quadratic twist must be of order (p' * c') with p' prime and c' a cofactor.
 The cofactor c' of the twist MUST BE EQUAL to or an integer multiple of the cofactor c of the curve.
 Both field order q and group order p MUST BE close to a power of two along the lines of , Appendix E.
 The representation of the neutral element G.I MUST BE the same for both, the curve and its twist.
 The implementation of G.scalar_mult_vfy(y,X) MUST map all c loworder points on the curve and all c' loworder points on the twist to G.I.
Montgomery curves other than the ones recommended here can use the specifications given in , given that the above properties hold.
Nonce values
Secret scalars ya and yb MUST NOT be reused. Values for sid SHOULD NOT be reused since the composability
guarantees established by the 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.
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.
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
Thanks to the members of the CFRG 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.
Hashing to Elliptic Curves
Cloudflare, Inc.
Cornell Tech
Cloudflare, Inc.
Stanford University
Cloudflare, Inc.
This document specifies a number of algorithms for encoding or
hashing an arbitrary string to a point on an elliptic curve. This
document is a product of the Crypto Forum Research Group (CFRG) in
the IRTF.
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.
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)
US Secure Hash Algorithms (SHA and SHAbased HMAC and HKDF)
Federal Information Processing Standard, FIPS
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.
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.
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 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
]]>
Testvector for prefix_free_cat()
Examples for invalid encoded messages
The following messages are examples which have invalid encoded length fields. I.e. they are examples
where parsing for the sum of the length of subfields as expected for a message generated for the prefix free concatenation
does not give the correct length of the message. Parties MUST abort upon reception of such invalid messages as MSGa or MSGb.
Definition of generator_string function.
Definitions and test vector ordered concatenation
Definitions for lexiographical ordering
For ordered concatenation lexiographical ordering of byte sequences is used:
bytes2 using lexiographical ordering."
min_len = min (len(bytes1), len(bytes2))
for m in range(min_len):
if bytes1[m] > bytes2[m]:
return True;
elif bytes1[m] < bytes2[m]:
return False;
return len(bytes1) > len(bytes2)
]]>
Definitions for ordered concatenation
With the above definition of lexiographical ordering ordered concatenation is specified as follows.
Test vectors ordered concatenation
Decoding and Encoding functions according to RFC7748
> 8*i) & 0xff)
for i in range((bits+7)/8)])
]]>
Elligator 2 reference implementation
The Elligator 2 map requires a 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 ANSIC 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 ANSIC 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 ANSIC 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 ANSIC 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 ANSIC 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 ANSIC 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 ANSIC 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.