```
The definitions above aim at making the protocol suitable for outsourcing CPace to
secure elements (SE) where nested hash function constructions such as defined in
```
have to be considered to be particularly costly.
As a result, the task of generating session keys by a strong KDF function is left out of the scope
of the CPace protocol. This fact is expressed by the naming of the intermediate shared Key ISK.
The definitions above regarding the mapping deviate from the definition in the
encode_to_curve function from by significantly reducing the amount of hash invocations.
Moreover, the CPace protocol specification, unlike
the hash-to-curve draft specification also considers the risk of side-channel leakage during the hashing of PRS by introducing
the ZPAD padding.
Mitigating attacks of an adversary that analyzes correlations between publicly known information with the low-entropy PRS
strings was considered relevant in important settings.
We also avoid the overhead of redundant cofactor clearing, by making the Diffie-Hellman protocol responsible for this task
(and not the mapping algorithm).
Due to its use in Ed25519 , SHA512 is considered to be the natural hash choice for Curve25519.
The 512 bit output of SHA512 moreover allows for removing any statistical bias stemming from the non-canonical base field
representations, such that the overhead of the HKDF_extract/HKDF_expand sequences from
are considered not necessary (in line with the assessments regarding Curve25519 in ).

```
```

```
```
This cipher suite targets applications that do not as agressively focus on efficiency, bandwidth and code size as the
Curve25519 implementation. Instead it aims at reusing existing encoding and curve standards wherever possible.
It uses the group of points on the NIST P-256 curve which is defined in short Weierstrass form
for constructing J . The base field F is the
prime field built upon the Solinas prime p = 2^256-2^224+2^192+2^96-1.
Encoding of full group elements requires both, x and y coordinates. In order to facilitate point
validation and in order to be in line with recent TLS 1.3 requirements, implementations MUST encode
both, x and y coordinates. It is RECOMMENDED to use the
uncompressed format from using the 0x04 octet prefix. The strip_sign_information() function
returns the substring from the SEC1 representation encoding the x-coordinate of the curve point.
NIST P-256 is of prime order and does not require cofactor clearing. The scalar_cofactor_clearing function is the
identity function with scalar_cofactor_clearing(s) == s
The domain separation strings are defined as DSI1 = "CPace-P256-1", DSI2 = "CPace-P256-2".
For the scalar_mult_cc function operating on the internally generated points,
a conventional scalar multiplication on P-256 is used, i.e. without the need of further
verification checks.
The scalar_mult_ccv function that operates on remotely generated points includes the mandatory verification as follows.
First from the encoded point
the x and y coordinates are decoded. These points are used for verifying the curve equation. If the point is not on the curve,
scalar_mult_ccv returns the neutral element I. If the point is on the curve, scalar_mult_ccv calls scalar_mult_cc and returns
the result of the scalar multiplication.
For P-256, the map_to_group_mod_neg function is implemented as follows. The zero-padding string length is calculated as
len(ZPAD) = max(0, H_block_SHA256 - len(DSI1 || PRS)) with H_block_SHA256 = 64.
For the mapping to the curve, a 32 byte string
U1 = SHA256(DSI1 || PRS || ZPAD || sid || CI) is calculated. From U1 a second 32 byte value is calculated as U2 = SHA256(U1).
The concatenation of U1 and U2 is interpreted as a 512 bit integer u by use of the
u = OS2IP(U1 || U2) function from .
This value is reduced to a 32 byte representation of a field element fu = u % p. The coordinates (x,y) in F
of the secret generator G are calculated as (x,y) = map_to_curve_simple_swu_3mod4(fu) function
from .
As hash function H SHA256 is chosen, returning a session key ISK of 32 bytes length with
ISK=SHA256(DSI2 || sid || Ks || Yas || Ybs).
The following sage code could be used as reference implementation for the mapping and key derivation functions.
```
Similarly to the Curve25519 implementation, the definitions above aim at making the protocol suitable for outsourcing to
secure elements where hash function invocations have to be considered to be particularly costly.
As a result, the task of generating session keys by a strong KDF function is left out of the scope
of the CPace protocol. The naming of ISK as intermediate shared key reflects this fact.
Also the method for calculating the generator has been optimized for reducing the number of hash calculations in comparison
to the suggestions
```.

```
```

```
```

