]> Apple, Inc.

jelle_v_vos@apple.com

University of California, Irvine

sjarecki@ics.uci.edu

Apple, Inc.

caw@heapingbits.net

This document describes the CPaceOQUAKE+ protocol, a hybrid asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting secure against quantum-capable attackers. CPaceOQUAKE+ is composed of two stages — CPace and OQUAKE+ — that run sequentially, with the output of CPace feeding as the secret_context into OQUAKE+. OQUAKE+ is an augmented variant of OQUAKE that adds password confirmation. This document also describes standalone OQUAKE+, a post-quantum aPAKE, and CPaceOQUAKE, the hybrid symmetric PAKE composed of the CPace and OQUAKE stages. This document recommends configurations for CPaceOQUAKE+. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the CFRG Crypto Forum Research Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Asymmetric (or Augmented) Password Authenticated Key Exchange (aPAKE) protocols are designed to provide password authentication and mutually authenticated key exchange in a client-server setting without relying on a public key infrastructure (PKI) and without disclosing passwords to servers or other entities other than the client machine. The only stage where PKI is required is during a client's registration. In the asymmetric PAKE setting, the client first registers a password verifier with the server. A verifier is a value that is derived from the password and which the server will later use to verify the client knowledge of the password. After registration, the client uses its password and the server uses the corresponding verifier to establish an authenticated shared secret such that the server learns nothing of the client's password. OPAQUE-3DH and SPAKE2+ are two examples of specified aPAKE protocols. These protocols provide security in classical threat models. However, in the presence of a quantum-capable attacker, both OPAQUE and SPAKE2+ fail to provide the desired level of security. Both protocols are vulnerable to a Harvest Now, Decrypt Later (HNDL) attack executed by a quantum-capable attacker, in which the attacker learns the shared secret and uses it to compromise application traffic. For a password-authenticated protocol, this HNDL threat is more severe than for plain (unauthenticated) key exchange: breaking underlying classical assumption of a PAKE that is not unconditionally password hiding does not merely disclose the traffic of one harvested session, but can retroactively recover the password itself from the harvested transcript. Since passwords are long-lived credentials, this grants a quantum-capable attacker indefinite impersonation capability rather than a one-time confidentiality loss; see for a detailed treatment of this attack. Upgrading both protocols to provide post-quantum security is non-trivial, especially as there are no known efficient constructions for certain building blocks used in these protocols (such as the OPRF used in OPAQUE-3DH). As the threat of quantum-capable attackers looms, the viability of existing aPAKE protocols in practice diminishes in time. This document describes the CPaceOQUAKE+ protocol, an aPAKE that supports mutual authentication in a client-server setting secure against quantum-capable attackers. CPaceOQUAKE+ is composed of two stages that run sequentially: CPace and OQUAKE+. The design securely composes multiple existing primitives . This document fully specifies CPaceOQUAKE+ and all dependencies necessary to implement it. provides recommended configurations.

Use Cases PAKE deployments vary along two largely independent dimensions: how long a password is used for, and what role the PAKE plays in the surrounding protocol. A password can be an ephemeral, high-entropy, one-time secret (e.g., a pairing code shown on a screen), or a long-lived, human-memorable credential that is reused across many protocol runs. Independently, the PAKE can be the mechanism that establishes the resulting secure channel, or it can run over a channel that is already secure for other reasons, in which case the PAKE serves only to confirm knowledge of the password over that channel. Crossing these two dimensions gives four cases, which helps clarify which deployments motivate a post-quantum aPAKE such as CPaceOQUAKE+, and which do not.

1. Device pairing (ephemeral password; PAKE establishes the channel). Two devices bootstrap a secure channel using a short-lived, high-entropy, one-time password or PIN, e.g., displayed on one device and typed into the other. A quantum-capable attacker is only relevant here if a post-quantum threat model is assumed at all, and even then this is a comparatively weak motivating example for a PQ-PAKE: because the password is used exactly once, retroactively recovering it (see ) has little value to an attacker, as there is no future session to impersonate. HNDL against the resulting channel's traffic remains a legitimate concern, but that concern is the same one that motivates post-quantum key exchange generally and is not specific to the PAKE.
2. Password confirmation over an already-secure channel (long-lived password; PAKE does not establish the channel). The channel's confidentiality and post-quantum security come from elsewhere, e.g., a hybrid KEM used in the surrounding transport protocol, and the PAKE is used only to bind knowledge of a long-lived password to that channel. The full machinery of a PQ aPAKE is not required to realize this case in isolation. Notably, this document's own OQUAKE+ design internally contains a version of this case: the password-confirmation (PC) sub-stage described in confirms the password over a channel already established by the preceding KEM-based exchange, layered on top of case 3 below.
3. Long-lived-password pairing (long-lived password; PAKE establishes the channel). This is the classic aPAKE deployment, e.g., a client authenticating to a server with an account password. It is also the case where retroactive password recovery is most damaging: because the password is reused indefinitely, recovering it does not merely disclose one harvested session's traffic, it lets the attacker impersonate the client in every future session until the password is changed. This is the primary use case targeted by CPaceOQUAKE+.
4. Degenerate case (ephemeral password; PAKE does not establish the channel). Included only for completeness of the taxonomy above; it is not a realistic deployment, since there is little reason to spend a one-time password confirming a channel that the password neither secures nor will be reused for.

A PQ PAKE -- and a hybrid PQ PAKE in particular -- helps address cases 1 and 3, closing the gap on this protocol needed for such use cases in practice.

Related Work This section relates CPaceOQUAKE+ to existing standardized PAKEs and to the broader post-quantum PAKE research literature, and addresses why this problem is not already solved, why it remains an active research problem, and why the state of the art is nonetheless mature enough for CFRG to engage with it.

Existing Solutions and Their Gaps OPAQUE-3DH and SPAKE2+ are standardized aPAKEs, and CPace is an emerging symmetric PAKE, but all three are purely classical constructions: none provide security against a quantum-capable attacker. NIST's post-quantum cryptography standardization effort has, to date, produced key encapsulation mechanisms and signature schemes, but no PAKE. A seemingly obvious fix is to run an existing classical PAKE inside, or alongside, a post-quantum or hybrid KEM already deployed at the transport layer (e.g., hybrid key exchange in TLS 1.3). This does not solve the PAKE-specific problem: it protects the resulting session key against a future quantum-capable attacker, but does nothing for the classical PAKE's own handshake transcript. If that classical PAKE's underlying hard problem is later broken, the password itself becomes retroactively recoverable from the harvested transcript, as detailed in , independent of whatever post-quantum protection was applied to the surrounding transport. This is the concrete gap that simply layering a post-quantum KEM around an existing classical PAKE does not close, and it is the gap this document addresses directly.

