rfc9807v1.txt		rfc9807.txt
	Internet Research Task Force (IRTF) D. Bourdrez		Internet Research Task Force (IRTF) D. Bourdrez
	Request for Comments: 9807		Request for Comments: 9807
	Category: Informational H. Krawczyk		Category: Informational H. Krawczyk
	ISSN: 2070-1721 AWS		ISSN: 2070-1721 AWS
	K. Lewi		K. Lewi
	Meta		Meta
	C. A. Wood		C. A. Wood
	Cloudflare, Inc.		Cloudflare, Inc.
	June 2025		July 2025
	The OPAQUE Augmented Password-Authenticated Key Exchange (aPAKE)		The OPAQUE Augmented Password-Authenticated Key Exchange (aPAKE)
	Protocol		Protocol
	Abstract		Abstract
	This document describes the OPAQUE protocol, an Augmented (or		This document describes the OPAQUE protocol, an Augmented (or
	Asymmetric) Password-Authenticated Key Exchange (aPAKE) that supports		Asymmetric) Password-Authenticated Key Exchange (aPAKE) protocol that
	mutual authentication in a client-server setting without reliance on		supports mutual authentication in a client-server setting without
	PKI and with security against pre-computation attacks upon server		reliance on PKI and with security against pre-computation attacks
	compromise. In addition, the protocol provides forward secrecy and		upon server compromise. In addition, the protocol provides forward
	the ability to hide the password from the server, even during		secrecy and the ability to hide the password from the server, even
	password registration. This document specifies the core OPAQUE		during password registration. This document specifies the core
	protocol and one instantiation based on 3DH. This document is a		OPAQUE protocol and one instantiation based on 3DH. This document is
	product of the Crypto Forum Research Group (CFRG) in the IRTF.		a product of the Crypto Forum Research Group (CFRG) in the IRTF.
	Status of This Memo		Status of This Memo
	This document is not an Internet Standards Track specification; it is		This document is not an Internet Standards Track specification; it is
	published for informational purposes.		published for informational purposes.
	This document is a product of the Internet Research Task Force		This document is a product of the Internet Research Task Force
	(IRTF). The IRTF publishes the results of Internet-related research		(IRTF). The IRTF publishes the results of Internet-related research
	and development activities. These results might not be suitable for		and development activities. These results might not be suitable for
	deployment. This RFC represents the consensus of the Crypto Forum		deployment. This RFC represents the consensus of the Crypto Forum
	skipping to change at line 170 ¶		skipping to change at line 170 ¶
	inevitable, such as online impersonation attempts with guessed client		inevitable, such as online impersonation attempts with guessed client
	passwords and offline dictionary attacks upon the compromise of a		passwords and offline dictionary attacks upon the compromise of a
	server and leakage of its credential file. In the latter case, the		server and leakage of its credential file. In the latter case, the
	attacker learns a mapping of a client's password under a one-way		attacker learns a mapping of a client's password under a one-way
	function and uses such a mapping to validate potential guesses for		function and uses such a mapping to validate potential guesses for
	the password. It is crucially important for the password protocol to		the password. It is crucially important for the password protocol to
	use an unpredictable one-way mapping. Otherwise, the attacker can		use an unpredictable one-way mapping. Otherwise, the attacker can
	pre-compute a deterministic list of mapped passwords leading to		pre-compute a deterministic list of mapped passwords leading to
	almost instantaneous leakage of passwords upon server compromise.		almost instantaneous leakage of passwords upon server compromise.
	This document describes OPAQUE, an aPAKE that is secure against pre-		This document describes OPAQUE, an aPAKE protocol that is secure
	computation attacks (as defined in [JKX18]). OPAQUE provides forward		against pre-computation attacks (as defined in [JKX18Full]). OPAQUE
	secrecy with respect to password leakage while also hiding the		provides forward secrecy with respect to password leakage while also
	password from the server, even during password registration. OPAQUE		hiding the password from the server, even during password
	allows applications to increase the difficulty of offline dictionary		registration. OPAQUE allows applications to increase the difficulty
	attacks via iterated hashing or other key-stretching schemes. OPAQUE		of offline dictionary attacks via iterated hashing or other key-
	is also extensible, allowing clients to safely store and retrieve		stretching schemes. OPAQUE is also extensible, allowing clients to
	arbitrary application data on servers using only their password.		safely store and retrieve arbitrary application data on servers using
			only their password.
	OPAQUE is defined and proven as the composition of three		OPAQUE is defined and proven as the composition of three
	functionalities: an Oblivious Pseudorandom Function (OPRF), a key		functionalities: an Oblivious Pseudorandom Function (OPRF), a key
	recovery mechanism, and an authenticated key exchange (AKE) protocol.		recovery mechanism, and an authenticated key exchange (AKE) protocol.
	It can be seen as a "compiler" for transforming any suitable AKE		It can be seen as a "compiler" for transforming any suitable AKE
	protocol into a secure aPAKE protocol. (See Section 10 for		protocol into a secure aPAKE protocol. (See Section 10 for
	requirements of the OPRF and AKE protocols.) This document specifies		requirements of the OPRF and AKE protocols.) This document specifies
	one OPAQUE instantiation based on [TripleDH]. Other instantiations		one OPAQUE instantiation based on [TripleDH]. Other instantiations
	are possible, as discussed in Appendix B, but their details are out		are possible, as discussed in Appendix B, but their details are out
	of scope for this document. In general, the modularity of OPAQUE's		of scope for this document. In general, the modularity of OPAQUE's
	design makes it easy to integrate with additional AKE protocols,		design makes it easy to integrate with additional AKE protocols,
	e.g., TLS or HMQV, and with future ones such as those based on post-		e.g., TLS or HMQV (Hashed Menezes-Qu-Vanstone), and with future AKE
	quantum techniques.		protocols such as those based on post-quantum techniques.
	OPAQUE consists of two stages: registration and authenticated key		OPAQUE consists of two stages: registration and authenticated key
	exchange. In the first stage, a client registers its password with		exchange. In the first stage, a client registers its password with
	the server and stores information used to recover authentication		the server and stores information used to recover authentication
	credentials on the server. Recovering these credentials can only be		credentials on the server. Recovering these credentials can only be
	done with knowledge of the client password. In the second stage, a		done with knowledge of the client password. In the second stage, a
	client uses its password to recover those credentials and		client uses its password to recover those credentials and
	subsequently uses them as input to an AKE protocol. This stage has		subsequently uses them as input to an AKE protocol. This stage has
	additional mechanisms to prevent an active attacker from interacting		additional mechanisms to prevent an active attacker from interacting
	with the server to guess or confirm clients registered via the first		with the server to guess or confirm clients registered via the first
	skipping to change at line 389 ¶		skipping to change at line 390 ¶
	second stage (also called the "login" or "online" stage), the client		second stage (also called the "login" or "online" stage), the client
	recovers its authentication material and uses it to perform a		recovers its authentication material and uses it to perform a
	mutually authenticated key exchange.		mutually authenticated key exchange.
	3.1. Setup		3.1. Setup
	Prior to both stages, the client and server agree on a configuration		Prior to both stages, the client and server agree on a configuration
	that fully specifies the cryptographic algorithm dependencies		that fully specifies the cryptographic algorithm dependencies
	necessary to run the protocol; see Section 7 for details. The server		necessary to run the protocol; see Section 7 for details. The server
	chooses a pair of keys (server_private_key and server_public_key) for		chooses a pair of keys (server_private_key and server_public_key) for
	the AKE and chooses a seed (oprf_seed) of Nh bytes for the OPRF. The		the AKE protocol and chooses a seed (oprf_seed) of Nh bytes for the
	server can use server_private_key and server_public_key with multiple		OPRF. The server can use server_private_key and server_public_key
	clients. The server can also opt to use a different seed for each		with multiple clients. The server can also opt to use a different
	client (i.e., each client can be assigned a single seed), so long as		seed for each client (i.e., each client can be assigned a single
	they are maintained across the registration and online AKE stages and		seed), so long as they are maintained across the registration and
	kept consistent for each client (since an inconsistent mapping of		online AKE stages and kept consistent for each client (since an
	clients to seeds could leak information as described in		inconsistent mapping of clients to seeds could leak information as
	Section 10.9).		described in Section 10.9).
	3.2. Registration		3.2. Registration
	Registration is the only stage in OPAQUE that requires a server-		Registration is the only stage in OPAQUE that requires a server-
	authenticated channel with confidentiality and integrity: either		authenticated channel with confidentiality and integrity: either
	physical, out-of-band, PKI-based, etc.		physical, out-of-band, PKI-based, etc.
	The client inputs its credentials, which include its password and		The client inputs its credentials, which include its password and
	user identifier, and the server inputs its parameters, which include		user identifier, and the server inputs its parameters, which include
	its private key and other information.		its private key and other information.
	skipping to change at line 452 ¶		skipping to change at line 453 ¶
	3.3. Online Authenticated Key Exchange		3.3. Online Authenticated Key Exchange
	In this second stage, a client obtains credentials previously		In this second stage, a client obtains credentials previously
	registered with the server, recovers private key material using the		registered with the server, recovers private key material using the
	password, and subsequently uses them as input to the AKE protocol.		password, and subsequently uses them as input to the AKE protocol.
	As in the registration phase, the client inputs its credentials,		As in the registration phase, the client inputs its credentials,
	including its password and user identifier, and the server inputs its		including its password and user identifier, and the server inputs its
	parameters and the credential file record corresponding to the		parameters and the credential file record corresponding to the
	client. The client outputs two values, an export_key (matching that		client. The client outputs two values, an export_key (matching that
	from registration) and a session_key, the latter of which is the		from registration) and a session_key, the latter of which is the
	primary AKE output. The server outputs a single value session_key		primary AKE protocol output. The server outputs a single value
	that matches that of the client. Upon completion, clients and		session_key that matches that of the client. Upon completion,
	servers can use these values as needed.		clients and servers can use these values as needed.
	The authenticated key exchange flow is shown in Figure 2:		The authenticated key exchange flow is shown in Figure 2:
	credentials (parameters, record)		credentials (parameters, record)
	| |		| |
	v v		v v
	Client Server		Client Server
	------------------------------------------------		------------------------------------------------
	AKE message 1		AKE message 1
	------------------------->		------------------------->
	skipping to change at line 537 ¶		skipping to change at line 538 ¶
	uint8 client_identity<1..2^16-1>;		uint8 client_identity<1..2^16-1>;
	} CleartextCredentials;		} CleartextCredentials;
	The function CreateCleartextCredentials constructs a		The function CreateCleartextCredentials constructs a
	CleartextCredentials structure given application credential		CleartextCredentials structure given application credential
	information.		information.
	CreateCleartextCredentials		CreateCleartextCredentials
	Input:		Input:
	- server_public_key, the encoded server public key for the AKE protocol.		- server_public_key, the encoded server public key
	- client_public_key, the encoded client public key for the AKE protocol.		for the AKE protocol.
			- client_public_key, the encoded client public key
			for the AKE protocol.
	- server_identity, the optional encoded server identity.		- server_identity, the optional encoded server identity.
	- client_identity, the optional encoded client identity.		- client_identity, the optional encoded client identity.
	Output:		Output:
	- cleartext_credentials, a CleartextCredentials structure.		- cleartext_credentials, a CleartextCredentials structure.
	def CreateCleartextCredentials(server_public_key, client_public_key,		def CreateCleartextCredentials(server_public_key, client_public_key,
	server_identity, client_identity):		server_identity, client_identity):
	# Set identities as public keys if no		# Set identities as public keys if no
	# application-layer identity is provided		# application-layer identity is provided
	skipping to change at line 582 ¶		skipping to change at line 585 ¶
	struct {		struct {
	uint8 envelope_nonce[Nn];		uint8 envelope_nonce[Nn];
	uint8 auth_tag[Nm];		uint8 auth_tag[Nm];
	} Envelope;		} Envelope;
	envelope_nonce: A randomly sampled nonce of length Nn used to		envelope_nonce: A randomly sampled nonce of length Nn used to
	protect this Envelope.		protect this Envelope.
	auth_tag: An authentication tag protecting the contents of the		auth_tag: An authentication tag protecting the contents of the
	envelope, covering envelope_nonce and CleartextCredentials.		Envelope, covering envelope_nonce and CleartextCredentials.
	4.1.2. Envelope Creation		4.1.2. Envelope Creation
	Clients create an Envelope at registration with the function Store		Clients create an Envelope at registration with the function Store
	defined below. Note that DeriveDiffieHellmanKeyPair in this function		defined below. Note that DeriveDiffieHellmanKeyPair in this function
	can fail with negligible probability. If this occurs, servers should		can fail with negligible probability. If this occurs, servers should
	re-run the function, sampling a new envelope_nonce, to completion.		re-run the function, sampling a new envelope_nonce, to completion.
	Store		Store
	skipping to change at line 664 ¶		skipping to change at line 667 ¶
	- server_identity, the optional encoded server identity.		- server_identity, the optional encoded server identity.
	- client_identity, the optional encoded client identity.		- client_identity, the optional encoded client identity.
	Output:		Output:
	- client_private_key, the encoded client private key for the		- client_private_key, the encoded client private key for the
	AKE protocol.		AKE protocol.
	- cleartext_credentials, a CleartextCredentials structure.		- cleartext_credentials, a CleartextCredentials structure.
	- export_key, an additional client key.		- export_key, an additional client key.
	Exceptions:		Exceptions:
	- EnvelopeRecoveryError, the envelope fails to be recovered.		- EnvelopeRecoveryError, the Envelope fails to be recovered.
	def Recover(randomized_password, server_public_key, envelope,		def Recover(randomized_password, server_public_key, envelope,
	server_identity, client_identity):		server_identity, client_identity):
	auth_key =		auth_key =
	Expand(randomized_password, concat(envelope.nonce, "AuthKey"),		Expand(randomized_password, concat(envelope.nonce, "AuthKey"),
	Nh)		Nh)
	export_key =		export_key =
	Expand(randomized_password, concat(envelope.nonce, "ExportKey"),		Expand(randomized_password, concat(envelope.nonce, "ExportKey"),
	Nh)		Nh)
	seed =		seed =
	skipping to change at line 1137 ¶		skipping to change at line 1140 ¶
	the credential.		the credential.
	- oprf_seed, the server-side seed of Nh bytes used to generate		- oprf_seed, the server-side seed of Nh bytes used to generate
	an oprf_key.		an oprf_key.
	- ke1, a KE1 message structure.		- ke1, a KE1 message structure.
	- client_identity, the optional encoded client identity, which is		- client_identity, the optional encoded client identity, which is
	set to client_public_key if not specified.		set to client_public_key if not specified.
	Output:		Output:
	- ke2, a KE2 structure.		- ke2, a KE2 structure.
	def GenerateKE2(server_identity, server_private_key, server_public_key,		def GenerateKE2(server_identity, server_private_key,
	record, credential_identifier, oprf_seed, ke1,		server_public_key, record, credential_identifier,
	client_identity):		oprf_seed, ke1, client_identity):
	credential_response =		credential_response =
	CreateCredentialResponse(ke1.credential_request,		CreateCredentialResponse(ke1.credential_request,
	server_public_key, record,		server_public_key, record,
	credential_identifier, oprf_seed)		credential_identifier, oprf_seed)
	cleartext_credentials =		cleartext_credentials =
	CreateCleartextCredentials(server_public_key,		CreateCleartextCredentials(server_public_key,
	record.client_public_key,		record.client_public_key,
	server_identity, client_identity)		server_identity, client_identity)
	auth_response =		auth_response =
	AuthServerRespond(cleartext_credentials, server_private_key,		AuthServerRespond(cleartext_credentials, server_private_key,
	skipping to change at line 1189 ¶		skipping to change at line 1192 ¶
	- ke3, a KE3 message structure.		- ke3, a KE3 message structure.
	- session_key, the session's shared secret.		- session_key, the session's shared secret.
	- export_key, an additional client key.		- export_key, an additional client key.
	def GenerateKE3(client_identity, server_identity, ke2):		def GenerateKE3(client_identity, server_identity, ke2):
	(client_private_key, cleartext_credentials, export_key) =		(client_private_key, cleartext_credentials, export_key) =
	RecoverCredentials(state.password, state.blind,		RecoverCredentials(state.password, state.blind,
	ke2.credential_response,		ke2.credential_response,
	server_identity, client_identity)		server_identity, client_identity)
	(ke3, session_key) =		(ke3, session_key) =
	AuthClientFinalize(cleartext_credentials, client_private_key, ke2)		AuthClientFinalize(cleartext_credentials,
			client_private_key, ke2)
	return (ke3, session_key, export_key)		return (ke3, session_key, export_key)
	6.2.4. ServerFinish		6.2.4. ServerFinish
	The ServerFinish function completes the AKE protocol for the server,		The ServerFinish function completes the AKE protocol for the server,
	yielding the session_key. Since the OPRF is a two-message protocol,		yielding the session_key. Since the OPRF is a two-message protocol,
	KE3 has no element of the OPRF and it, therefore, invokes the AKE's		KE3 has no element of the OPRF. Therefore, KE3 invokes the AKE's
	AuthServerFinalize directly. The AuthServerFinalize function takes		AuthServerFinalize directly. The AuthServerFinalize function takes
	KE3 as input and MUST verify the client authentication material it		KE3 as input and MUST verify the client authentication material it
	contains before the session_key value can be used. This verification		contains before the session_key value can be used. This verification
	is necessary to ensure forward secrecy against active attackers.		is necessary to ensure forward secrecy against active attackers.
	ServerFinish		ServerFinish
	State:		State:
	- state, a ServerState structure.		- state, a ServerState structure.
	skipping to change at line 1468 ¶		skipping to change at line 1472 ¶
	output of this function is a unique, fixed-length byte string.		output of this function is a unique, fixed-length byte string.
	It is RECOMMENDED to use Elliptic Curve Diffie-Hellman for this key		It is RECOMMENDED to use Elliptic Curve Diffie-Hellman for this key
	exchange protocol. Implementations for recommended groups in		exchange protocol. Implementations for recommended groups in
	Section 7, as well as groups covered by test vectors in Appendix C,		Section 7, as well as groups covered by test vectors in Appendix C,
	are described in the following sections.		are described in the following sections.
	6.4.1.1. 3DH ristretto255		6.4.1.1. 3DH ristretto255
	This section describes the implementation of the Diffie-Hellman key		This section describes the implementation of the Diffie-Hellman key
	exchange functions based on ristretto255 as defined in [RISTRETTO].		exchange functions based on ristretto255 as defined in [RFC9496].
	DeriveDiffieHellmanKeyPair(seed): This function is implemented as		DeriveDiffieHellmanKeyPair(seed): This function is implemented as
	DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where		DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where
	DeriveKeyPair is as specified in Section 3.2 of [RFC9497]. The		DeriveKeyPair is as specified in Section 3.2 of [RFC9497]. The
	public value from DeriveKeyPair is encoded using SerializeElement		public value from DeriveKeyPair is encoded using SerializeElement
	from Section 2.1 of [RFC9497].		from Section 2.1 of [RFC9497].
	DiffieHellman(k, B): Implemented as scalar multiplication as		DiffieHellman(k, B): Implemented as scalar multiplication as
	described in [RISTRETTO] after decoding B from its encoded input		described in [RFC9496] after decoding B from its encoded input
	using the Decode function in Section 4.3.1 of [RISTRETTO]. The		using the Decode function in Section 4.3.1 of [RFC9496]. The
	output is then encoded using the SerializeElement function of the		output is then encoded using the SerializeElement function of the
	OPRF group described in Section 2.1 of [RFC9497].		OPRF group described in Section 2.1 of [RFC9497].
	6.4.1.2. 3DH P-256		6.4.1.2. 3DH P-256
	This section describes the implementation of the Diffie-Hellman key		This section describes the implementation of the Diffie-Hellman key
	exchange functions based on NIST P-256 as defined in [NISTCurves].		exchange functions based on NIST P-256 as defined in [NISTCurves].
	DeriveDiffieHellmanKeyPair(seed): This function is implemented as		DeriveDiffieHellmanKeyPair(seed): As defined in Section 6.4.1.1.
	DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where
	DeriveKeyPair is as specified in Section 3.2 of [RFC9497]. The
	public value from DeriveKeyPair is encoded using SerializeElement
	from Section 2.1 of [RFC9497].
	DiffieHellman(k, B): Implemented as scalar multiplication as		DiffieHellman(k, B): Implemented as scalar multiplication as
	described in [NISTCurves], after decoding B from its encoded input		described in [NISTCurves] after decoding B from its encoded input
	using the compressed Octet-String-to-Elliptic-Curve-Point method		using the compressed Octet-String-to-Elliptic-Curve-Point method
	according to [NISTCurves]. The output is then encoded using the		according to [NISTCurves]. The output is then encoded using the
	SerializeElement function of the OPRF group described in		SerializeElement function of the OPRF group described in
	Section 2.1 of [RFC9497].		Section 2.1 of [RFC9497].
	6.4.1.3. 3DH Curve25519		6.4.1.3. 3DH Curve25519
	This section describes the implementation of the Diffie-Hellman key		This section describes the implementation of the Diffie-Hellman key
	exchange functions based on Curve25519 as defined in [Curve25519].		exchange functions based on Curve25519 as defined in [RFC7748].
	DeriveDiffieHellmanKeyPair(seed): This function is implemented by		DeriveDiffieHellmanKeyPair(seed): This function is implemented by
	returning the private key k based on seed (of length Nseed = 32		returning the private key k based on seed (of length Nseed = 32
	bytes) as described in Section 5 of [Curve25519], as well as the		bytes) as described in Section 5 of [RFC7748], as well as the
	result of DiffieHellman(k, B), where B is the base point of		result of DiffieHellman(k, B), where B is the base point of
	Curve25519.		Curve25519.
	DiffieHellman(k, B): Implemented using the X25519 function in		DiffieHellman(k, B): Implemented using the X25519 function in
	Section 5 of [Curve25519]. The output is then used raw with no		Section 5 of [RFC7748]. The output is then used raw with no
	processing.		processing.
	6.4.2. Key Schedule Functions		6.4.2. Key Schedule Functions
	This section contains functions used for the AKE key schedule.		This section contains functions used for the AKE key schedule.
	6.4.2.1. Transcript Functions		6.4.2.1. Transcript Functions
	The OPAQUE-3DH key derivation procedures make use of the functions		The OPAQUE-3DH key derivation procedures make use of the functions
	below that are repurposed from TLS 1.3 [RFC8446].		below that are repurposed from TLS 1.3 [RFC8446].
	skipping to change at line 1543 ¶		skipping to change at line 1543 ¶
	uint8 context<0..255> = Context;		uint8 context<0..255> = Context;
	} CustomLabel;		} CustomLabel;
	Derive-Secret(Secret, Label, Transcript-Hash) =		Derive-Secret(Secret, Label, Transcript-Hash) =
	Expand-Label(Secret, Label, Transcript-Hash, Nx)		Expand-Label(Secret, Label, Transcript-Hash, Nx)
	Note that the Label parameter is not a NULL-terminated string.		Note that the Label parameter is not a NULL-terminated string.
	OPAQUE-3DH can optionally include application-specific, shared		OPAQUE-3DH can optionally include application-specific, shared
	context information in the transcript, such as configuration		context information in the transcript, such as configuration
	parameters or application-specific info, e.g., "appXYZ-v1.2.3".		parameters or application-specific information, e.g., "appXYZ-
			v1.2.3".
	The OPAQUE-3DH key schedule requires a preamble, which is computed as		The OPAQUE-3DH key schedule requires a preamble, which is computed as
	follows.		follows.
	Preamble		Preamble
	Parameters:		Parameters:
	- context, optional shared context information.		- context, optional shared context information.
	Input:		Input:
	skipping to change at line 1568 ¶		skipping to change at line 1569 ¶
	to server_public_key if not specified.		to server_public_key if not specified.
	- credential_response, the corresponding field on the KE2 structure.		- credential_response, the corresponding field on the KE2 structure.
	- server_nonce, the corresponding field on the AuthResponse		- server_nonce, the corresponding field on the AuthResponse
	structure.		structure.
	- server_public_keyshare, the corresponding field on the AuthResponse		- server_public_keyshare, the corresponding field on the AuthResponse
	structure.		structure.
	Output:		Output:
	- preamble, the protocol transcript with identities and messages.		- preamble, the protocol transcript with identities and messages.
	def Preamble(client_identity, ke1, server_identity, credential_response,		def Preamble(client_identity, ke1, server_identity,
	server_nonce, server_public_keyshare):		credential_response, server_nonce,
			server_public_keyshare):
	preamble = concat("OPAQUEv1-",		preamble = concat("OPAQUEv1-",
	I2OSP(len(context), 2), context,		I2OSP(len(context), 2), context,
	I2OSP(len(client_identity), 2), client_identity,		I2OSP(len(client_identity), 2), client_identity,
	ke1,		ke1,
	I2OSP(len(server_identity), 2), server_identity,		I2OSP(len(server_identity), 2), server_identity,
	credential_response,		credential_response,
	server_nonce,		server_nonce,
	server_public_keyshare)		server_public_keyshare)
	return preamble		return preamble
	skipping to change at line 1666 ¶		skipping to change at line 1668 ¶
	- client_private_key, the client's private key.		- client_private_key, the client's private key.
	- ke2, a KE2 message structure.		- ke2, a KE2 message structure.
	Output:		Output:
	- ke3, a KE3 structure.		- ke3, a KE3 structure.
	- session_key, the shared session secret.		- session_key, the shared session secret.
	Exceptions:		Exceptions:
	- ServerAuthenticationError, the handshake fails.		- ServerAuthenticationError, the handshake fails.
	def AuthClientFinalize(cleartext_credentials, client_private_key, ke2):		def AuthClientFinalize(cleartext_credentials,
			client_private_key, ke2):
	dh1 = DiffieHellman(state.client_secret,		dh1 = DiffieHellman(state.client_secret,
	ke2.auth_response.server_public_keyshare)		ke2.auth_response.server_public_keyshare)
	dh2 = DiffieHellman(state.client_secret,		dh2 = DiffieHellman(state.client_secret,
	cleartext_credentials.server_public_key)		cleartext_credentials.server_public_key)
	dh3 = DiffieHellman(client_private_key,		dh3 = DiffieHellman(client_private_key,
	ke2.auth_response.server_public_keyshare)		ke2.auth_response.server_public_keyshare)
	ikm = concat(dh1, dh2, dh3)		ikm = concat(dh1, dh2, dh3)
	preamble = Preamble(cleartext_credentials.client_identity,		preamble = Preamble(cleartext_credentials.client_identity,
	skipping to change at line 1793 ¶		skipping to change at line 1796 ¶
	Section 2. Examples include HKDF [RFC5869] for the KDF, HMAC		Section 2. Examples include HKDF [RFC5869] for the KDF, HMAC
	[RFC2104] for the MAC, and SHA-256 and SHA-512 for the Hash		[RFC2104] for the MAC, and SHA-256 and SHA-512 for the Hash
	functions. If an extensible output function such as SHAKE128		functions. If an extensible output function such as SHAKE128
	[FIPS202] is used, then the output length Nh MUST be chosen to		[FIPS202] is used, then the output length Nh MUST be chosen to
	align with the target security level of the OPAQUE configuration.		align with the target security level of the OPAQUE configuration.
	For example, if the target security parameter for the		For example, if the target security parameter for the
	configuration is 128 bits, then Nh SHOULD be at least 32 bytes.		configuration is 128 bits, then Nh SHOULD be at least 32 bytes.
	* The KSF is determined by the application and implements the		* The KSF is determined by the application and implements the
	interface in Section 2. As noted, collision resistance is		interface in Section 2. As noted, collision resistance is
	required. Examples for KSF include Argon2id [ARGON2], scrypt		required. Examples for KSF include Argon2id [RFC9106], scrypt
	[SCRYPT], and PBKDF2 [PBKDF2] with fixed parameter choices. See		[RFC7914], and PBKDF2 [RFC8018] with fixed parameter choices. See
	Section 8 for more information about this choice of function.		Section 8 for more information about this choice of function.
	* The Group mode identifies the group used in the OPAQUE-3DH AKE.		* The Group mode identifies the group used in the OPAQUE-3DH AKE.
	This SHOULD match that of the OPRF. For example, if the OPRF is		This SHOULD match that of the OPRF. For example, if the OPRF is
	ristretto255-SHA512, then Group SHOULD be ristretto255.		ristretto255-SHA512, then Group SHOULD be ristretto255.
	Context is the shared parameter used to construct the preamble in		Context is the shared parameter used to construct the preamble in
	Section 6.4.2.1. This parameter SHOULD include any application-		Section 6.4.2.1. This parameter SHOULD include any application-
	specific configuration information or parameters that are needed to		specific configuration information or parameters that are needed to
	prevent cross-protocol or downgrade attacks.		prevent cross-protocol or downgrade attacks.
	skipping to change at line 1933 ¶		skipping to change at line 1936 ¶
	incorporate client_identity alongside the password as input to the		incorporate client_identity alongside the password as input to the
	OPRF. Furthermore, it is RECOMMENDED to incorporate server_identity		OPRF. Furthermore, it is RECOMMENDED to incorporate server_identity
	alongside the password as input to the OPRF. These additions provide		alongside the password as input to the OPRF. These additions provide
	domain separation for clients and servers; see Section 10.2.		domain separation for clients and servers; see Section 10.2.
	9.2. Handling Online Guessing Attacks		9.2. Handling Online Guessing Attacks
	Online guessing attacks (against any aPAKE) can be done from both the		Online guessing attacks (against any aPAKE) can be done from both the
	client side and the server side. In particular, a malicious server		client side and the server side. In particular, a malicious server
	can attempt to simulate honest responses to learn the client's		can attempt to simulate honest responses to learn the client's
	password. While this constitutes an exhaustive online attack, hence		password. While this constitutes an exhaustive online attack (as
	as expensive as an online guessing attack from the client side, it		expensive as a guessing attack from the client side), it can be
	can be mitigated when the channel between client and server is		mitigated when the channel between client and server is
	authenticated, e.g., using server-authenticated TLS. In such cases,		authenticated, e.g., using server-authenticated TLS. In such cases,
	these online attacks are limited to clients and the authenticated		these online attacks are limited to clients and the authenticated
	server itself. Moreover, such a channel provides privacy of user		server itself. Moreover, such a channel provides privacy of user
	information, including identity and envelope values.		information, including identity and envelope values.
	Additionally, note that a client participating in the online login		Additionally, note that a client participating in the online login
	stage will learn whether or not authentication is successful after		stage will learn whether or not authentication is successful after
	receiving the KE2 message. This means that the server should treat		receiving the KE2 message. This means that the server should treat
	any client which fails to send a subsequent KE3 message as an		any client which fails to send a subsequent KE3 message as an
	authentication failure. This can be handled in applications that		authentication failure. This can be handled in applications that
	skipping to change at line 1960 ¶		skipping to change at line 1963 ¶
	9.3. Error Considerations		9.3. Error Considerations
	Some functions included in this specification are fallible. For		Some functions included in this specification are fallible. For
	example, the authenticated key exchange protocol may fail because the		example, the authenticated key exchange protocol may fail because the
	client's password was incorrect or the authentication check failed,		client's password was incorrect or the authentication check failed,
	yielding an error. The explicit errors generated throughout this		yielding an error. The explicit errors generated throughout this
	specification, along with conditions that lead to each error, are as		specification, along with conditions that lead to each error, are as
	follows:		follows:
	* EnvelopeRecoveryError: The envelope Recover function failed to		* EnvelopeRecoveryError: The Envelope Recover function failed to
	produce any authentication key material; Section 4.1.3.		produce any authentication key material; Section 4.1.3.
	* ServerAuthenticationError: The client failed to complete the		* ServerAuthenticationError: The client failed to complete the
	authenticated key exchange protocol with the server;		authenticated key exchange protocol with the server;
	Section 6.4.3.		Section 6.4.3.
	* ClientAuthenticationError: The server failed to complete the		* ClientAuthenticationError: The server failed to complete the
	authenticated key exchange protocol with the client;		authenticated key exchange protocol with the client;
	Section 6.4.4.		Section 6.4.4.
	skipping to change at line 2004 ¶		skipping to change at line 2007 ¶
	only the correct password can unlock the private key while at the		only the correct password can unlock the private key while at the
	same time avoiding potential offline guessing attacks. This general		same time avoiding potential offline guessing attacks. This general
	composability property provides great flexibility and enables a		composability property provides great flexibility and enables a
	variety of OPAQUE instantiations, from optimized performance to		variety of OPAQUE instantiations, from optimized performance to
	integration with existing authenticated key exchange protocols such		integration with existing authenticated key exchange protocols such
	as TLS.		as TLS.
	10.1. Notable Design Differences		10.1. Notable Design Differences
	The specification as written here differs from the original		The specification as written here differs from the original
	cryptographic design in [JKX18] and the corresponding CFRG document		cryptographic design in [JKX18Full] and the corresponding CFRG
	[Krawczyk20], both of which were used as input to the CFRG PAKE		document [Krawczyk20], both of which were used as input to the CFRG
	competition. This section describes these differences, including		PAKE competition. This section describes these differences,
	their motivation and explanation as to why they preserve the provable		including their motivation and explanation as to why they preserve
	security of OPAQUE based on [JKX18].		the provable security of OPAQUE based on [JKX18Full].
	The following list enumerates important functional differences that		The following list enumerates important functional differences that
	were made as part of the protocol specification process to address		were made as part of the protocol specification process to address
	application or implementation considerations.		application or implementation considerations.
	* Clients construct envelope contents without revealing the password		* Clients construct envelope contents without revealing the password
	to the server, as described in Section 5, whereas the servers		to the server, as described in Section 5, whereas the servers
	construct envelopes in [JKX18]. This change adds to the security		construct envelopes in [JKX18Full]. This change adds to the
	of the protocol. [JKX18] considered the case where the envelope		security of the protocol. [JKX18Full] considered the case where
	was constructed by the server for reasons of compatibility with		the envelope was constructed by the server for reasons of
	previous Universal Composability (UC) security modeling. [HJKW23]		compatibility with previous Universal Composability (UC) security
	analyzes the registration phase as specified in this document.		modeling. [HJKW23] analyzes the registration phase as specified
	This change was made to support registration flows where the		in this document. This change was made to support registration
	client chooses the password and wishes to keep it secret from the		flows where the client chooses the password and wishes to keep it
	server, and it is compatible with the variant in [JKX18] that was		secret from the server, and it is compatible with the variant in
	originally analyzed.		[JKX18Full] that was originally analyzed.
	* Envelopes do not contain encrypted credentials. Instead,		* Envelopes do not contain encrypted credentials. Instead,
	envelopes contain information used to derive client private key		envelopes contain information used to derive client private key
	material for the AKE. This change improves the assumption behind		material for the AKE. This change improves the assumption behind
	the protocol by getting rid of equivocality and random key		the protocol by getting rid of equivocality and random key
	robustness for the encryption function. The random-key robustness		robustness for the encryption function. The random-key robustness
	property defined in Section 2.2 is only needed for the MAC		property defined in Section 2.2 is only needed for the MAC
	function. This change was made for two reasons. First, it		function. This change was made for two reasons. First, it
	reduces the number of bytes stored in envelopes, which is a		reduces the number of bytes stored in envelopes, which is a
	helpful improvement for large applications of OPAQUE with many		helpful improvement for large applications of OPAQUE with many
	registered users. Second, it removes the need for client		registered users. Second, it removes the need for client
	applications to generate private keys during registration.		applications to generate private keys during registration.
	Instead, this responsibility is handled by OPAQUE, thereby		Instead, this responsibility is handled by OPAQUE, thereby
	simplifying the client interface to the protocol.		simplifying the client interface to the protocol.
	* Envelopes are masked with a per-user masking key as a way of		* Envelopes are masked with a per-user masking key as a way of
	preventing client enumeration attacks. See Section 10.9 for more		preventing client enumeration attacks. See Section 10.9 for more
	details. This extension is not needed for the security of OPAQUE		details. This extension is not needed for the security of OPAQUE
	as an aPAKE, but is only used to provide a defense against		as an aPAKE protocol, but is only used to provide a defense
	enumeration attacks. In the analysis, the masking key can be		against enumeration attacks. In the analysis, the masking key can
	simulated as a (pseudo) random key. This change was made to		be simulated as a (pseudo) random key. This change was made to
	support real-world use cases where client or user enumeration is a		support real-world use cases where client or user enumeration is a
	security (or privacy) risk.		security (or privacy) risk.
	* Per-user OPRF keys are derived from a client identity and cross-		* Per-user OPRF keys are derived from a client identity and cross-
	user PRF seed as a mitigation against client enumeration attacks.		user PRF seed as a mitigation against client enumeration attacks.
	See Section 10.9 for more details. The analysis of OPAQUE assumes		See Section 10.9 for more details. The analysis of OPAQUE assumes
	OPRF keys of different users are independently random or		OPRF keys of different users are independently random or
	pseudorandom. Deriving these keys via a single PRF (i.e., with a		pseudorandom. Deriving these keys via a single PRF (i.e., with a
	single cross-user key) applied to users' identities satisfies this		single cross-user key) applied to users' identities satisfies this
	assumption. This change was made to support real-world use cases		assumption. This change was made to support real-world use cases
	skipping to change at line 2071 ¶		skipping to change at line 2074 ¶
	* The protocol outputs an export key for the client in addition to a		* The protocol outputs an export key for the client in addition to a
	shared session key that can be used for application-specific		shared session key that can be used for application-specific
	purposes. This key is a pseudorandom value derived from the		purposes. This key is a pseudorandom value derived from the
	client password (among other values) and has no influence on the		client password (among other values) and has no influence on the
	security analysis (it can be simulated with a random output).		security analysis (it can be simulated with a random output).
	This change was made to support more application use cases for		This change was made to support more application use cases for
	OPAQUE, such as the use of OPAQUE for end-to-end encrypted		OPAQUE, such as the use of OPAQUE for end-to-end encrypted
	backups; see [WhatsAppE2E].		backups; see [WhatsAppE2E].
	* The AKE describes a 3-message protocol where the third message		* The AKE protocol describes a 3-message protocol where the third
	includes client authentication material that the server is		message includes client authentication material that the server is
	required to verify. This change (from the original 2-message		required to verify. This change (from the original 2-message
	protocol) was made to provide explicit client authentication and		protocol) was made to provide explicit client authentication and
	full forward security. The 3-message protocol is analyzed in		full forward security. The 3-message protocol is analyzed in
	[JKX18Full].		[JKX18Full].
	* The protocol admits optional application-layer client and server		* The protocol admits optional application-layer client and server
	identities. In the absence of these identities, the client and		identities. In the absence of these identities, the client and
	server are authenticated against their public keys. Binding		server are authenticated against their public keys. Binding
	authentication to identities is part of the AKE part of OPAQUE.		authentication to identities is part of the AKE part of OPAQUE.
	The type of identities and their semantics are application-		The type of identities and their semantics are application-
	skipping to change at line 2107 ¶		skipping to change at line 2110 ¶
	and indexing into the registration record storage called the		and indexing into the registration record storage called the
	credential_identifier. This allows clients to change their		credential_identifier. This allows clients to change their
	application-layer identity (client_identity) without inducing		application-layer identity (client_identity) without inducing
	server-side changes, e.g., by changing an email address associated		server-side changes, e.g., by changing an email address associated
	with a given account. This mechanism is part of the derivation of		with a given account. This mechanism is part of the derivation of
	OPRF keys via a single PRF. As long as the derivation of		OPRF keys via a single PRF. As long as the derivation of
	different OPRF keys from a single PRF has different PRF inputs,		different OPRF keys from a single PRF has different PRF inputs,
	the protocol is secure. The choice of such inputs is up to the		the protocol is secure. The choice of such inputs is up to the
	application.		application.
	* [JKX18] comments on a defense against offline dictionary attacks		* [JKX18Full] comments on a defense against offline dictionary
	upon server compromise or honest-but-curious servers. The authors		attacks upon server compromise or honest-but-curious servers. The
	suggest implementing the OPRF phase as a threshold OPRF [TOPPSS],		authors suggest implementing the OPRF phase as a threshold OPRF
	effectively forcing an attacker to act online or to control at		[TOPPSS], effectively forcing an attacker to act online or control
	least t key shares (among the total n), where t is the threshold		at least t key shares (of the total n), where t is the threshold
	number of shares necessary to recombine the secret OPRF key, and		number of shares necessary to recombine the secret OPRF key. Only
	only then be able to run an offline dictionary attack. This		then would an attacker be able to run an offline dictionary
	implementation only affects the server and changes nothing for the		attack. This implementation only affects the server and changes
	client. Furthermore, if the threshold OPRF servers holding these		nothing for the client. Furthermore, if the threshold OPRF
	keys are separate from the authentication server, then recovering		servers holding these keys are separate from the authentication
	all n shares would still not suffice to run an offline dictionary		server, then recovering all n shares would still not suffice to
	attack without access to the client record database. However,		run an offline dictionary attack without access to the client
	this mechanism is out of scope for this document.		record database. However, this mechanism is out of scope for this
			document.
	The following list enumerates notable differences and refinements		The following list enumerates notable differences and refinements
	from the original cryptographic design in [JKX18] and the		from the original cryptographic design in [JKX18Full] and the
	corresponding CFRG document [Krawczyk20] that were made to make this		corresponding CFRG document [Krawczyk20] that were made to make this
	specification suitable for interoperable implementations.		specification suitable for interoperable implementations.
	* [JKX18] used a generic prime-order group for the DH-OPRF and HMQV		* [JKX18Full] used a generic prime-order group for the DH-OPRF and
	operations, and includes necessary prime-order subgroup checks		HMQV operations, and includes necessary prime-order subgroup
	when receiving attacker-controlled values over the wire. This		checks when receiving attacker-controlled values over the wire.
	specification instantiates the prime-order group used for 3DH		This specification instantiates the prime-order group used for 3DH
	using prime-order groups based on elliptic curves as described in		using prime-order groups based on elliptic curves as described in
	Section 2.1 of [RFC9497]. This specification also delegates OPRF		Section 2.1 of [RFC9497]. This specification also delegates OPRF
	group choice and operations to Section 4 of [RFC9497]. As such,		group choice and operations to Section 4 of [RFC9497]. As such,
	the prime-order group as used in the OPRF and 3DH as specified in		the prime-order group as used in the OPRF and 3DH as specified in
	this document both adhere to the requirements in [JKX18].		this document both adhere to the requirements in [JKX18Full].
	* [JKX18] specified DH-OPRF (see Appendix B) to instantiate the OPRF		* [JKX18Full] specified DH-OPRF (see Appendix B) to instantiate the
	functionality in the protocol. A critical part of DH-OPRF is the		OPRF functionality in the protocol. A critical part of DH-OPRF is
	hash-to-group operation, which was not instantiated in the		the hash-to-group operation, which was not instantiated in the
	original analysis. However, the requirements for this operation		original analysis. However, the requirements for this operation
	were included. This specification instantiates the OPRF		were included. This specification instantiates the OPRF
	functionality based on Section 3.3.1 of [RFC9497], which is		functionality based on Section 3.3.1 of [RFC9497], which is
	identical to the DH-OPRF functionality in [JKX18] and, concretely,		identical to the DH-OPRF functionality in [JKX18Full] and,
	uses the hash-to-curve functions in [RFC9380]. All hash-to-curve		concretely, uses the hash-to-curve functions in [RFC9380]. All
	methods in [RFC9380] are compliant with the requirement in		hash-to-curve methods in [RFC9380] are compliant with the
	[JKX18], namely, that the output be a member of the prime-order		requirement in [JKX18Full], namely, that the output be a member of
	group.		the prime-order group.
	* [JKX18] and [Krawczyk20] both used HMQV as the AKE for the		* [JKX18Full] and [Krawczyk20] both used HMQV as the AKE for the
	protocol. However, this document fully specifies 3DH instead of		protocol. However, this document fully specifies 3DH instead of
	HMQV (though a sketch for how to instantiate OPAQUE using HMQV is		HMQV (though a sketch for how to instantiate OPAQUE using HMQV is
	included in Appendix B.1). Since 3DH satisfies the essential		included in Appendix B.1). Since 3DH satisfies the essential
	requirements for the AKE as described in [JKX18] and [Krawczyk20],		requirements for the AKE protocol as described in [JKX18Full] and
	as recalled in Section 10.2, this change preserves the overall		[Krawczyk20], as recalled in Section 10.2, this change preserves
	security of the protocol. 3DH was chosen for its simplicity and		the overall security of the protocol. 3DH was chosen for its
	ease of implementation.		simplicity and ease of implementation.
	* The DH-OPRF and HMQV instantiation of OPAQUE in Figure 12 [JKX18]		* The DH-OPRF and HMQV instantiation of OPAQUE as shown in Figure 12
	uses a different transcript than that which is described in this		[JKX18Full] uses a different transcript than that which is
	specification. In particular, the key exchange transcript		described in this specification. In particular, the key exchange
	specified in Section 6.4 is a superset of the transcript as		transcript specified in Section 6.4 is a superset of the
	defined in [JKX18]. This was done to align with best practices,		transcript as defined in [JKX18Full]. This was done to align with
	like what is done for key exchange protocols like TLS 1.3		best practices, like what is done for key exchange protocols like
	[RFC8446].		TLS 1.3 [RFC8446].
	* Neither [JKX18] nor [Krawczyk20] included wire format details for		* Neither [JKX18Full] nor [Krawczyk20] included wire format details
	the protocol, which is essential for interoperability. This		for the protocol, which is essential for interoperability. This
	specification fills this gap by including such wire format details		specification fills this gap by including such wire format details
	and corresponding test vectors; see Appendix C.		and corresponding test vectors; see Appendix C.
	10.2. Security Analysis		10.2. Security Analysis
	Jarecki et al. [JKX18] proved the security of OPAQUE (modulo the		Jarecki et al. [JKX18Full] proved the security of OPAQUE (modulo the
	design differences outlined in Section 10.1) in a strong aPAKE model		design differences outlined in Section 10.1) in a strong aPAKE model
	that ensures security against precomputation attacks and is		that ensures security against precomputation attacks and is
	formulated in the UC framework [Canetti01] under the random oracle		formulated in the UC framework [Canetti01] under the random oracle
	model. This assumes security of the OPRF function and the underlying		model. This assumes security of the OPRF function and the underlying
	key exchange protocol.		key exchange protocol.
	OPAQUE's design builds on a line of work initiated in the seminal		OPAQUE's design builds on a line of work initiated in the seminal
	paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol		paper of Ford and Kaliski [FK00] and is based on the HPAKE protocol
	of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et		of Xavier Boyen [Boyen09] and the (1,1)-PPSS protocol from Jarecki et
	al. [JKKX16]. None of these papers considered security against		al. [JKKX16]. None of these papers considered security against
	skipping to change at line 2202 ¶		skipping to change at line 2206 ¶
	authenticated protocols, e.g., HMQV, but not all of them. We also		authenticated protocols, e.g., HMQV, but not all of them. We also
	note that key exchange protocols based on shared keys do not satisfy		note that key exchange protocols based on shared keys do not satisfy
	the KCI requirement, hence they are not considered in the OPAQUE		the KCI requirement, hence they are not considered in the OPAQUE
	setting. We note that KCI is needed to ensure a crucial property of		setting. We note that KCI is needed to ensure a crucial property of
	OPAQUE. Even upon compromise of the server, the attacker cannot		OPAQUE. Even upon compromise of the server, the attacker cannot
	impersonate the client to the server without first running an		impersonate the client to the server without first running an
	exhaustive dictionary attack. Another essential requirement from AKE		exhaustive dictionary attack. Another essential requirement from AKE
	protocols for use in OPAQUE is to provide forward secrecy (against		protocols for use in OPAQUE is to provide forward secrecy (against
	active attackers).		active attackers).
	In [JKX18], security is proven for one instance (i.e., one key) of		In [JKX18Full], security is proven for one instance (i.e., one key)
	the OPAQUE protocol, and without batching. There is currently no		of the OPAQUE protocol, and without batching. There is currently no
	security analysis available for the OPAQUE protocol described in this		security analysis available for the OPAQUE protocol described in this
	document in a setting with multiple server keys or batching.		document in a setting with multiple server keys or batching.
	As stated in Section 9.1, incorporating client_identity adds domain		As stated in Section 9.1, incorporating client_identity adds domain
	separation, particularly against servers that choose the same OPRF		separation, particularly against servers that choose the same OPRF
	key for multiple clients. The client_identity as input to the OPRF		key for multiple clients. The client_identity as input to the OPRF
	also acts as a key identifier that would be required for a proof of		also acts as a key identifier that would be required for a proof of
	the protocol in the multi-key setting; the OPAQUE analysis in [JKX18]		the protocol in the multi-key setting; the OPAQUE analysis in
	assumes single server-key instances. Adding server_identity to the		[JKX18Full] assumes single server-key instances. Adding
	OPRF input provides domain separation for clients that reuse the same		server_identity to the OPRF input provides domain separation for
	client_identity across different server instantiations.		clients that reuse the same client_identity across different server
			instantiations.
	10.3. Identities		10.3. Identities
	AKE protocols generate keys that need to be uniquely and verifiably		AKE protocols generate keys that need to be uniquely and verifiably
	bound to a pair of identities. In the case of OPAQUE, those		bound to a pair of identities. In the case of OPAQUE, those
	identities correspond to client_identity and server_identity. Thus,		identities correspond to client_identity and server_identity. Thus,
	it is essential for the parties to agree on such identities,		it is essential for the parties to agree on such identities,
	including an agreed bit representation of these identities as needed.		including an agreed bit representation of these identities as needed.
	Note that the method of transmission of client_identity from client		Note that the method of transmission of client_identity from client
	skipping to change at line 2327 ¶		skipping to change at line 2332 ¶
	shared secret is not the point at infinity.		shared secret is not the point at infinity.
	10.8. OPRF Key Stretching		10.8. OPRF Key Stretching
	Applying a key stretching function to the output of the OPRF greatly		Applying a key stretching function to the output of the OPRF greatly
	increases the cost of an offline attack upon the compromise of the		increases the cost of an offline attack upon the compromise of the
	credential file on the server. Applications SHOULD select parameters		credential file on the server. Applications SHOULD select parameters
	for the KSF that balance cost and complexity across different client		for the KSF that balance cost and complexity across different client
	implementations and deployments. Note that in OPAQUE, the key		implementations and deployments. Note that in OPAQUE, the key
	stretching function is executed by the client as opposed to the		stretching function is executed by the client as opposed to the
	server in traditional password hashing scenarios. This means that		server in common password hashing scenarios. This means that
	applications must consider a tradeoff between the performance of the		applications must consider a tradeoff between the performance of the
	protocol on clients (specifically low-end devices) and protection		protocol on clients (specifically low-end devices) and protection
	against offline attacks after a server compromise.		against offline attacks after a server compromise.
	10.9. Client Enumeration		10.9. Client Enumeration
	Client enumeration refers to attacks where the attacker tries to		Client enumeration refers to attacks where the attacker tries to
	learn whether a given user identity is registered with a server or		learn whether a given user identity is registered with a server or
	whether a reregistration or change of password was performed for that		whether a reregistration or change of password was performed for that
	user. OPAQUE counters these attacks by requiring servers to act with		user. OPAQUE counters these attacks by requiring servers to act with
	skipping to change at line 2475 ¶		skipping to change at line 2480 ¶
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC9497] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.		[RFC9497] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. A.
	Wood, "Oblivious Pseudorandom Functions (OPRFs) Using		Wood, "Oblivious Pseudorandom Functions (OPRFs) Using
	Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497,		Prime-Order Groups", RFC 9497, DOI 10.17487/RFC9497,
	December 2023, <https://www.rfc-editor.org/info/rfc9497>.		December 2023, <https://www.rfc-editor.org/info/rfc9497>.
	12.2. Informative References		12.2. Informative References
	[ARGON2] Biryukov, A., Dinu, D., Khovratovich, D., and S.
	Josefsson, "Argon2 Memory-Hard Function for Password
	Hashing and Proof-of-Work Applications", RFC 9106,
	DOI 10.17487/RFC9106, September 2021,
	<https://www.rfc-editor.org/info/rfc9106>.
	[BG04] Brown, D. and R. Galant, "The Static Diffie-Hellman		[BG04] Brown, D. and R. Galant, "The Static Diffie-Hellman
	Problem", Cryptology ePrint Archive, Paper 2004/306, 2004,		Problem", Cryptology ePrint Archive, Paper 2004/306, 2004,
	<https://eprint.iacr.org/2004/306>.		<https://eprint.iacr.org/2004/306>.
	[Boyen09] Boyen, X., "HPAKE: Password Authentication Secure against		[Boyen09] Boyen, X., "HPAKE: Password Authentication Secure against
	Cross-Site User Impersonation", Cryptology and Network		Cross-Site User Impersonation", Cryptology and Network
	Security (CANS 2009), Lecture Notes in Computer Science,		Security (CANS 2009), Lecture Notes in Computer Science,
	vol. 5888, pp. 279-298, DOI 10.1007/978-3-642-10433-6_19,		vol. 5888, pp. 279-298, DOI 10.1007/978-3-642-10433-6_19,
	2009, <https://doi.org/10.1007/978-3-642-10433-6_19>.		2009, <https://doi.org/10.1007/978-3-642-10433-6_19>.
	skipping to change at line 2504 ¶		skipping to change at line 2503 ¶
	on Foundations of Computer Science, pp. 136-145,		on Foundations of Computer Science, pp. 136-145,
	DOI 10.1109/SFCS.2001.959888, 2001,		DOI 10.1109/SFCS.2001.959888, 2001,
	<https://doi.org/10.1109/SFCS.2001.959888>.		<https://doi.org/10.1109/SFCS.2001.959888>.
	[Cheon06] Cheon, J. H., "Security Analysis of the Strong Diffie-		[Cheon06] Cheon, J. H., "Security Analysis of the Strong Diffie-
	Hellman Problem", Advances in Cryptology - EUROCRYPT 2006,		Hellman Problem", Advances in Cryptology - EUROCRYPT 2006,
	Lecture Notes in Computer Science, vol. 4004, pp. 1-11,		Lecture Notes in Computer Science, vol. 4004, pp. 1-11,
	DOI 10.1007/11761679_1, 2006,		DOI 10.1007/11761679_1, 2006,
	<https://doi.org/10.1007/11761679_1>.		<https://doi.org/10.1007/11761679_1>.
	[Curve25519]
	Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
	for Security", RFC 7748, DOI 10.17487/RFC7748, January
	2016, <https://www.rfc-editor.org/info/rfc7748>.
	[DL24] Dayanikli, D. and A. Lehmann, "(Strong) aPAKE Revisited:		[DL24] Dayanikli, D. and A. Lehmann, "(Strong) aPAKE Revisited:
	Capturing Multi-User Security and Salting", Cryptology		Capturing Multi-User Security and Salting", Cryptology
	ePrint Archive, Paper 2024/756, 2024,		ePrint Archive, Paper 2024/756, 2024,
	<https://eprint.iacr.org/2024/756>.		<https://eprint.iacr.org/2024/756>.
	[FIPS202] NIST, "SHA-3 Standard: Permutation-Based Hash and		[FIPS202] NIST, "SHA-3 Standard: Permutation-Based Hash and
	Extendable-Output Functions", NIST FIPS 202,		Extendable-Output Functions", NIST FIPS 202,
	DOI 10.6028/NIST.FIPS.202, August 2015,		DOI 10.6028/NIST.FIPS.202, August 2015,
	<https://nvlpubs.nist.gov/nistpubs/FIPS/		<https://nvlpubs.nist.gov/nistpubs/FIPS/
	NIST.FIPS.202.pdf>.		NIST.FIPS.202.pdf>.
	skipping to change at line 2545 ¶		skipping to change at line 2539 ¶
	Hellman Protocol", Cryptology ePrint Archive, Paper		Hellman Protocol", Cryptology ePrint Archive, Paper
	2005/176, 2005, <https://eprint.iacr.org/2005/176>.		2005/176, 2005, <https://eprint.iacr.org/2005/176>.
	[JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu,		[JKKX16] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu,
	"Highly-Efficient and Composable Password-Protected Secret		"Highly-Efficient and Composable Password-Protected Secret
	Sharing (Or: How to Protect Your Bitcoin Wallet Online)",		Sharing (Or: How to Protect Your Bitcoin Wallet Online)",
	2016 IEEE European Symposium on Security and Privacy		2016 IEEE European Symposium on Security and Privacy
	(EuroS&P), pp. 276-291, DOI 10.1109/EuroSP.2016.30, 2016,		(EuroS&P), pp. 276-291, DOI 10.1109/EuroSP.2016.30, 2016,
	<https://doi.org/10.1109/EuroSP.2016.30>.		<https://doi.org/10.1109/EuroSP.2016.30>.
	[JKX18] Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An
	Asymmetric PAKE Protocol Secure Against Pre-Computation
	Attacks", Advances in Cryptology – EUROCRYPT 2018, Lecture
	Notes in Computer Science, vol. 10822, pp. 456-486,
	DOI 10.1007/978-3-319-78372-7_15, 2018,
	<https://doi.org/10.1007/978-3-319-78372-7_15>.
	[JKX18Full]		[JKX18Full]
	Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An		Jarecki, S., Krawczyk, H., and J. Xu, "OPAQUE: An
	Asymmetric PAKE Protocol Secure Against Pre-Computation		Asymmetric PAKE Protocol Secure Against Pre-Computation
	Attacks", Cryptology ePrint Archive, Paper 2018/163, 2018,		Attacks", Cryptology ePrint Archive, Paper 2018/163, 2018,
	<https://eprint.iacr.org/2018/163>.		<https://eprint.iacr.org/2018/163>.
	[keyagreement]		[keyagreement]
	Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.		Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
	Davis, "Recommendation for Pair-Wise Key-Establishment		Davis, "Recommendation for Pair-Wise Key-Establishment
	Schemes Using Discrete Logarithm Cryptography",		Schemes Using Discrete Logarithm Cryptography",
	skipping to change at line 2576 ¶		skipping to change at line 2563 ¶
	Krawczyk, H., "The OPAQUE Asymmetric PAKE Protocol", Work		Krawczyk, H., "The OPAQUE Asymmetric PAKE Protocol", Work
	in Progress, Internet-Draft, draft-krawczyk-cfrg-opaque-		in Progress, Internet-Draft, draft-krawczyk-cfrg-opaque-
	06, 19 June 2020, <https://datatracker.ietf.org/doc/html/		06, 19 June 2020, <https://datatracker.ietf.org/doc/html/
	draft-krawczyk-cfrg-opaque-06>.		draft-krawczyk-cfrg-opaque-06>.
	[LGR20] Len, J., Grubbs, P., and T. Ristenpart, "Partitioning		[LGR20] Len, J., Grubbs, P., and T. Ristenpart, "Partitioning
	Oracle Attacks", Cryptology ePrint Archive, Paper		Oracle Attacks", Cryptology ePrint Archive, Paper
	2020/1491, 2021, <https://eprint.iacr.org/2020/1491.pdf>.		2020/1491, 2021, <https://eprint.iacr.org/2020/1491.pdf>.
	[NISTCurves]		[NISTCurves]
	NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-4,		NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5,
	DOI 10.6028/nist.fips.186-4, 2013,		DOI 10.6028/nist.fips.186-5, 2013,
	<https://doi.org/10.6028/nist.fips.186-4>.		<https://doi.org/10.6028/nist.fips.186-5>.
	[PBKDF2] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
	Password-Based Cryptography Specification Version 2.1",
	RFC 8018, DOI 10.17487/RFC8018, January 2017,
	<https://www.rfc-editor.org/info/rfc8018>.
	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand		[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,		Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,		DOI 10.17487/RFC5869, May 2010,
	<https://www.rfc-editor.org/info/rfc5869>.		<https://www.rfc-editor.org/info/rfc5869>.
			[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
			for Security", RFC 7748, DOI 10.17487/RFC7748, January
			2016, <https://www.rfc-editor.org/info/rfc7748>.
			[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
			Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
			August 2016, <https://www.rfc-editor.org/info/rfc7914>.
	[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,		[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
	"PKCS #1: RSA Cryptography Specifications Version 2.2",		"PKCS #1: RSA Cryptography Specifications Version 2.2",
	RFC 8017, DOI 10.17487/RFC8017, November 2016,		RFC 8017, DOI 10.17487/RFC8017, November 2016,
	<https://www.rfc-editor.org/info/rfc8017>.		<https://www.rfc-editor.org/info/rfc8017>.
			[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
			Password-Based Cryptography Specification Version 2.1",
			RFC 8018, DOI 10.17487/RFC8018, January 2017,
			<https://www.rfc-editor.org/info/rfc8018>.
	[RFC8125] Schmidt, J., "Requirements for Password-Authenticated Key		[RFC8125] Schmidt, J., "Requirements for Password-Authenticated Key
	Agreement (PAKE) Schemes", RFC 8125, DOI 10.17487/RFC8125,		Agreement (PAKE) Schemes", RFC 8125, DOI 10.17487/RFC8125,
	April 2017, <https://www.rfc-editor.org/info/rfc8125>.		April 2017, <https://www.rfc-editor.org/info/rfc8125>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
			[RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S.
			Josefsson, "Argon2 Memory-Hard Function for Password
			Hashing and Proof-of-Work Applications", RFC 9106,
			DOI 10.17487/RFC9106, September 2021,
			<https://www.rfc-editor.org/info/rfc9106>.
	[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid		[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
	Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,		Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
	February 2022, <https://www.rfc-editor.org/info/rfc9180>.		February 2022, <https://www.rfc-editor.org/info/rfc9180>.
	[RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S.,		[RFC9380] Faz-Hernandez, A., Scott, S., Sullivan, N., Wahby, R. S.,
	and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380,		and C. A. Wood, "Hashing to Elliptic Curves", RFC 9380,
	DOI 10.17487/RFC9380, August 2023,		DOI 10.17487/RFC9380, August 2023,
	<https://www.rfc-editor.org/info/rfc9380>.		<https://www.rfc-editor.org/info/rfc9380>.
	[RISTRETTO]		[RFC9496] de Valence, H., Grigg, J., Hamburg, M., Lovecruft, I.,
	de Valence, H., Grigg, J., Hamburg, M., Lovecruft, I.,
	Tankersley, G., and F. Valsorda, "The ristretto255 and		Tankersley, G., and F. Valsorda, "The ristretto255 and
	decaf448 Groups", RFC 9496, DOI 10.17487/RFC9496, December		decaf448 Groups", RFC 9496, DOI 10.17487/RFC9496, December
	2023, <https://www.rfc-editor.org/info/rfc9496>.		2023, <https://www.rfc-editor.org/info/rfc9496>.
	[SCRYPT] Percival, C. and S. Josefsson, "The scrypt Password-Based
	Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
	August 2016, <https://www.rfc-editor.org/info/rfc7914>.
	[SIGMA-I] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to		[SIGMA-I] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to
	Authenticated Diffie-Hellman and its Use in the IKE		Authenticated Diffie-Hellman and its Use in the IKE
	Protocols", 2003,		Protocols", 2003,
	<https://www.iacr.org/cryptodb/archive/2003/		<https://www.iacr.org/cryptodb/archive/2003/
	CRYPTO/1495/1495.pdf>.		CRYPTO/1495/1495.pdf>.
	[TOPPSS] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu,		[TOPPSS] Jarecki, S., Kiayias, A., Krawczyk, H., and J. Xu,
	"TOPPSS: Cost-Minimal Password-Protected Secret Sharing		"TOPPSS: Cost-Minimal Password-Protected Secret Sharing
	based on Threshold OPRF", Applied Cryptology and Network		based on Threshold OPRF", Applied Cryptology and Network
	Security - ACNS 2017, Lecture Notes in Computer Science,		Security - ACNS 2017, Lecture Notes in Computer Science,
	skipping to change at line 2674 ¶		skipping to change at line 2670 ¶
	[HMQV] and SIGMA-I [SIGMA-I]. HMQV is similar to 3DH but varies in		[HMQV] and SIGMA-I [SIGMA-I]. HMQV is similar to 3DH but varies in
	its key schedule. SIGMA-I uses digital signatures rather than static		its key schedule. SIGMA-I uses digital signatures rather than static
	DH keys for authentication. Specification of these instantiations is		DH keys for authentication. Specification of these instantiations is
	left to future documents. A sketch of how these instantiations might		left to future documents. A sketch of how these instantiations might
	change is included in the next subsection for posterity.		change is included in the next subsection for posterity.
	OPAQUE may also be instantiated with any post-quantum (PQ) AKE		OPAQUE may also be instantiated with any post-quantum (PQ) AKE
	protocol that has the message flow above and security properties (KCI		protocol that has the message flow above and security properties (KCI
	resistance and forward secrecy) outlined in Section 10. Note that		resistance and forward secrecy) outlined in Section 10. Note that
	such an instantiation is not quantum-safe unless the OPRF is quantum-		such an instantiation is not quantum-safe unless the OPRF is quantum-
	safe. However, an OPAQUE instantiation where the AKE is quantum-		safe. However, an OPAQUE instantiation where the AKE protocol is
	safe, but the OPRF is not, would still ensure the confidentiality and		quantum-safe, but the OPRF is not, would still ensure the
	integrity of application data encrypted under session_key (or a key		confidentiality and integrity of application data encrypted under
	derived from it) with a quantum-safe encryption function. However,		session_key (or a key derived from it) with a quantum-safe encryption
	the only effect of a break of the OPRF by a future quantum attacker		function. However, the only effect of a break of the OPRF by a
	would be the ability of this attacker to run at that time an		future quantum attacker would be the ability of this attacker to run
	exhaustive dictionary attack against the old user's password and only		at that time an exhaustive dictionary attack against the old user's
	for users whose envelopes were harvested while in use (in the case of		password and only for users whose envelopes were harvested while in
	OPAQUE run over a TLS channel with the server, harvesting such		use (in the case of OPAQUE run over a TLS channel with the server,
	envelopes requires targeted active attacks).		harvesting such envelopes requires targeted active attacks).
	B.1. HMQV Instantiation Sketch		B.1. HMQV Instantiation Sketch
	An HMQV instantiation would work similarly to OPAQUE-3DH, differing		An HMQV instantiation would work similarly to OPAQUE-3DH, differing
	primarily in the key schedule [HMQV]. First, the key schedule		primarily in the key schedule [HMQV]. First, the key schedule
	preamble value would use a different constant prefix -- "HMQV"		preamble value would use a different constant prefix -- "HMQV"
	instead of "3DH" -- as shown below.		instead of "3DH" -- as shown below.
	preamble = concat("HMQV",		preamble = concat("HMQV",
	I2OSP(len(client_identity), 2), client_identity,		I2OSP(len(client_identity), 2), client_identity,
End of changes. 53 change blocks.
	171 lines changed or deleted		167 lines changed or added
This html diff was produced by rfcdiff 1.48.