```
```
A security proof of CPace is found in .
Elements received from a peer MUST be checked by a proper implementation of the scalar_mult_ccv method.
Failure to properly validate group elements can lead to attacks. The Curve25519-based cipher suite employs
the twist security feature of the curve for point validation.
As such, it is mandatory to check that all low-order points on both
the curve and the twist are
mapped on the neutral element by the X25519 function. Corresponding test vectors are provided in the
appendix.
The choices of random numbers MUST be uniform. Randomly generated values (e.g., ya and yb)
MUST NOT be reused.
CPace is NOT RECOMMENDED to be used in conjunction with applications supporting different username/password pairs.
In this case it is RECOMMENDED to use CPace as building block of the augmented AuCPace protocol.
If CPace is used as a building block of higher-level protocols, it is RECOMMENDED that sid
is generated by the higher-level protocol and passed to CPace. It is RECOMMENDED sid,
is generated by sampling ephemeral random strings.
Since CPace is designed to be used as a building block in higher-level protocols and for
compatibility with constrained hardware,
it does not by itself include a strong KDF construction. CPace uses a simple hash operation for generating its
intermediate key ISK.
It is RECOMMENDED that the ISK is post-processed by a KDF according the needs of the higher-level protocol. In case
that the CPace protocol is delegated to a secure element hardware, it is RECOMMENDED that the main processing unit
applies a KDF to the externally generated ISK.
In case that side-channel attacks are to be considered practical for a given application, it is RECOMMENDED to focus
side-channel protections such as masking and redundant execution (faults) on the process of calculating
the secret generator G. The most critical aspect to consider is the processing of the first block of the hash that includes
the PRS string. The CPace protocol construction considers the fact that side-channel protections of hash functions might
be particularly resource hungry. For this reason, CPace aims at minimizing the number of hash functions invocations in the
specified mapping method.
CPace is proven secure under the hardness of the computational Diffie-Hellmann (CDH)
and the computational Double-Diffie-Hellmann
assumptions in the group J.
Still, even for the event that large-scale quantum computers (LSQC) will become available, CPace forces an active
adversary to solve one CDH per password guess. Using the wording suggested by S. Tobutu on the CFRG mailing list,
CPace is "quantum-annoying".
For the event that LSQC become ubiquitous, it is suggested to consider
the replacement of the group operations used in CPace with a corresponding commutative group actions on isogenies,
such as suggested in . The fact that CPace does not require arbitrary group operations
but only the operation set
available in a group modulo negation allows for commutative isogeny-based group actions cryptography as a drop-in
replacement.
No IANA action is required.
Thanks
to the members of the CFRG for
comments and advice. Any comment and advice is appreciated.
Comments are specifically invited regarding
the following aspect. The CPace mapping function design is based on the following
assessments. 1.) Masked, hardware-side-channel-protected hash function implementations
should be considered highly desirable for the calculation of the generators G if an implementation
might be exposed to physical attacks.
2.) The complexity of such protected hash implementations (possibly with lots of boolean-arithmetic
masking conversions) was assessed critical for constrained hardware. Hash operation complexity
was also assessed to be critical for secure element
chipsets that often were assessed to run hash operations in software without hardware accellerator support.
This assessment is not in line with the assumptions for the hash-to-curve-05 draft.
As a consequence, this draft aimed at more aggressively reducing the number of nested hash
function invocations in comparison to the suggestions of the hash-to-curve-05 draft.

```
```
STANDARDS FOR EFFICIENT CRYPTOGRAPHY, "SEC 1: Elliptic Curve
Cryptography", version 2.0
SEC
&RFC2119;
&RFC5480;
&RFC5869;
&RFC6234;
&RFC7748;
&RFC7914;
&RFC8032;
&RFC8174;
draft-irtf-cfrg-hash-to-curve-05
IRTF draft standard
"Standard Specifications for Public Key Cryptography", IEEE 1363
IEEE 1363
AuCPace. PAKE protocol tailored for the use in the internet of things.
eprint.iacr.org/2018/286
An Isogeny-Based Password-Authenticated Key Establishment Protocol.
eprint.iacr.org/2018/886
The test vectors for CPace25519 consist of three blocks.
First test vectors for X25519 are provided which is used as
combined scalar multiplication, cofactor clearing and verification
function. Specifically, test vectors for the small order points
are provided for checking that all small order points are mapped to
the neutral element
Then test vectors for the Elligator2 primitive are provided.
Then test vectors for the encoding of the secret generator are provided combining
the hash operation and the encoding of the generator.
Finally test vectors for a honest party protocol execution are provided, including
derivation of the session key ISK.
Two test vectors are provided

```
```