Ongoing Research [[EDITOR'S NOTE: remove in the final version of this document]] The compiler techniques underlying this document's design are recent and remain under active development. The KEM-to-PAKE compiler underlying OQUAKE , the timing side-channel fix required to use it safely with ML-KEM , the PAKE combiners used to hybridize it with CPace , and closely related asymmetric PAKE compilers were all published in 2024 and 2025. The security analysis backing this document's specific composition is similarly new. Concretely, identifies and fixes a timing side channel in OQUAKE's ML-KEM key-generation step (see ) that was only discovered in 2025, after OQUAKE's core compiler had already been analyzed, illustrating that this design space is still being hardened rather than settled. Likewise, this document currently carries an open issue regarding whether OQUAKE's proof of security extends to the UC bare PAKE model without requiring party or session identifiers (see ); this extension is believed to hold on the basis of the existing NoIC/OQUAKE analysis in but has not yet been published. Finally, no single compiler approach has yet converged as the preferred solution across the range of use cases in : designs optimized for case 3 (this document's target) make different tradeoffs than designs optimized for, e.g., case 1 or case 2.

Readiness for CFRG Engagement [[EDITOR'S NOTE: remove in the final version of this document]] Despite being new, the core sequential-composition design in this document has already been independently analyzed by at least three different groups (see ), which substantially increases confidence in the design beyond what a single analysis would provide. This document's source also includes concrete test vectors for each protocol it specifies, to support independent implementation and verification. The remaining gaps identified above, most notably the unpublished bare-PAKE proof extension and the open question of identity requirements, are well-scoped and do not call the core design into question; they are the kind of item best resolved through the scrutiny that CFRG engagement itself provides, rather than a prerequisite to starting that engagement.

Conventions and Definitions 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.

Notation and Terminology The following functions and operators are used throughout the document.

• The function random(n) generates a cryptographically secure pseudorandom byte string of length n bytes.
• The associative binary operator || denotes concatenation of two byte strings.
• The binary function XOR(a, b) denotes an element-wise XOR operation between two byte strings a and b of the same length.
• The functions bytes_to_int and int_to_bytes convert byte strings to and from non-negative integers. bytes_to_int and int_to_bytes are implemented as OS2IP and I2OSP as described in , respectively.
• The function lv_encode encodes a byte string with a two-byte, big-endian length prefix. For example, lv_enode((0x00, 0x01, 0x02)) = (0x00, 0x03, 0x00, 0x01, 0x02). The function lv_decode parses a byte string that is expected to be encoded with a two-byte length preceding the remaining bytes, e.g., lv_decode((0x00, 0x03, 0x00, 0x01, 0x02)) = (0x00, 0x01, 0x02). Note that lv_decode can fail when the length of the actual bytes does not match that encoded in the prefix. For example, lv_decode((0xFF, 0xFF, 0x00)) will fail.
• The notation bytes[l..h] refers to the slice of byte array bytes starting at index l and ending at index h-1. For example, given bytes = (0x00, 0x01, 0x02), then bytes[0..1] = 0x00 and bytes[0..3] = (0x00, 0x01, 0x02). Similarly, the notation bytes[l..] refers to the slice of the byte array bytes starting at l until the end of bytes, i.e.., bytes[l..] = bytes[l..len(bytes)].

All algorithms and procedures described in this document are laid out in a Python-like pseudocode. Each function takes a set of inputs and parameters and produces a set of output values. Parameters become constant values once the protocol variant and the configuration are fixed.

Overview This document aims to specify two protocols: a symmetric and an asymmetric hybrid PAKE. In the symmetric PAKE setting, the client and server share a password and use it to establish an authenticated shared secret. In the asymmetric PAKE setting, the client first registers a password verifier with the server. A verifier is a value that is derived from the password and which the client will later use to demonstrate knowledge of the password. After registration, the client uses its password and the server uses the corresponding verifier to establish an authenticated shared secret such that the server learns nothing of the client's password. The protocols specified in this document are built from two stages:

1. CPace : A classical elliptic curve-based symmetric PAKE.
2. OQUAKE: A new post-quantum symmetric PAKE built from a BUA-sKEM; see .

An abstract overview of CPaceOQUAKE is shown in the figure below. +---->| (Stage 1)|<-----+<---- PRS +----------+ | SK1 | +----v-----+ | OQUAKE | | (Stage 2)| +----------+ | | | | client_key <--------+ +------> server_key ]]> Additionally, the document specifies OQUAKE+, an augmented variant of OQUAKE that adds password confirmation to upgrade the symmetric PAKE to an asymmetric PAKE; see . These building blocks are composed into the following named protocols:

• CPaceOQUAKE: A hybrid symmetric PAKE combining CPace and OQUAKE.
• OQUAKE+: A post-quantum aPAKE; see .
• CPaceOQUAKE+: A hybrid aPAKE combining CPace and OQUAKE+.

An abstract overview of CPaceOQUAKE+ is shown in the figure below. +---->| (Stage 1)|<-----+<---- Verifier | +----------+ | | | | | sec_ctx=SK1 | | | | | +----------+ | | | OQUAKE+ | | Verifier---->+---->| (Stage 2)|<-----+<---- Verifier seed | | Public key +----------+ | | | | client_key <--------+ +------> server_key ]]> We note that this standard only specifies the compositions listed above. It is not necessarily true that one can securely compose all PAKEs this way. The rest of this document specifies CPaceOQUAKE+ and its dependencies. specifies CPace and OQUAKE as individual stages and their composition into CPaceOQUAKE. specifies OQUAKE+ and its composition with CPace into CPaceOQUAKE+. Each of these pieces build upon the cryptographic dependencies specified in .

Cryptographic Dependencies The protocols in this document have four primary dependencies:

• Key Encapsulation Mechanism (KEM);
• Splittable Binary Key Encapsulation Mechanism with specific uniformity properties (binary UPK-ANO-KEM, or BUA-sKEM);
• Key Derivation Function (KDF);
• Key Stretching Function (KSF);

specifies different combinations of each of these dependencies that are suitable for implementation.

Key Encapsulation Mechanism A Key Encapsulation Mechanism (KEM) is an algorithm that is used for exchanging a secret from one party to another. We require an IND-CCA-secure KEM with key derivation from a seed. It consists of the following syntax.

• DeriveKeyPair(seed): Deterministic algorithm to derive a key pair (sk, pk) from the byte string seed, where seed MUST have Nseed bytes.
• Encaps(pk): Randomized algorithm to generate an ephemeral, fixed-length symmetric key (the KEM shared secret) and a fixed-length encapsulation of that key that can be decapsulated by the holder of the secret key corresponding to pk. This function can raise an EncapsError on encapsulation failure.
• Decaps(ct, sk): Deterministic algorithm using the secret key sk to recover the ephemeral symmetric key (the KEM shared secret) from its encapsulated representation ct. This function can raise a DecapsError on decapsulation failure.
• Nseed: The length in bytes of the seed used to derive a key pair.
• Nct: The length in bytes of an encapsulated key produced by this KEM.
• Npk: The length in bytes of a public key for this KEM.

This specification uses X-Wing .

Splittable binary UPK-ANO-KEM A binary UPK-ANO-KEM supports the same functions as defined above for a KEM, and it must also be IND-CCA secure, but it must also achieve two additional security properties. Namely, in addition to IND-CCA security, a binary UPK-ANO-KEM requires that:

1. Public keys are indistinguishable from random strings of bytes (of the same length), i.e. uniform public keys (UPK); and
2. Ciphertexts are anonymous in the presence of chosen ciphertext attack (ANO-CCA), i.e. anonymous ciphertexts (ANO).

These additional properties are crucial for the security of OQUAKE. In other words, one MUST NOT use a KEM that has no uniform public keys and/or no anonymous ciphertexts in place of a UPK-ANO-KEM. In this specification, we also require a third property: the KEM must be splittable. A splittable KEM (sKEM) implements the Split(pk) -> (t, ⍴) function and its inverse, which takes a public key and splits it into a part ⍴ that is indepdendent of the KEM's secret key and can therefore be made public, and a part t that does depend on the secret key. This property allows parties to perform variable-time operations on ⍴ without revealing information about the secret key. We use N⍴ to denote the byte-length of ⍴ and Nt to denote the byte-length of t. We use Combine(t, ⍴) -> pk to refer to the inverse operation of Split. In the remainder of this specification, we abbreviate 'splittable binary UPK-ANO-KEM' as BUA-sKEM. This specification uses a variant of ML-KEM1024 , which we therefore denote by ML-BUA-sKEM1024. It is specified in . This is instantiated with "KemeleonNR - ML-KEM1024" . Note that, while Kemeleon provides uniform encoding for KEM ciphertexts and public keys, we only require uniform enoding for public keys. Future specifications can replace ML-BUA-sKEM1024 with another splittable binary UPK-ANO-KEM that is more efficient if one becomes available.

Key Derivation Function A Key Derivation Function (KDF) is a function that takes some source of initial keying material and uses it to derive one or more cryptographically strong keys. This specification uses a KDF with the following API and parameters:

• Extract(salt, ikm): Extract a pseudorandom key of fixed length Nx bytes from input keying material ikm and an optional byte string salt.
• Expand(prk, info, L): Expand a pseudorandom key prk using the optional string info into L bytes of output keying material.
• Nx: The output size of the Extract() function in bytes.

Key Stretching Function This specification makes use of a Key Stretching Function (KSF), which is a slow and expensive cryptographic hash function with the following API:

• Stretch(msg, salt, L): Apply a key stretching function to stretch the input msg and salt salt, hardening it against offline dictionary attacks. This function also needs to satisfy collision resistance. The output is a string of L bytes.

ML-BUA-sKEM: A BUA-sKEM around ML-KEM

Splittable ML-KEM ML-KEM is already specified in a way that allows one to separate out the part of the public key that does not depend on the secret key; this feature is also used in Kemeleon . The Split function is defined as follows for ML-KEM . The part of the public key that does not depend on the secret key represents the final 32 bytes. For this reason, Nt = ML-KEM.Npk - 32 and N⍴ = 32. For ML-KEM, the inverse of the split operation is concatenation.

ML-BUA-sKEM Key Derivation The design of ML-BUA-sKEM is such that it does not change the internals of ML-KEM; it only uses the Split function. To ensure that the public key generated by ML-BUA-sKEM.DeriveKeyPair is binary and uniform, it uses Kemeleon to (re-)encode ML-KEM's public keys. In the PAKEs described in this specification, it is crucial that this happens in constant time. For this reason, ML-BUA-sKEM uses the non-rejection sampling variants of Kemeleon, as denoted by VectorEncodeNR and VectorDecodeNR. ML-BUA-sKEM is defined as follows. The uniform public keys produced by ML-BUA-sKEM are longer than those produced by ML-KEM. The final 32 bytes of the public key still represent the part that does not depend on the secret key. For ML-BUA-sKEM, the inverse of the split operation is concatenation.

ML-BUA-sKEM Encapsulation & Decapsulation ML-BUA-sKEM encapsulation undoes the uniform encoding performed during key derivation before calling ML-KEM.Encaps on the non-uniform public key. The decapsulation procedure for ML-BUA-sKEM is exactly the same as for ML-KEM.

CPaceOQUAKE Protocol The hybrid, symmetric PAKE protocol, denoted CPaceOQUAKE consists of CPace combined with OQUAKE . OQUAKE is a PAKE built from a BUA-sKEM and KDF, using a 2-rounds of Feistel network to password-encrypt the BUA-sKEM public key. The OQUAKE protocol is based on the "NoIC" protocol analyzed in . The CPaceOQUAKE protocol is based on the `Sequential PAKE Combiner' protocol proposed by . A very close variant of this protocol was also analyzed in . At a high level, CPaceOQUAKE is a four-message protocol that runs between client and server wherein, upon completion, both parties share the same session key if they agree on the password-related string (PRS). Otherwise, they obtain random session keys. This is summarized in the diagram below. +---->| (Stage 1)|<-----+<---- PRS +----------+ | SK1 | +----v-----+ | OQUAKE | | (Stage 2)| +----------+ | | | | client_key <--------+ +------> server_key ]]> CPaceOQUAKE composes CPace and OQUAKE by first running CPace to completion between client and server, and then running OQUAKE with the CPace session key provided as the secret_context. We explain the composition in more detail in . All PAKEs in this document share a common interface. Each takes as input a password-related string PRS (or a verifier derived from it), a public_context, and a secret_context. The public_context binds public session information that both parties agree on, such as an optional session identifier sid and optional client and server identifiers U and S (e.g., a device identifier, an IP address, or a URL). The secret_context binds confidential information shared by both parties, such as the session key of a preceding protocol stage; it is never sent on the wire. Both the public_context and the secret_context are optional; a party that does not use one passes the empty string b"" (equivalently, None). Two parties obtain matching session keys only if their PRS, public_context, and secret_context match. See for more discussion about the identities and how they are chosen in practice. The public_context is constructed from the optional sid, U, and S using the following utility function. Each of sid, U, and S is optional and defaults to the empty string b"". Applications MAY include additional public information by prepending or appending it to the returned value.

CPace Specification CPace is a classical elliptic curve-based PAKE . This section wraps the CPace specification in a consistent interface. We use an interactive version of CPace that takes two rounds, in which there is a designated initiator and responder. In other words, the responder only starts executing the protocol after it received the first message from the initiator. The flow of the protocol consists of two messages sent between initiator and responder, produced by the functions Init, Respond, and Finish, described below. Both parties take as input a password-related string PRS, a public_context, and a secret_context (see ). Upon completion, both parties obtain matching session keys if their PRS, public_context, secret_context, and key length (specified by N) match. Otherwise, they obtain random keys. In exceptional cases, the protocol aborts. CPace derives its generator from PRS, a channel identifier (CI), and a session identifier (sid); CI may carry confidential information and is never sent on the wire, whereas sid is public and is additionally bound into the session key. Accordingly, CPace uses the secret_context as its CI and the public_context as its sid.

Initiation The initiator starts the protocol using its password-related string PRS, binding the session to the public_context and secret_context.

Response The responder performs the same actions as the initiator. Since it already received the initiator's message, it can immediately finish its execution of the protocol. It outputs the shared secret and a message Yb intended to be sent to the initiator. The functions lv_cat and transcript are defined in .

Finish The initiator finishes the protocol by combining the discrete logarithm ya generated by CPace.Init and the message Yb received from the responder.

OQUAKE Specification OQUAKE is a PAKE built on a BUA-sKEM and KDF. If the BUA-sKEM provides security against quantum-enabled attacks, then so does OQUAKE. It consists of two messages sent between initiator and responder, produced by the functions Init, Respond, and Finish, described below. Both parties take as input a password-related string PRS, a public_context, and a secret_context. Upon completion, both parties obtain matching session keys if their PRS, public_context, secret_context, and key length (specified by N) match. Otherwise, they obtain random session keys. When a secret_context is provided, OQUAKE derives an effective password from (PRS, secret_context) and uses it in place of PRS throughout the protocol. This allows OQUAKE to be securely composed with a preceding protocol stage whose output key is provided as the secret_context. The public_context (see ) typically encodes a session identifier sid and client and server identifiers U and S. It has the following requirements. If a client and server identifier are provided:

• The session identifier must match between the client and server
• This session identifier has not been used before in a session between the client and server

If no client and server identifiers are provided:

• The session identifier must match between the client and server
• This session identifier has not been used before by the client or server in any session with any other party

These requirements originate from the security proof for OQUAKE. If these requirements are not met, the proof does not apply, but this does not mean that the protocol becomes vulnerable. The specification follows the design as presented in , with the splittable KEM technique described in , which prevents timing attacks caused by rejection sampling in ML-KEM. See for more information on the timing attack and this fix.

Initiation Init takes as input the initiator's PRS, a public_context, and a secret_context. It produces a state for the initiator to store, as well as a protocol message that is sent to the responder. Its implementation is as follows.

Response Respond takes as input the PRS, a public_context, a secret_context, and the initiator's protocol message. It produces a 32-byte symmetric key and a protocol message intended to be sent to the initiator. Its implementation is as follows.

Finish Finish takes as input the initiator-created state that is output from Init as well as the responder's reply message resp_msg. It produces a symmetric key that is output to the initiator. Its implementation is as follows.

Composition of CPace & OQUAKE CPaceOQUAKE is a sequential composition of CPace (see ) and OQUAKE (see ). Whereas running CPace and OQUAKE in parallel realizes a worst-of-both worlds PAKE, this sequential composition realizes a best-of-both worlds PAKE. In other words, CPaceOQUAKE remains as secure as the strongest PAKE, resisting attacks that break the classical CPace (e.g. by a quantum-capable attacker) or attacks that break the quantum-resistant OQUAKE (e.g. by a flaw in the BUA-sKEM). This assumes that OQUAKE is instantiated with a quantum-resistant BUA-sKEM. The reason a parallel combiner does not achieve best-of-both-worlds security is that it requires both constituent PAKEs to be unconditionally password hiding, meaning that the password must not be learnable even if all computational assumptions underlying the PAKE break. Intuitively, if one PAKE is not unconditionally password hiding, an attacker that breaks its computational assumptions can recover the password, and knowing the password is sufficient to then defeat the other PAKE as well. CPace is unconditionally password hiding in the sense that, even if the Diffie-Hellman assumption fails, the protocol transcript (including the exchanged group elements) is statistically independent of the password-related string PRS: PRS is only used to derive a generator, while the transmitted points are fresh random scalar multiples of this generator and hence are uniformly distributed in the group. OQUAKE, however, is not unconditionally password hiding: an attacker that can break the D-MLWE assumption can distinguish ML-KEM public keys and ciphertexts from random bitstrings and thereby mount offline dictionary attacks to recover the password. Because no currently known post-quantum PAKE built on standard primitives such as ML-KEM achieves unconditional password hiding, a parallel combiner cannot provide the desired hybrid security guarantee. The sequential combiner overcomes this limitation. Instead of running OQUAKE on the original password-related string PRS, CPaceOQUAKE feeds the CPace session key to OQUAKE as the secret_context, which binds the original PRS to the CPace session key. Even if an attacker breaks D-MLWE and can distinguish OQUAKE public keys and ciphertexts, offline dictionary attacks against the original PRS are infeasible because the CPace-derived session key material is computationally indistinguishable from a random value (under the gap Diffie-Hellman assumption). The sequential composition is analyzed in and a close variant is analyzed in . To be precise, CPaceOQUAKE first runs CPace to completion using password-related string PRS, establishing a session key SK1. It then runs OQUAKE using PRS and secret_context=SK1. OQUAKE derives an effective password from (PRS, SK1) and uses it throughout the protocol, producing session key SK2. The CPaceOQUAKE session key is SK2, which transitively depends on SK1 through the effective password derivation. This is outlined in the diagram below. CPace is initiated by the client, and OQUAKE is also initiated by the client after CPace completes. Unlike OQUAKE, CPaceOQUAKE does not require a shared session identifier sid, although this is strongly recommended. If no sid is provided, CPace will run without an sid, and OQUAKE will use a random string generated with random material provided by both parties. If an sid is provided, both CPace and OQUAKE will use this sid. An overview of the protocol flow is shown below. The protocol has five functions. Init, InitiatorContinue, and InitiatorFinish are intended to be called by the client, and Respond and ResponderFinish are intended to be called by the server. | | | | ctx, msg2 = | CPaceOQUAKE.Respond(PRS,pub_ctx,sec_ctx,msg1) | | | msg2 | |<----------------------------| | | ctx, msg3 = | CPaceOQUAKE.InitiatorContinue( | PRS,pub_ctx,sec_ctx,ctx,msg2) | | | | msg3 | |---------------------------->| | | | server_key, msg4 = | CPaceOQUAKE.ResponderFinish( | PRS,pub_ctx,sec_ctx,ctx,msg3) | | | msg4 | |<----------------------------| | | client_key = | CPaceOQUAKE.InitiatorFinish(ctx,msg4) | | | ----------------------------------------- output client_key output server_key ]]>

Client Initiation The client initiates a CPace exchange with the server using input PRS, a public_context, and a secret_context. The output of this process is some state for completing the protocol and a protocol message. The client sends this message to the server.

Server Response The server processes the client message using its input PRS, a public_context, and a secret_context. The server responds to the CPace session that the client initiated, completing Stage 1. The server MUST ensure that exactly one of s1 and a sid in the public_context exists. It MUST abort if the message does not have the correct length.

Client Continue The client finishes CPace (Stage 1) and initiates OQUAKE (Stage 2). The client derives the CPace session key, then uses it as the secret_context for OQUAKE. The output is a new state and an OQUAKE init message to send to the server. The client must ensure that exactly one of (s1, s2) and a sid in the public_context exists. The client should abort when the message does not have the correct length.

Server Finish The server completes the protocol by responding to the OQUAKE session (Stage 2). The server uses the CPace session key from Stage 1 as the secret_context for OQUAKE. The OQUAKE output key is the CPaceOQUAKE session key. The server should abort when the message does not have the correct length.

Client Finish The client finishes the protocol by completing OQUAKE (Stage 2). The OQUAKE output key is the CPaceOQUAKE session key.

CPaceOQUAKE+ Protocol CPaceOQUAKE+ is the five-message aPAKE resulting from composing CPace (Stage 1) and OQUAKE+ (Stage 2). At a high level, this involves running CPace on a verifier of the client's password, followed by OQUAKE+, which performs the post-quantum key exchange and password confirmation in a single stage. To ensure that the client does indeed know the password pertaining to that verifier, the OQUAKE+ stage uses a seed derived from the password. Both the verifier and the seed are derived from the password using a key stretching function. The seed is later used to derive a KEM public key. We refer to the collection of the verifier and this public key as 'the verifiers'. This document also specifies standalone OQUAKE+ (see ), a post-quantum aPAKE that uses the OQUAKE+ stage without the classical CPace stage. The CPaceOQUAKE+ protocol can be seen as a close variant (and a specific instance) of the `augmented PAKE' construction presented in and in .

Registering Clients This subsection specifies functions for generating the verifiers and a protocol for registering clients.

Generating Verifiers Verifiers are random-looking value derived from password-related strings from which it is computionally impractical to derive the password-related string. To make verifiers unique between different users with the same password or servers that they interact with, we employ a salt, a user account identifier, and an optional server identifier. The material required for the verifiers is generated as follows: To derive an actual public key from the verifier material, we use the following function: The server MUST store pk; it MUST NOT store seed.

Registration The registration phase consists of one message sent from the client to the server. This message contains the verifier, a public key, and 32-byte salt. The server stores this information corresponding to the client for future use in the verification flow. This phase requires a secure channel from client to server in order to transfer the password verifier and public key. The salt can be sent in plain text. We recommend that the salt is a random byte string: salt = random(32). However, in practice this may require an additional communication flow, used by the server to send the salt to the client before protocol CPaceOQUAKE+ starts. Instead, one may consider deriving the salt from some client-specific value that it knows and can retain locally. A high level flow overview of the registration flow is below. | | | | Store (salt, v, pk, U, S) | | --------------------------------------- ]]>

The OQUAKE+ Stage OQUAKE+ is an augmented variant of OQUAKE that adds password confirmation to upgrade the symmetric PAKE to an asymmetric PAKE. It uses the registered verifiers from the previous subsection. In the OQUAKE+ stage, the client proves knowledge of its password without revealing it by responding to a challenge from the server. OQUAKE+ is parameterized by a BUA-sKEM, KEM, KDF, and KSF; see for specific parameter configurations. OQUAKE+ is a three-message flow between the client and server. The client initiates the OQUAKE key exchange. The server responds with the OQUAKE key exchange response and a password confirmation challenge (piggybacked into a single message). The client completes the OQUAKE key exchange, then responds to the challenge. A high level overview of this flow is below. | | | | ctx, msg2 = OQUAKE+.Respond( | v, pub_ctx, sec_ctx, msg1, pk) | | | msg2 | |<--------------------------| | | client_key, msg3 = OQUAKE+.Finish( | ctx, seed, msg2, pub_ctx) | | | | msg3 | |-------------------------->| | | | server_key = OQUAKE+.Verify(ctx, msg3) | | --------------------------------------- output client_key output server_key ]]>

Initiation Init takes the same inputs as OQUAKE.Init and produces the same outputs. It is defined identically to OQUAKE.Init (see ).

Response Respond takes as input the PRS, a public_context, a secret_context, the initiator's protocol message, and the client's registered public key. It produces an opaque state and a protocol message that combines the OQUAKE response with a password confirmation challenge. The implementation MUST NOT reveal server_key from the state.

Finish Finish takes as input the initiator-created state from Init, the seed used to derive the KEM key pair during registration, the responder's combined reply message, and the public_context. The client completes the OQUAKE key exchange to recover the shared secret, then uses it to decrypt the password confirmation challenge. The client re-derives the KEM key pair from the seed and decapsulates the KEM ciphertext to recover the shared secret and derive password confirmation values and a new shared secret. The client checks that the server-provided confirmation value matches its own and aborts if not. Otherwise, it returns its own password confirmation value. The client outputs the new shared secret as its output.

Verify Upon receipt of the response, the server validates that the password confirmation value matches its own value. If the value does not match, the server aborts. Otherwise, the server outputs the new shared secret as its output.

Standalone OQUAKE+ OQUAKE+ can be used as a standalone post-quantum aPAKE without the classical CPace stage. The client runs OQUAKE+ with the verifier as the password-related string, and uses the seed to respond to the password confirmation challenge. Standalone OQUAKE+ consists of three messages: | | | | ctx, msg2 = OQUAKE+.Respond(v,pub_ctx,None,msg1,pk) | | | msg2 | |<---------------------------------| | | client_key, msg3 = OQUAKE+.Finish(ctx,seed,msg2,pub_ctx) | | | msg3 | |--------------------------------->| | | | server_key = OQUAKE+.Verify(ctx,msg3) | | ---------------------------------------- output client_key output server_key ]]>

Composition of CPace & OQUAKE+ CPaceOQUAKE+ is the composition of CPace (Stage 1) and OQUAKE+ (Stage 2). It is a hybrid aPAKE that provides security against both classical and quantum-capable attackers. The composition is strictly sequential. First, the parties run CPace using the verifier derived from the client's password. The client recovers this verifier using the GenVerifierMaterial function. After CPace completes, the parties proceed with OQUAKE+, which is initiated by the client. The server uses the stored public key to challenge the client, and the client uses the seed produced by GenVerifierMaterial to prove knowledge of the password. This seed MUST remain secret to prevent impersonation. An overview of the composition is below. +---->| (Stage 1)|<-----+<---- Verifier | +----------+ | | | | | sec_ctx=SK1 | | | | | +----------+ | | | OQUAKE+ | | Verifier---->+---->| (Stage 2)|<-----+<---- Verifier seed | | Public key +----------+ | | | | client_key <--------+ +------> server_key ]]> Upon successful completion of the entire protocol, the client and server will share a symmetric key that was authenticated by knowledge of the password. The protocol aborts if the password did not match. The protocol flows are shown below. Note here that if the client does not know the salt, the server must send it to the client before the protocol starts, which it can do in plain text. | | | | ctx, msg2 = CPaceOQUAKE+.Respond(v,pub_ctx,None,msg1) | | | msg2 | |<---------------------------------| | | Stage 2: OQUAKE+ | | | ctx, msg3 = CPaceOQUAKE+.InitiatorContinue( | v,pub_ctx,None,ctx,msg2) | | msg3 | |--------------------------------->| | | | ctx, msg4 = CPaceOQUAKE+.ResponderContinue( | v,pub_ctx,None,ctx,msg3,pk) | | | | msg4 | |<---------------------------------| | | client_key, msg5 = CPaceOQUAKE+.InitiatorFinish( ctx,seed,msg4,pub_ctx) | | | | msg5 | |--------------------------------->| | | | server_key = CPaceOQUAKE+.ResponderFinish(ctx,msg5) | | ---------------------------------------- output client_key output server_key ]]>

CPaceOQUAKE+ Configurations CPaceOQUAKE+ is instantiated by selecting a configuration of a group and hash function for the CPace protocol, a KEM, KDF, KSF, for the OQUAKE+ stage, and a KEM and KDF for the OQUAKE stage, and a general purpose cryptographic hash function H. The KEM, KDF, are not required to be the same, so they are distinguished by "PC-" and "PAKE-" prefixes, e.g., PC-KDF and PAKE-KDF are the KDFs for the OQUAKE+ stage and the OQUAKE stage, respectively. The RECOMMENDED configuration is below.

• CPace-Group: CPACE-RISTR255-SHA512
• CPace-Hash: SHA-512
• KEM: X-Wing , where Nseed = 32, Nct = 1120, and Npk = 1216.
• PC-KDF: HKDF-SHA-256
• PC-KSF: Argon2id(S = zeroes(16), p = 4, T = Nh, m = 2^21, t = 1, v = 0x13, K = nil, X = nil, y = 2)
• BUA-sKEM: ML-BUA-sKEM1024 , where Kemeleon.sec_param = 256, Nseed = 64, Npk = 1594, and Nct = 1568.
• PAKE-KDF: HKDF-SHA-256
• H: SHA256
• DST: "1b3abc3cd05e8054e8399bc38dfcbc1321d2e1b02da335ed1e8031ef5199f672" (a randomly generated 32-byte string)

The RECOMMENDED parameters are (see ):

• Nverifier = 32
• Nkc = 64
• Nsec = 32
• Nkey = 32, this is achieved by choosing H in CPace with H.b_in_bytes = 32

Other documents can define configurations as needed for their use case, subject to the following requirements:

1. KEM MUST be a hybrid KEM, i.e., one that achieves both classical and post-quantum security.
2. The parameters must be chosen so they correspond with this KEM. E.g., Nseed must have the correct length.

For instance, one possible additional configuration is as follows.

• CPace-Group: CPACE-P256XMD:SHA-256_SSWU_NU-SHA256
• CPace-Hash: SHA-256
• KEM: X-Wing , where Nseed = 32, Nct = 1120, and Npk = 1216.
• PC-KDF: HKDF-SHA-256
• PC-KSF: Scrypt(N = 32768, r = 8, p = 1)
• BUA-sKEM: ML-BUA-sKEM1024 , where Kemeleon.sec_param = 256, Nseed = 64, Npk = 1594, and Nct = 1568.
• PAKE-KDF: HKDF-SHA-256
• H: SHA256
• DST: "b840fa4d4b4caec9e25d13d8c016cfe93e7468d54e936490bd0b0a3ffca1a01b" (a randomly generated 32-byte string)

Implementation Considerations Some functions included in this specification are fallible (as noted by their ability to raise exceptions). The explicit errors generated throughout this specification, along with conditions that lead to each error, are as follows:

• AuthenticationError: The OQUAKE+ stage fails password confirmation checks at the client or server;

Beyond these explicit errors, CPaceOQUAKE+ implementations can produce implicit errors. For example, if protocol messages sent between client and server do not match their expected size, an implementation should produce an error. The errors in this document are meant as a guide for implementors. They are not an exhaustive list of all the errors an implementation might emit. For example, an implementation might run out of memory.

Security Considerations This section discusses security considerations for the protocols specified in this document.

Hybrid Design CPaceOQUAKE and CPaceOQUAKE+ are hybrid PAKE protocols, meaning that the overall protocol remains secure so long as either the classical assumptions underlying CPace, i.e., the gap Diffie-Hellman assumption, or the post-quantum assumptions, i.e., D-MLWE used by OQUAKE, hold. This protects against vulnerabilities in either the classical or post-quantum components. Moreover, OQUAKE does not unconditionally hide the password. If the underlying security assumptions were to break, then the password would be revealed to the attacker. The reason for this is that an attacker that can break the D-MLWE assumption can distinguish actual ML-KEM public keys and ciphertexts from random bitstrings. For OQUAKE, this would allow the attacker to perform offline dictionary attacks on the password. This is also the reason a parallel combiner cannot provide the desired hybrid security (see ): if one PAKE is not unconditionally password hiding, breaking its underlying assumption can yield the password, and learning the password is sufficient to also break the other PAKE. In contrast, the sequential hybrid variants do not suffer from the same weakness: the input to OQUAKE is an effective password, derived from (PRS, secret_context) where the secret_context is the CPace session key, not the original PRS. Performing an offline dictionary attack against the original PRS would require the attacker to also guess the CPace-derived key, which is computationally indistinguishable from a random value under the gap Diffie-Hellman assumption. The benefits of this hybrid protection come at the cost of protocol and round complexity. From a protocol perspective, beyond two independent PAKEs treated nearly as black boxes, additional protocol logic is needed to combine the PAKEs together and produce a shared secret based on both PAKEs. From a round perspective, the hybrid PAKE introduces additional round trips, complicating integration into higher-level protocols like TLS. Finally, the hybrid protocol is comparatively new and has not yet received significant peer review (compared to the non-hybrid PAKEs). However, the backing analysis has been independently analyzed by at least three different groups, improving overall confidence in the design.

Retroactive Password and Session Key Recovery A PAKE is unconditionally password hiding if its protocol messages remain statistically independent of the password even when every computational assumption underlying the PAKE fails. Few efficient PAKEs achieve this: as discussed in , CPace does, but OQUAKE does not, and this is true of PAKEs generally, not just the ones specified in this document. This property is what makes CPace safe to use as the first stage of a sequential combiner: its output key is never subjected to a verification check on its own, so an attacker who breaks the Diffie-Hellman assumption learns nothing from the CPace messages alone. It does not, by itself, mean that a session key derived by CPace stays safe once it is checked against something -- e.g., confirmed directly, or used to encrypt subsequent traffic, as happens in an ordinary standalone deployment. This section generalizes that latter observation into a broader principle and uses it to answer two concrete questions: which classical PAKEs allow a quantum-capable attacker to retroactively recover a session when deployed this ordinary way, and does the same hold for EKE-style PAKEs. The general principle is this: for any PAKE that is not unconditionally password hiding, breaking its underlying computational assumption -- whether that happens contemporaneously or, as with a future quantum computer, retroactively against a transcript recorded today -- allows an attacker to mount an offline dictionary attack against that transcript, provided the attacker also has some way to check a candidate password against it. In practice that check comes for free: an explicit password-confirmation message, present in most aPAKEs, serves directly as the check, and even without one, any subsequent application traffic encrypted under the resulting session key serves the same purpose. Once the attacker recovers the password this way, two consequences follow. First, the attacker can derive the session key of the harvested session and decrypt its traffic, exactly as in ordinary Harvest Now, Decrypt Later against unauthenticated key exchange. Second, and unlike that ordinary case, the attacker also now holds a long-lived credential: they can impersonate the client in every future session until the password is changed. Retroactive password recovery is therefore strictly worse for a PAKE than HNDL is for plain key exchange, which is why deploying a post-quantum KEM only at the transport layer, as discussed in , does not address the risk that a classical PAKE poses on its own. This principle applies directly to classical Diffie-Hellman-based PAKEs, including CPace, SPAKE2, and SPAKE2+, when deployed in the ordinary way, i.e., with the resulting session key confirmed or used directly, rather than fed onward as an opaque input to a second PAKE stage as in : their protocol messages are deterministic functions of a password-derived generator and per-session exponents, so a quantum-capable attacker able to solve the discrete logarithm or Diffie-Hellman problem can, for each candidate password, recompute the generator, recompute the candidate shared secret from the recorded messages, and check it against the verification signal described above. SPAKE2+ is a sharper case: its password-derived offset is applied to fixed, standardized constant points (commonly written M and N) shared by every server and session on a given group, rather than to a fresh per-session generator as in CPace. Solving a single discrete logarithm instance for that group -- e.g., the discrete log of M or N, using a quantum computer, even a slow one -- therefore yields a capability reusable against any server using that group: a single live exchange with the server, plus a confirmation or subsequent-traffic verification signal, is then enough to brute-force the password offline with classical computation alone. This principle applies equally to EKE-style PAKEs, including KEM-based compilers such as OQUAKE (see ): the first protocol flow is, conceptually, a password-encrypted public key or ciphertext, so an attacker who recovers the password by breaking the KEM's hardness assumption (D-MLWE, for the ML-KEM-based instantiation in this document) can decrypt that flow and derive the identical session key an honest party would. The password-hiding failure of OQUAKE described in and is the concrete instance of this general EKE-style argument for the specific construction used in this document. This is precisely why the sequential hybrid composition specified in this document is valuable: an attacker must break both a classical and a post-quantum hard problem simultaneously to retroactively recover the password protected by CPaceOQUAKE(+), a strictly stronger guarantee than any single-primitive PAKE, classical or post-quantum alone, can offer.

Identities Client and server identities are essential to authenticated key exchange protocols, and PAKEs are no exception. This section discusses the role and importance of identities in the PAKE protocols specified in this document.

Symmetric PAKE identities PAKEs are often analyzed in the universal composability (UC) framework, which imposes several requirements on the protocols: (1) the existence of a globally-unique session identifer associated with each protocol invocation, and (2) unique party identifiers. Both are considered as inputs to PAKEs, along with the password itself. In practice, however, computing or agreeing on session and party identifiers is non-trivial and cumbersome. For example, agreeing on a globally unique session identifier requires a protocol to run before the PAKE. Moreover, assigning identifiers to parties -- especially in symmetric PAKE settings -- is problematic as there are rarely pragmatic choices to be made for each party's identifier. IP addresses are not always unique, PKI or some other registry mechanism for assigning names may not exist, and so on. Intuitively, in symmetric settings, passwords are the only secret input to the PAKE protocol; party identities are assumed to be public. As such, an adversary is assumed to know these identifiers. Fortunately, there exists a UC model in which symmetric PAKEs such as CPace are proven secure without requiring party or session identifiers -- the bare PAKE model . The UC bare PAKE model, and proof of security for CPace in this model, demonstrate that PAKEs are universally composable without relying on unique party or session identifiers. We believe that the current proof of security of OQUAKE in can be extended to show that NoIC, the basis of OQUAKE, realizes the Bare PAKE model as well, although we note that that this proof has not been published yet. As such, for the PAKEs in , both the party and session identifier are optional. Applications are free to choose values for these identifiers if applicable, but they are not required for security. [[OPEN ISSUE: adjust the requirements for the identities in OQUAKE on the basis on the bare PAKE analysis]]

Asymmetric PAKE identities In contrast to the symmetric PAKE setting, party identities in the asymmetric PAKE setting play a different role. The very nature of the asymmetric PAKE is that one server, with many different registered passwords, can authenticate many different clients. Consequently, when the protocol runs, the server needs some way to determine which password registration to use in the protocol. Beyond ensuring that the server is authenticating the correct client, the client's identity is what helps the server make this selection. However, the server identifier carries a similar burden. Indeed, the server identifier is used to distinguish distinct server instances from each other so, for example, a client cannot mistakenly authenticate with server A when communicating with server B. This is especially important if the client re-uses their identifier across server instances, since a password registration for server A would then be valid for server B if the server identity were not incorporated into the protocol. Based on this, client and server identities are RECOMMENDED for the asymmetric PAKEs specified in this document (in ). Both client and server identities can be long-lived, e.g., a client identity could be an email address and a server identity could be a domain name. Practically, applications should be mindful of what happens when these identities change. Since they are both included in the password verifier (see ), changing either identifier will require the veirifer to be re-computed and the client to be re-registered. For a single client, this change is minimal, but for a single server, which can have many registered clients, this change can be expensive. Applications therefore ought to consider the longevitiy and uniqueness of their party identifiers when instantiating these protocols.

Timing Attacks and Tempo OQUAKE (without the fix from ) is subject to a timing attack due to how the ML-KEM expands the key-generation seed (rho) to a matrix (A). An internal function — SampleNTT — uses rejection sampling based on the seed and therefore is variable time. In NoIC / OQUAKE, after a sender password-encrypts a public key, an attacker can perform an offline dictionary attack based on this key in the following way:

1. Password-decrypt the authenticated public key using a candidate password.
2. Time the seed-to-matrix expansion step using this candidate public key and compare it against the known timing target.

The Tempo fix addresses this issue by ensuring that input to SampleNTT is not secret-dependent.

IANA Considerations This document has no IANA actions.

References Normative References National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) Alloc Init Labs - New York Endress + Hauser Liquid Analysis - Gerlingen IBM Research Europe - Zurich This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. SandboxAQ MPI-SP & Radboud University Cloudflare This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. IBM Research Europe - Zurich University of Waterloo ETH Zurich This document specifies Kemeleon encoding algorithms for encoding ML- KEM public keys and ciphertexts as random bytestrings. Kemeleon encodings provide obfuscation of public keys and ciphertexts, relying on module LWE assumptions. This document specifies a number of variants of these encodings, with differing failure rates, output sizes, and performance profiles. This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema. Informative References n.d. n.d. n.d. n.d. n.d. n.d. n.d. AWS Meta Cloudflare, Inc. This document describes the OPAQUE protocol, an augmented (or asymmetric) password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol and one instantiation based on 3DH. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document describes SPAKE2+, a Password-Authenticated Key Exchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime-order group, and computationally efficient. This document was produced outside of the IETF and IRTF and represents the opinions of the authors. Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement of SPAKE2+ by the IETF or IRTF. Springer Nature Switzerland

Deriving parameters This section discusses how to generate parameters, given an upper bound on an adversary's advantage in breaking the hybrid (a)PAKE. The parameters in this standard correspond to a classical hardness of 117 bits (considering the attacker can break CPace) and a quantum hardness of 100 bits. We assume that an adversary can perform at most 2^qq queries to random oracles or (a)PAKE sessions. We use qq = 64. The derivation below uses some approximations, ignoring small constants in the exponent such as 1 and 1.6. We also only study dominant terms in the advantage equations.

Parameters for CPaceOQUAKE+ We have the following requirements:

• Nseed * 8 + Nverifier * 8 >= 2 * qq + classical hardness
• Nverifier * 8 >= qq + classical hardness
• Nkc * 8 >= qq + classical hardness
• KEM failure <= -qq - classical hardness
• KEM ind vs classical <= -qq - classical hardness
• KEM ind vs quantum <= -qq - quantum hardness
• CPaceOQUAKE vs classical <= classical hardness
• CPaceOQUAKE vs quantum <= quantum hardness

For ML-KEM we have Nseed = 32. For consistency, the spec uses Nverifier = 32. ML-KEM1024's failure probability is 2^-175.2. This is slightly too large, but we deem it acceptable: the chance that an adversary encounters a failure is purely statistical and very small. The following subsection discusses the parameters and hardness of CPaceOQUAKE.

Parameters for CPaceOQUAKE For the security of CPaceOQUAKE+, we require that CPaceOQUAKE provides:

• CPaceOQUAKE vs classical <= classical hardness
• CPaceOQUAKE vs quantum <= quantum hardness

We have the following requirements when CPaceOQUAKE relies on CPace's security:

• CPace vs classical <= classical hardness
• Nkey * 8 >= qq + classical hardness
• KEM failure <= -qq - classical hardness

We have the following requirements when CPaceOQUAKE relies on OQUAKE's security:

• OQUAKE vs classical <= classical hardness
• OQUAKE vs quantum <= quantum hardness
• Nkey * 8 >= 2*qq + classical hardness

So, the smallest Nkey = 32. We ignore the KEM failure following the same reasoning as above. The following subsections discuss the parameters and hardness of CPace and OQUAKE.

Parameters for CPace We refer to the CPace . This standard requires Nkey, the number of bytes in CPace's session key, to be 32, so one must set H.bmax_in_bytes = 32.

Parameters for OQUAKE We have the following requirements:

• BUA-sKEM ind vs classical <= -qq - classical hardness
• BUA-sKEM ind vs quantum <= -qq - quantum hardness
• BUA-sKEM public key uniformity vs classical <= -qq - classical hardness
• BUA-sKEM public key uniformity vs quantum <= -qq - quantum hardness
• BUA-sKEM ciphertext uniformity vs classical <= -qq - classical hardness
• BUA-sKEM ciphertext uniformity vs quantum <= -qq - quantum hardness
• BUA-sKEM key * 8 >= qq + classical hardness
• KEM failure <= -qq - classical hardness

For ML-BUA-sKEM, if we set Kemeleon.sec_param to 256, it is as hard or harder to break public key and ciphertext uniformity as it is to break indistinguishability, so we discuss all three properties at once. For ML-BUA-sKEM1024, the resistance to classical attacks is approximately 253 - qq bits of security. So for qq = 64, classical hardness is approximately 189 bits of security. The resistance to quantum attacks is approximately 230 - qq bits of security. So for qq = 64, quantum hardness is approximately 166 bits of security. The ML-BUA-sKEM key is 32 bytes, so this satisfies the requirements. We ignore the KEM failure following the same reasoning as above.