rfc9807.original.xml   rfc9807.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.3. -irtf-cfrg-opaque-18" number="9807" consensus="true" updates="" obsoletes="" sub
6) --> missionType="IRTF" category="info" tocInclude="true" sortRefs="true" symRefs="tr
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ue" version="3" xml:lang="en">
-irtf-cfrg-opaque-18" category="info" tocInclude="true" sortRefs="true" symRefs=
"true" version="3"> <!-- [rfced] We have expanded (and updated) the abbreviation "PAKE" in
<!-- xml2rfc v2v3 conversion 3.24.0 --> document title as follows for consistency regarding the use of "aPAKE"
throughout the document. Please let us know if you prefer
otherwise. Also, please let us know if you prefer the "Perhaps" option or
otherwise.
Original:
The OPAQUE Augmented PAKE Protocol
Current:
The OPAQUE Augmented Password-Authenticated Key Exchange (aPAKE) Protocol
Perhaps:
OPAQUE: An Augmented Password-Authenticated Key Exchange (aPAKE) Protocol
-->
<front> <front>
-&gt; <title abbrev="OPAQUE">The OPAQUE Augmented Password-Authenticated Key Excha
<title abbrev="OPAQUE">The OPAQUE Augmented PAKE Protocol</title> nge (aPAKE) Protocol</title>
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-opaque-18"/> <seriesInfo name="RFC" value="9807"/>
<author initials="D." surname="Bourdrez" fullname="Daniel Bourdrez"> <author initials="D." surname="Bourdrez" fullname="Daniel Bourdrez">
<organization/>
<address> <address>
<email>d@bytema.re</email> <email>d@bytema.re</email>
</address> </address>
</author> </author>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk"> <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization>AWS</organization> <organization>AWS</organization>
<address> <address>
<email>hugokraw@gmail.com</email> <email>hugokraw@gmail.com</email>
</address> </address>
</author> </author>
skipping to change at line 39 skipping to change at line 52
<address> <address>
<email>lewi.kevin.k@gmail.com</email> <email>lewi.kevin.k@gmail.com</email>
</address> </address>
</author> </author>
<author initials="C. A." surname="Wood" fullname="Christopher A. Wood"> <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare, Inc.</organization> <organization>Cloudflare, Inc.</organization>
<address> <address>
<email>caw@heapingbits.net</email> <email>caw@heapingbits.net</email>
</address> </address>
</author> </author>
<date year="2024" month="November" day="22"/> <date year="2025" month="June"/>
<keyword>Internet-Draft</keyword> <workgroup>Crypto Forum</workgroup>
<abstract>
<?line 258?>
<t>This document describes the OPAQUE protocol, an augmented (or asymmetric) <!-- [rfced] Please insert any keywords (beyond those that appear in
password-authenticated key exchange (aPAKE) that supports mutual the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<!--[rfced] Please ensure that the guidelines listed in Section 2.1 of
RFC 5743 have been adhered to in this document. -->
<abstract>
<t>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 authentication in a client-server setting without reliance on PKI and
with security against pre-computation attacks upon server compromise. with security against pre-computation attacks upon server compromise.
In addition, the protocol provides forward secrecy and the ability to In addition, the protocol provides forward secrecy and the ability to
hide the password from the server, even during password registration. hide the password from the server, even during password registration.
This document specifies the core OPAQUE protocol and one instantiation This document specifies the core OPAQUE protocol and one instantiation
based on 3DH. This document is a product of the Crypto Forum Research based on 3DH. This document is a product of the Crypto Forum Research
Group (CFRG) in the IRTF.</t> Group (CFRG) in the IRTF.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/cfrg/draft-irtf-cfrg-opaque"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 270?>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>Password authentication is ubiquitous in many applications. In a common <t>Password authentication is ubiquitous in many applications. In a common
implementation, a client authenticates to a server by sending its client implementation, a client authenticates to a server by sending its client
ID and password to the server over a secure connection. This makes ID and password to the server over a secure connection. This makes
the password vulnerable to server mishandling, including accidentally the password vulnerable to server mishandling, including accidentally
logging the password or storing it in plaintext in a database. Server logging the password or storing it in plaintext in a database. Server
compromise resulting in access to these plaintext passwords is not an compromise resulting in access to these plaintext passwords is not an
uncommon security incident, even among security-conscious organizations. uncommon security incident, even among security-conscious organizations. Moreove
Moreover, plaintext password authentication over secure channels such as r, plaintext password authentication over secure channels such as
TLS is also vulnerable to cases where TLS may fail, including PKI TLS is also vulnerable in cases where TLS may fail, including PKI
attacks, certificate mishandling, termination outside the security attacks, certificate mishandling, termination outside the security
perimeter, visibility to TLS-terminating intermediaries, and more.</t> perimeter, visibility to TLS-terminating intermediaries, and more.</t>
<t>Augmented (or Asymmetric) Password Authenticated Key Exchange (aPAKE) <t>Augmented (or Asymmetric) Password Authenticated Key Exchange (aPAKE)
protocols are designed to provide password authentication and protocols are designed to provide password authentication and
mutually authenticated key exchange in a client-server setting without mutually authenticated key exchange in a client-server setting without
relying on PKI (except during client registration) and without relying on PKI (except during client registration) and without
disclosing passwords to servers or other entities other than the client disclosing passwords to servers or other entities other than the client
machine. A secure aPAKE should provide the best possible security for a machine. A secure aPAKE should provide the best possible security for a
password protocol. Indeed, some attacks are inevitable, such as password protocol. Indeed, some attacks are inevitable, such as
online impersonation attempts with guessed client passwords and offline online impersonation attempts with guessed client passwords and offline
dictionary attacks upon the compromise of a server and leakage of its dictionary attacks upon the compromise of a server and leakage of its
credential file. In the latter case, the attacker learns a mapping of credential file. In the latter case, the attacker learns a mapping of
a client's password under a one-way function and uses such a mapping to a client's password under a one-way function and uses such a mapping to
validate potential guesses for the password. Crucially important is validate potential guesses for the password. It is crucially important for the p
for the password protocol to use an unpredictable one-way mapping. assword protocol to use an unpredictable one-way mapping.
Otherwise, the attacker can pre-compute a deterministic list of mapped Otherwise, the attacker can pre-compute a deterministic list of mapped
passwords leading to almost instantaneous leakage of passwords upon passwords leading to almost instantaneous leakage of passwords upon
server compromise.</t> server compromise.</t>
<t>This document describes OPAQUE, an aPAKE that is secure against <t>This document describes OPAQUE, an aPAKE that is secure against
pre-computation attacks (as defined in <xref target="JKX18"/>). OPAQUE provides forward pre-computation attacks (as defined in <xref target="JKX18"/>). OPAQUE provides forward
secrecy with respect to password leakage while also hiding the password from secrecy with respect to password leakage while also hiding the password from
the server, even during password registration. OPAQUE allows applications the server, even during password registration. OPAQUE allows applications
to increase the difficulty of offline dictionary attacks via iterated to increase the difficulty of offline dictionary attacks via iterated
hashing or other key-stretching schemes. OPAQUE is also extensible, allowing hashing or other key-stretching schemes. OPAQUE is also extensible, allowing
clients to safely store and retrieve arbitrary application data on servers clients to safely store and retrieve arbitrary application data on servers
using only their password.</t> using only their password.</t>
<t>OPAQUE is defined and proven as the composition of three functionalitie s: <t>OPAQUE is defined and proven as the composition of three functionalitie s:
an oblivious pseudorandom function (OPRF), a key recovery mechanism, an Oblivious Pseudorandom Function (OPRF), a key recovery mechanism,
and an authenticated key exchange (AKE) protocol. It can be seen and an authenticated key exchange (AKE) protocol. It can be seen
as a "compiler" for transforming any suitable AKE protocol into a secure as a "compiler" for transforming any suitable AKE protocol into a secure
aPAKE protocol. (See <xref target="security-considerations"/> for requirements o f the aPAKE protocol. (See <xref target="security-considerations"/> for requirements o f the
OPRF and AKE protocols.) This document specifies one OPAQUE instantiation OPRF and AKE protocols.) This document specifies one OPAQUE instantiation
based on <xref target="TripleDH"/>. Other instantiations are possible, as discus sed in based on <xref target="TripleDH"/>. Other instantiations are possible, as discus sed in
<xref target="alternate-akes"/>, but their details are out of scope for this doc ument. <xref target="alternate-akes"/>, but their details are out of scope for this doc ument.
<!-- [rfced] Is "ones" referring to "future AKE protocols" in this sentence?
Additionally, should "HMQV" be expanded as "Hashed Menezes-Qu-Vanston" or
otherwise?
Original:
In general, the modularity of OPAQUE's 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- quantum techniques.
Perhaps:
In general, the modularity of OPAQUE's
design makes it easy to integrate with additional AKE protocols,
e.g., TLS or HMQV (Hashed Menezes-Qu-Vanstone), and with future AKE
protocols such as those based on post-quantum techniques.
-->
In general, the modularity of OPAQUE's design makes it easy to integrate In general, the modularity of OPAQUE's design makes it easy to integrate
with additional AKE protocols, e.g., TLS or HMQV, and with future ones such with additional AKE protocols, e.g., TLS or HMQV, and with future ones such
as those based on post-quantum techniques.</t> as those based on post-quantum techniques.</t>
<t>OPAQUE consists of two stages: registration and authenticated key excha nge. <t>OPAQUE consists of two stages: registration and authenticated key excha nge.
In the first stage, a client registers its password with the server and stores In the first stage, a client registers its password with the server and stores
information used to recover authentication credentials on the server. Recovering these information used to recover authentication credentials on the server. Recovering these
credentials can only be done with knowledge of the client password. In the secon d credentials can only be done with knowledge of the client password. In the secon d
stage, a client uses its password to recover those credentials and subsequently stage, a client uses its password to recover those credentials and subsequently
uses them as input to an AKE protocol. This stage has additional mechanisms to uses them as input to an AKE protocol. This stage has additional mechanisms to
prevent an active attacker from interacting with the server to guess or confirm prevent an active attacker from interacting with the server to guess or confirm
clients registered via the first phase. Servers can use this mechanism to safegu ard clients registered via the first phase. Servers can use this mechanism to safegu ard
registered clients against this type of enumeration attack; see registered clients against this type of enumeration attack; see
<xref target="preventing-client-enumeration"/> for more discussion.</t> <xref target="preventing-client-enumeration"/> for more discussion.</t>
<t>The name OPAQUE is a homonym of O-PAKE where O is for Oblivious. The na <!-- [rfced] The sentence below seems out of place at the end of the
me Introduction. May we place this sentence in the abstract where "OPAQUE"
OPAKE was taken.</t> is first introduced?
<t>This draft complies with the requirements for PAKE protocols set forth
in Original:
The name OPAQUE is a homonym of O-PAKE where O is for Oblivious. The
name OPAKE was taken.
Current:
The name "OPAQUE" is a homonym of O-PAKE, where O is for Oblivious.
The name "OPAKE" was taken.
Perhaps (if moved to the abstract, perhaps make two paragraphs):
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. The name
"OPAQUE" is a homonym of O-PAKE, where O is for Oblivious.
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.
-->
<t>The name "OPAQUE" is a homonym of O-PAKE, where O is for Oblivious. The name
"OPAKE" was taken.</t>
<t>This document complies with the requirements for PAKE protocols set for
th in
<xref target="RFC8125"/>. This document represents the consensus of the Crypto F orum <xref target="RFC8125"/>. This document represents the consensus of the Crypto F orum
Research Group (CFRG). It is not an IETF product and is not a standard.</t> Research Group (CFRG). It is not an IETF product and is not a standard.</t>
<section anchor="requirements-notation"> <section anchor="requirements-notation">
<name>Requirements Notation</name> <name>Requirements Notation</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
only when, they RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<?line -6?> be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section> </section>
<section anchor="notation"> <section anchor="notation">
<name>Notation</name> <name>Notation</name>
<t>The following functions are used throughout this document:</t> <t>The following functions are used throughout this document:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>I2OSP and OS2IP:</dt><dd>Convert a byte string to and from a non-n
<t>I2OSP and OS2IP: Convert a byte string to and from a non-negative egative
integer as integer as described in <xref section="4" target="RFC8017"/>. Note
described in Section 4 of <xref target="RFC8017"/>. Note that these functions op that these functions operate on byte strings in big-endian byte
erate on order.</dd>
byte strings in big-endian byte order.</t> <dt>concat(x0, ..., xN):</dt><dd>Concatenate byte strings. For example
</li> ,
<li> <tt>concat(0x01, 0x0203, 0x040506) = 0x010203040506</tt>.</dd>
<t>concat(x0, ..., xN): Concatenate byte strings. For example, <dt>random(n):</dt><dd>Generates a cryptographically secure
<tt>concat(0x01, 0x0203, 0x040506) = 0x010203040506</tt>.</t> pseudorandom byte string of length <tt>n</tt> bytes.</dd>
</li> <dt>zeroes(n):</dt><dd>Generate a string of <tt>n</tt> bytes all
<li> equal to 0 (zero).</dd>
<t>random(n): Generate a cryptographically secure pseudorandom byte <dt>xor(a,b):</dt><dd>Apply XOR to byte strings. For example, <tt>xor(
string of length <tt>n</tt> bytes.</t> 0xF0F0,
</li> 0x1234) = 0xE2C4</tt>. It is an error to call this function with
<li> arguments of unequal length.</dd>
<t>zeroes(n): Generate a string of <tt>n</tt> bytes all equal to 0 ( <dt>ct_equal(a, b):</dt><dd>Return <tt>true</tt> if <tt>a</tt> is equal
zero).</t> to
</li> <tt>b</tt>, and false otherwise. The implementation of this
<li> function must be constant-time in the length of <tt>a</tt> and
<t>xor(a,b): Apply XOR to byte strings. For example, <tt>xor(0xF0F0, <tt>b</tt>, which are assumed to be of equal length, irrespective of
0x1234) = 0xE2C4</tt>. the values <tt>a</tt> or <tt>b</tt>.</dd>
It is an error to call this function with arguments of unequal length.</t> </dl>
</li>
<li>
<t>ct_equal(a, b): Return <tt>true</tt> if <tt>a</tt> is equal to <t
t>b</tt>, and false otherwise.
The implementation of this function must be constant-time in the length of <tt>a
</tt>
and <tt>b</tt>, which are assumed to be of equal length, irrespective of the val
ues <tt>a</tt>
or <tt>b</tt>.</t>
</li>
</ul>
<t>Except if said otherwise, random choices in this specification refer to <t>Except if said otherwise, random choices in this specification refer to
drawing with uniform distribution from a given set (i.e., "random" is short drawing with uniform distribution from a given set (i.e., "random" is short
for "uniformly random"). Random choices can be replaced with fresh outputs from for "uniformly random"). Random choices can be replaced with fresh outputs from
a cryptographically strong pseudorandom generator, according to the requirements a cryptographically strong pseudorandom generator, according to the requirements
in <xref target="RFC4086"/>, or pseudorandom function. For convenience, we defin e <tt>nil</tt> as a in <xref target="RFC4086"/>, or a pseudorandom function. For convenience, we def ine <tt>nil</tt> as a
lack of value.</t> lack of value.</t>
<t>All protocol messages and structures defined in this document use the syntax from <t>All protocol messages and structures defined in this document use the syntax from
Section 3 of <xref target="RFC8446"/>.</t> <xref section="3" target="RFC8446"/>.</t>
</section> </section>
</section> </section>
<section anchor="dependencies"> <section anchor="dependencies">
<name>Cryptographic Dependencies</name> <name>Cryptographic Dependencies</name>
<t>OPAQUE depends on the following cryptographic protocols and primitives: </t> <t>OPAQUE depends on the following cryptographic protocols and primitives: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Oblivious Pseudorandom Function (OPRF); <xref target="deps-oprf"/>< /t> <t>Oblivious Pseudorandom Function (OPRF); <xref target="deps-oprf"/>< /t>
</li> </li>
<li> <li>
skipping to change at line 203 skipping to change at line 248
<t>Key Stretching Function (KSF); <xref target="deps-hash"/></t> <t>Key Stretching Function (KSF); <xref target="deps-hash"/></t>
</li> </li>
</ul> </ul>
<t>This section describes these protocols and primitives in more detail. U nless said <t>This section describes these protocols and primitives in more detail. U nless said
otherwise, all random nonces and seeds used in these dependencies and the rest o f otherwise, all random nonces and seeds used in these dependencies and the rest o f
the OPAQUE protocol are of length <tt>Nn</tt> and <tt>Nseed</tt> bytes, respecti vely, where the OPAQUE protocol are of length <tt>Nn</tt> and <tt>Nseed</tt> bytes, respecti vely, where
<tt>Nn</tt> = <tt>Nseed</tt> = 32.</t> <tt>Nn</tt> = <tt>Nseed</tt> = 32.</t>
<section anchor="deps-oprf"> <section anchor="deps-oprf">
<name>Oblivious Pseudorandom Function</name> <name>Oblivious Pseudorandom Function</name>
<t>An Oblivious Pseudorandom Function (OPRF) is a two-party protocol bet ween <t>An Oblivious Pseudorandom Function (OPRF) is a two-party protocol bet ween
client and server for computing a PRF, where the PRF key is held by the server client and server for computing a Pseudorandom Function (PRF), where the PRF key is held by the server
and the input to the function is provided by the client. The client does not and the input to the function is provided by the client. The client does not
learn anything about the PRF other than the obtained output, and the server learn anything about the PRF other than the obtained output, and the server
learns nothing about the client's input or the function output. learns nothing about the client's input or the function output.
This specification depends on the prime-order OPRF construction specified This specification depends on the prime-order OPRF construction specified
as <tt>modeOPRF</tt> (<tt>0x00</tt>) from Section 3.1 of <xref target="RFC9497"/ >.</t> as <tt>modeOPRF</tt> (<tt>0x00</tt>) from <xref section="3.1" target="RFC9497"/> .</t>
<t>The following OPRF client APIs are used:</t> <t>The following OPRF client APIs are used:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>Blind(element):</dt><dd>Create and output (<tt>blind</tt>,
<t>Blind(element): Create and output (<tt>blind</tt>, <tt>blinded_el <tt>blinded_element</tt>), consisting of a blinded representation of
ement</tt>), consisting of a blinded input <tt>element</tt>, denoted <tt>blinded_element</tt>, along with
representation of input <tt>element</tt>, denoted <tt>blinded_element</tt>, alon a value to revert the blinding process, denoted <tt>blind</tt>. This
g with a value to revert is equivalent to the Blind function described in
the blinding process, denoted <tt>blind</tt>. This is equivalent to the Blind fu <xref section="3.3.1" target="RFC9497"/>.</dd>
nction <dt>Finalize(element, blind, evaluated_element):</dt><dd>Finalize the
described in Section 3.3.1 of <xref target="RFC9497"/>.</t> OPRF
</li> evaluation using input <tt>element</tt>, random inverter
<li> <tt>blind</tt>, and evaluation output <tt>evaluated_element</tt>,
<t>Finalize(element, blind, evaluated_element): Finalize the OPRF ev yielding output <tt>oprf_output</tt>. This is equivalent to the
aluation using input <tt>element</tt>, Finalize function described in <xref section="3.3.1"
random inverter <tt>blind</tt>, and evaluation output <tt>evaluated_element</tt> target="RFC9497"/>.</dd>
, yielding output <tt>oprf_output</tt>. </dl>
This is equivalent to the Finalize function described in Section 3.3.1 of <xref
target="RFC9497"/>.</t>
</li>
</ul>
<t>Moreover, the following OPRF server APIs are used:</t> <t>Moreover, the following OPRF server APIs are used:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>BlindEvaluate(k, blinded_element):</dt><dd>Evaluate blinded input
<t>BlindEvaluate(k, blinded_element): Evaluate blinded input <tt>bli <tt>blinded_element</tt> using input key <tt>k</tt>, yielding output
nded_element</tt> using element <tt>evaluated_element</tt>. This is equivalent to the
input key <tt>k</tt>, yielding output element <tt>evaluated_element</tt>. This i BlindEvaluate function described in <xref section="3.3.1"
s equivalent to target="RFC9497"/>, where <tt>k</tt> is the private key
the BlindEvaluate function described in Section 3.3.1 of <xref target="RFC9497"/ parameter.</dd>
>, where <tt>k</tt> is the private key parameter.</t> <dt>DeriveKeyPair(seed, info):</dt><dd>Create and output (<tt>sk</tt>,
</li> <tt>pk</tt>), consisting of a private and public key derived
<li> deterministically from an input <tt>seed</tt> and input
<t>DeriveKeyPair(seed, info): Create and output (<tt>sk</tt>, <tt>pk <tt>info</tt> parameter, as described in <xref section="3.2"
</tt>), consisting of a private and public key derived target="RFC9497"/>.</dd>
deterministically from an input <tt>seed</tt> and input <tt>info</tt> parameter, </dl>
as described in Section 3.2 of <xref target="RFC9497"/>.</t>
</li>
</ul>
<t>Finally, this specification makes use of the following shared APIs an d parameters:</t> <t>Finally, this specification makes use of the following shared APIs an d parameters:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>SerializeElement(element):</dt><dd>Map input <tt>element</tt> to a
<t>SerializeElement(element): Map input <tt>element</tt> to a fixed- fixed-length byte array.</dd>
length byte array.</t> <dt>DeserializeElement(buf):</dt><dd>Attempt to map input byte array
</li> <tt>buf</tt> to an OPRF group element. This function can raise a
<li> DeserializeError upon failure; see <xref section="2.1"
<t>DeserializeElement(buf): Attempt to map input byte array <tt>buf< target="RFC9497"/> for more details.</dd>
/tt> to an OPRF group element. <dt>Noe:</dt><dd>The size of a serialized OPRF group element output fr
This function can raise a DeserializeError upon failure; see Section 2.1 of <xre om SerializeElement.</dd>
f target="RFC9497"/> <dt>Nok:</dt><dd>The size of an OPRF private key as output from Derive
for more details.</t> KeyPair.</dd>
</li> </dl>
<li>
<t>Noe: The size of a serialized OPRF group element output from Seri
alizeElement.</t>
</li>
<li>
<t>Nok: The size of an OPRF private key as output from DeriveKeyPair
.</t>
</li>
</ul>
</section> </section>
<section anchor="deps-symmetric"> <section anchor="deps-symmetric">
<name>Key Derivation Function and Message Authentication Code</name> <name>Key Derivation Function and Message Authentication Code</name>
<t>A Key Derivation Function (KDF) is a function that takes some source of initial <t>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. keying material and uses it to derive one or more cryptographically strong keys.
This specification uses a KDF with the following API and parameters:</t> This specification uses a KDF with the following API and parameters:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>Extract(salt, ikm):</dt><dd>Extract a pseudorandom key of fixed le
<t>Extract(salt, ikm): Extract a pseudorandom key of fixed length <t ngth
t>Nx</tt> bytes from <tt>Nx</tt> bytes from input keying material <tt>ikm</tt> and an
input keying material <tt>ikm</tt> and an optional byte string <tt>salt</tt>.</t optional byte string <tt>salt</tt>.</dd>
> <dt>Expand(prk, info, L):</dt><dd>Expand a pseudorandom key <tt>prk</t
</li> t>,
<li> using the string <tt>info</tt>, into <tt>L</tt> bytes of output
<t>Expand(prk, info, L): Expand a pseudorandom key <tt>prk</tt>, usi keying material.</dd>
ng the string <tt>info</tt>, <dt>Nx:</dt><dd>The output size of the <tt>Extract()</tt> function in
into <tt>L</tt> bytes of output keying material.</t> bytes.</dd>
</li> </dl>
<li>
<t>Nx: The output size of the <tt>Extract()</tt> function in bytes.<
/t>
</li>
</ul>
<t>This specification also makes use of a random-key robust Message Auth entication Code <t>This specification also makes use of a random-key robust Message Auth entication Code
(MAC). See <xref target="rkr-mac"/> for more details on this property. The API a nd parameters for (MAC). See <xref target="rkr-mac"/> for more details on this property. The API a nd parameters for
the random-key robust MAC are as follows:</t> the random-key robust MAC are as follows:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>MAC(key, msg):</dt><dd>Compute a message authentication code
<t>MAC(key, msg): Compute a message authentication code over input < over input <tt>msg</tt> with key <tt>key</tt>, producing a
tt>msg</tt> with key fixed-length output of <tt>Nm</tt> bytes.</dd>
<tt>key</tt>, producing a fixed-length output of <tt>Nm</tt> bytes.</t> <dt>Nm:</dt><dd>The output size of the <tt>MAC()</tt> function in byte
</li> s.</dd>
<li> </dl>
<t>Nm: The output size of the <tt>MAC()</tt> function in bytes.</t>
</li>
</ul>
</section> </section>
<section anchor="deps-hash"> <section anchor="deps-hash">
<name>Hash Functions</name> <name>Hash Functions</name>
<t>This specification makes use of a collision-resistant hash function w ith the following <t>This specification makes use of a collision-resistant hash function w ith the following
API and parameters:</t> API and parameters:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>Hash(msg):</dt><dd>Apply a cryptographic hash function to input
<t>Hash(msg): Apply a cryptographic hash function to input <tt>msg</ <tt>msg</tt>, producing a fixed-length digest of size <tt>Nh</tt>
tt>, producing a bytes.</dd>
fixed-length digest of size <tt>Nh</tt> bytes.</t> <dt>Nh:</dt><dd>The output size of the <tt>Hash()</tt> function in byt
</li> es.</dd>
<li> </dl>
<t>Nh: The output size of the <tt>Hash()</tt> function in bytes.</t>
</li>
</ul>
<t>This specification makes use of a Key Stretching Function (KSF), whic h is a slow <t>This specification makes use of a Key Stretching Function (KSF), whic h is a slow
and expensive cryptographic hash function with the following API:</t> and expensive cryptographic hash function with the following API:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>Stretch(msg):</dt><dd>Apply a key stretching function to stretch
<t>Stretch(msg): Apply a key stretching function to stretch the inpu the input <tt>msg</tt> and harden it against offline dictionary
t <tt>msg</tt> and attacks. This function also needs to satisfy collision
harden it against offline dictionary attacks. This function also needs to resistance.</dd>
satisfy collision resistance.</t> </dl>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="protocol-overview"> <section anchor="protocol-overview">
<name>Protocol Overview</name> <name>Protocol Overview</name>
<t>OPAQUE consists of two stages: registration and authenticated key excha nge (AKE). <t>OPAQUE consists of two stages: registration and authenticated key excha nge (AKE).
In the first stage, a client registers its password with the server and stores In the first stage, a client registers its password with the server and stores
its credential file on the server. In the second stage (also called the its credential file on the server. In the second stage (also called the
"login" or "online" stage), the client recovers its authentication material and uses it to "login" or "online" stage), the client recovers its authentication material and uses it to
perform a mutually authenticated key exchange.</t> perform a mutually authenticated key exchange.</t>
<section anchor="setup"> <section anchor="setup">
<name>Setup</name> <name>Setup</name>
<t>Prior to both stages, the client and server agree on a configuration that <t>Prior to both stages, the client and server agree on a configuration that
fully specifies the cryptographic algorithm dependencies necessary to run the fully specifies the cryptographic algorithm dependencies necessary to run the
protocol; see <xref target="configurations"/> for details. protocol; see <xref target="configurations"/> for details.
The server chooses a pair of keys (<tt>server_private_key</tt> and <tt>server_pu blic_key</tt>) The server chooses a pair of keys (<tt>server_private_key</tt> and <tt>server_pu blic_key</tt>)
for the AKE, and chooses a seed (<tt>oprf_seed</tt>) of <tt>Nh</tt> bytes for th e OPRF. for the AKE and chooses a seed (<tt>oprf_seed</tt>) of <tt>Nh</tt> bytes for the OPRF.
The server can use <tt>server_private_key</tt> and <tt>server_public_key</tt> wi th multiple The server can use <tt>server_private_key</tt> and <tt>server_public_key</tt> wi th multiple
clients. The server can also opt to use a different seed for each client clients. The server can also opt to use a different seed for each client
(i.e. each client can be assigned a single seed), so long as they are maintained (i.e., each client can be assigned a single seed), so long as they are maintaine
across the registration and online AKE stages, and kept consistent for each d
across the registration and online AKE stages and kept consistent for each
client (since an inconsistent mapping of clients to seeds could leak information client (since an inconsistent mapping of clients to seeds could leak information
as described in <xref target="preventing-client-enumeration"/>).</t> as described in <xref target="preventing-client-enumeration"/>).</t>
</section> </section>
<section anchor="registration"> <section anchor="registration">
<name>Registration</name> <name>Registration</name>
<t>Registration is the only stage in OPAQUE that requires a server-authe nticated <t>Registration is the only stage in OPAQUE that requires a server-authe nticated
channel with confidentiality and integrity: either physical, out-of-band, PKI-ba sed, etc.</t> channel with confidentiality and integrity: either physical, out-of-band, PKI-ba sed, etc.</t>
<t>The client inputs its credentials, which include its password and use r <t>The client inputs its credentials, which include its password and use r
identifier, and the server inputs its parameters, which include its private key identifier, and the server inputs its parameters, which include its private key
and other information.</t> and other information.</t>
<t>The client output of this stage is a single value <tt>export_key</tt> that the client <t>The client output of this stage is a single value <tt>export_key</tt> that the client
may use for application-specific purposes, e.g., as a symmetric key used to encr ypt may use for application-specific purposes, e.g., as a symmetric key used to encr ypt
additional information for storage on the server. The server does not have acces s to this additional information for storage on the server. The server does not have acces s to this
<tt>export_key</tt>.</t> <tt>export_key</tt>.</t>
<t>The server output of this stage is a record corresponding to the clie nt's <t>The server output of this stage is a record corresponding to the clie nt's
registration that it stores in a credential file alongside other clients registration that it stores in a credential file alongside other clients
registrations as needed.</t> registrations as needed.</t>
<t>The registration flow is shown below, and the process is described in more detail in <t>The registration flow is shown in <xref target="fig1"/>, and the proc ess is described in more detail in
<xref target="registration-phase"/>:</t> <xref target="registration-phase"/>:</t>
<figure anchor="fig1">
<name></name>
<artwork><![CDATA[ <artwork><![CDATA[
credentials parameters credentials parameters
| | | |
v v v v
Client Server Client Server
------------------------------------------------ ------------------------------------------------
registration request registration request
-------------------------> ------------------------->
registration response registration response
<------------------------- <-------------------------
record record
-------------------------> ------------------------->
------------------------------------------------ ------------------------------------------------
| | | |
v v v v
export_key record export_key record
]]></artwork> ]]></artwork>
</figure>
<t>These messages are named <tt>RegistrationRequest</tt>, <tt>Registrati onResponse</tt>, and <t>These messages are named <tt>RegistrationRequest</tt>, <tt>Registrati onResponse</tt>, and
<tt>RegistrationRecord</tt>, respectively. Their contents and wire format are de fined in <tt>RegistrationRecord</tt>, respectively. Their contents and wire format are de fined in
<xref target="registration-messages"/>.</t> <xref target="registration-messages"/>.</t>
</section> </section>
<section anchor="online-authenticated-key-exchange"> <section anchor="online-authenticated-key-exchange">
<name>Online Authenticated Key Exchange</name> <name>Online Authenticated Key Exchange</name>
<t>In this second stage, a client obtains credentials previously registe red <t>In this second stage, a client obtains credentials previously registe red
with the server, recovers private key material using the password, and with the server, recovers private key material using the password, and
subsequently uses them as input to the AKE protocol. As in the registration subsequently uses them as input to the AKE protocol. As in the registration
phase, the client inputs its credentials, including its password and user phase, the client inputs its credentials, including its password and user
identifier, and the server inputs its parameters and the credential file record identifier, and the server inputs its parameters and the credential file record
corresponding to the client. The client outputs two values, an <tt>export_key</t t> corresponding to the client. The client outputs two values, an <tt>export_key</t t>
(matching that from registration) and a <tt>session_key</tt>, the latter of whic h (matching that from registration) and a <tt>session_key</tt>, the latter of whic h
is the primary AKE output. The server outputs a single value <tt>session_key</tt > is the primary AKE output. The server outputs a single value <tt>session_key</tt >
that matches that of the client. Upon completion, clients and servers can that matches that of the client. Upon completion, clients and servers can
use these values as needed.</t> use these values as needed.</t>
<t>The authenticated key exchange flow is shown below:</t> <t>The authenticated key exchange flow is shown in <xref target="fig2"/>
:</t>
<figure anchor="fig2">
<name></name>
<artwork><![CDATA[ <artwork><![CDATA[
credentials (parameters, record) credentials (parameters, record)
| | | |
v v v v
Client Server Client Server
------------------------------------------------ ------------------------------------------------
AKE message 1 AKE message 1
-------------------------> ------------------------->
AKE message 2 AKE message 2
<------------------------- <-------------------------
AKE message 3 AKE message 3
-------------------------> ------------------------->
------------------------------------------------ ------------------------------------------------
| | | |
v v v v
(export_key, session_key) session_key (export_key, session_key) session_key
]]></artwork> ]]></artwork>
</figure>
<t>These messages are named <tt>KE1</tt>, <tt>KE2</tt>, and <tt>KE3</tt> , respectively. They carry the <t>These messages are named <tt>KE1</tt>, <tt>KE2</tt>, and <tt>KE3</tt> , respectively. They carry the
messages of the concurrent execution of the key recovery process (OPRF) and the messages of the concurrent execution of the key recovery process (OPRF) and the
authenticated key exchange (AKE), and their corresponding wire formats are authenticated key exchange (AKE). Their corresponding wire formats are
specified in <xref target="ake-messages"/>.</t> specified in <xref target="ake-messages"/>.</t>
<t>The rest of this document describes the specifics of these stages in detail. <t>The rest of this document describes the specifics of these stages in detail.
<xref target="client-material"/> describes how client credential information is <xref target="client-material"/> describes how client credential information is
generated, encoded, and stored on the server during registration, and recovered during generated, encoded, and stored on the server during registration and recovered d uring
login. <xref target="registration-phase"/> describes the first registration stag e of the protocol, login. <xref target="registration-phase"/> describes the first registration stag e of the protocol,
and <xref target="online-phase"/> describes the second authentication stage of t he protocol. and <xref target="online-phase"/> describes the second authentication stage of t he protocol.
<xref target="configurations"/> describes how to instantiate OPAQUE using differ ent <xref target="configurations"/> describes how to instantiate OPAQUE using differ ent
cryptographic dependencies and parameters.</t> cryptographic dependencies and parameters.</t>
</section> </section>
</section> </section>
<section anchor="client-material"> <section anchor="client-material">
<name>Client Credential Storage and Key Recovery</name> <name>Client Credential Storage and Key Recovery</name>
<t>OPAQUE makes use of a structure called <tt>Envelope</tt> to manage clie nt credentials. <t>OPAQUE makes use of a structure called <tt>Envelope</tt> to manage clie nt credentials.
The client creates its <tt>Envelope</tt> on registration and sends it to the ser ver for The client creates its <tt>Envelope</tt> on registration and sends it to the ser ver for
storage. On every login, the server sends this <tt>Envelope</tt> to the client s o it can storage. On every login, the server sends this <tt>Envelope</tt> to the client s o it can
recover its key material for use in the AKE.</t> recover its key material for use in the AKE.</t>
<t>Applications may pin key material to identities if desired. If no ident ity is given <t>Applications may pin key material to identities if desired. If no ident ity is given
for a party, its value MUST default to its public key. The following types of for a party, its value <bcp14>MUST</bcp14> default to its public key. The follow ing types of
application credential information are considered:</t> application credential information are considered:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>client_private_key:</dt><dd>The encoded client private key for the A
<t>client_private_key: The encoded client private key for the AKE prot KE protocol.</dd>
ocol.</t> <dt>client_public_key:</dt><dd>The encoded client public key for the AKE
</li> protocol.</dd>
<li> <dt>server_public_key:</dt><dd>The encoded server public key for the AKE
<t>client_public_key: The encoded client public key for the AKE protoc protocol.</dd>
ol.</t> <dt>client_identity:</dt><dd>The client identity. This is an
</li> application-specific value, e.g., an email address or an account
<li> name. If not specified, it defaults to the client's public key.</dd>
<t>server_public_key: The encoded server public key for the AKE protoc <dt>server_identity:</dt><dd>The server identity. This is typically a do
ol.</t> main
</li> name, e.g., example.com. If not specified, it defaults to the
<li> server's public key. See <xref target="identities"/> for information
<t>client_identity: The client identity. This is an application-specif about this identity.</dd>
ic value, </dl>
e.g., an e-mail address or an account name. If not specified, it defaults
to the client's public key.</t>
</li>
<li>
<t>server_identity: The server identity. This is typically a domain na
me, e.g., example.com.
If not specified, it defaults to the server's public key. See <xref target="iden
tities"/> for
information about this identity.</t>
</li>
</ul>
<t>A subset of these credential values are used in the <tt>CleartextCreden tials</tt> structure as follows:</t> <t>A subset of these credential values are used in the <tt>CleartextCreden tials</tt> structure as follows:</t>
<artwork><![CDATA[
<sourcecode type=""><![CDATA[
struct { struct {
uint8 server_public_key[Npk]; uint8 server_public_key[Npk];
uint8 server_identity<1..2^16-1>; uint8 server_identity<1..2^16-1>;
uint8 client_identity<1..2^16-1>; uint8 client_identity<1..2^16-1>;
} CleartextCredentials; } CleartextCredentials;
]]></artwork> ]]></sourcecode>
<t>The function CreateCleartextCredentials constructs a <tt>CleartextCrede ntials</tt> structure given <t>The function CreateCleartextCredentials constructs a <tt>CleartextCrede ntials</tt> structure given
application credential information.</t> application credential information.</t>
<artwork><![CDATA[
<sourcecode type=""><![CDATA[
CreateCleartextCredentials CreateCleartextCredentials
Input: Input:
- server_public_key, the encoded server public key for the AKE protocol. - server_public_key, the encoded server public key for the AKE protocol.
- client_public_key, the encoded client public key 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.
skipping to change at line 477 skipping to change at line 510
if client_identity == nil if client_identity == nil
client_identity = client_public_key client_identity = client_public_key
cleartext_credentials = CleartextCredentials { cleartext_credentials = CleartextCredentials {
server_public_key, server_public_key,
server_identity, server_identity,
client_identity client_identity
} }
return cleartext_credentials return cleartext_credentials
]]></artwork> ]]></sourcecode>
<section anchor="key-recovery"> <section anchor="key-recovery">
<name>Key Recovery</name> <name>Key Recovery</name>
<t>This specification defines a key recovery mechanism that uses the str etched OPRF <t>This specification defines a key recovery mechanism that uses the str etched OPRF
output as a seed to directly derive the private and public keys using the output as a seed to directly derive the private and public keys using the
<tt>DeriveDiffieHellmanKeyPair()</tt> function defined in <xref target="key-crea tion"/>.</t> <tt>DeriveDiffieHellmanKeyPair()</tt> function defined in <xref target="key-crea tion"/>.</t>
<section anchor="envelope-structure"> <section anchor="envelope-structure">
<name>Envelope Structure</name> <name>Envelope Structure</name>
<t>The key recovery mechanism defines its <tt>Envelope</tt> as follows :</t> <t>The key recovery mechanism defines its <tt>Envelope</tt> as follows :</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
struct { struct {
uint8 envelope_nonce[Nn]; uint8 envelope_nonce[Nn];
uint8 auth_tag[Nm]; uint8 auth_tag[Nm];
} Envelope; } Envelope;
]]></artwork> ]]></sourcecode>
<t>envelope_nonce: A randomly-sampled nonce of length <tt>Nn</tt>, use <dl spacing="normal" newline="false">
d to protect this <tt>Envelope</tt>.</t> <dt>envelope_nonce:</dt><dd>A randomly sampled nonce of length
<t>auth_tag: An authentication tag protecting the contents of the enve <tt>Nn</tt> used to protect this <tt>Envelope</tt>.</dd>
lope, covering <dt>auth_tag:</dt><dd>An authentication tag protecting the
<tt>envelope_nonce</tt> and <tt>CleartextCredentials</tt>.</t> contents of the envelope, covering <tt>envelope_nonce</tt> and
<tt>CleartextCredentials</tt>.</dd>
</dl>
</section> </section>
<section anchor="envelope-creation"> <section anchor="envelope-creation">
<name>Envelope Creation</name> <name>Envelope Creation</name>
<t>Clients create an <tt>Envelope</tt> at registration with the functi on <tt>Store</tt> defined <t>Clients create an <tt>Envelope</tt> at registration with the functi on <tt>Store</tt> defined
below. Note that <tt>DeriveDiffieHellmanKeyPair</tt> in this function can fail w ith negligible below. Note that <tt>DeriveDiffieHellmanKeyPair</tt> in this function can fail w ith negligible
probability. If this occurs, servers should re-run the function, sampling a probability.
<!-- [rfced] In the following text, is the procedure of sampling a new
"envelope_nonce" separate from rerunning the function? Or are they the
same thing? We ask because the interrupting phrase ("sampling...") may
impede readability. May we update to one of the following options?
Current:
If this occurs, servers should re-run the function, sampling a new
envelope_nonce, to completion.
Perhaps:
If this occurs, servers should re-run the function (i.e., sample a
new envelope_nonce) to completion.
Or:
If this occurs, servers should re-run the function and sample a new
envelope_nonce to completion.
-->
If this occurs, servers should re-run the function, sampling a
new <tt>envelope_nonce</tt>, to completion.</t> new <tt>envelope_nonce</tt>, to completion.</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
Store Store
Input: Input:
- randomized_password, a randomized password. - randomized_password, a randomized password.
- server_public_key, the encoded server public key for - server_public_key, the encoded server public key for
the AKE protocol. 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:
skipping to change at line 553 skipping to change at line 608
I2OSP(len(cleartext_credentials.client_identity), 2), I2OSP(len(cleartext_credentials.client_identity), 2),
cleartext_credentials.client_identity cleartext_credentials.client_identity
)) ))
envelope = Envelope { envelope = Envelope {
envelope_nonce, envelope_nonce,
auth_tag auth_tag
} }
return (envelope, client_public_key, masking_key, export_key) return (envelope, client_public_key, masking_key, export_key)
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="envelope-recovery"> <section anchor="envelope-recovery">
<name>Envelope Recovery</name> <name>Envelope Recovery</name>
<t>Clients recover their <tt>Envelope</tt> during login with the <tt>R ecover</tt> function <t>Clients recover their <tt>Envelope</tt> during login with the <tt>R ecover</tt> function
defined below.</t> defined below.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
Recover Recover
Input: Input:
- randomized_password, a randomized password. - randomized_password, a randomized password.
- server_public_key, the encoded server public key for the - server_public_key, the encoded server public key for the
AKE protocol. AKE protocol.
- envelope, the client's Envelope structure. - envelope, the client's Envelope structure.
- 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.
skipping to change at line 601 skipping to change at line 656
DeriveDiffieHellmanKeyPair(seed) DeriveDiffieHellmanKeyPair(seed)
cleartext_credentials = cleartext_credentials =
CreateCleartextCredentials(server_public_key, client_public_key, CreateCleartextCredentials(server_public_key, client_public_key,
server_identity, client_identity) server_identity, client_identity)
expected_tag = expected_tag =
MAC(auth_key, concat(envelope.nonce, cleartext_credentials)) MAC(auth_key, concat(envelope.nonce, cleartext_credentials))
If !ct_equal(envelope.auth_tag, expected_tag) If !ct_equal(envelope.auth_tag, expected_tag)
raise EnvelopeRecoveryError raise EnvelopeRecoveryError
return (client_private_key, cleartext_credentials, export_key) return (client_private_key, cleartext_credentials, export_key)
]]></artwork> ]]></sourcecode>
<t>In the case of <tt>EnvelopeRecoveryError</tt> being raised, all pre <t>In the case of <tt>EnvelopeRecoveryError</tt> being raised, all pre
viously-computed viously computed
intermediary values in this function MUST be deleted.</t> intermediary values in this function <bcp14>MUST</bcp14> be deleted.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="registration-phase"> <section anchor="registration-phase">
<name>Registration</name> <name>Registration</name>
<t>The registration process proceeds as follows. The client inputs <t>The registration process proceeds as follows. The client inputs
the following values:</t> the following values:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>password:</dt><dd>The client's password.</dd>
<t>password: The client's password.</t> <dt>creds:</dt><dd>The client credentials as described in <xref
</li> target="client-material"/>.</dd>
<li> </dl>
<t>creds: The client credentials, as described in <xref target="client
-material"/>.</t>
</li>
</ul>
<t>The server inputs the following values:</t> <t>The server inputs the following values:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>server_public_key:</dt><dd>The server public key for the AKE protoco
<t>server_public_key: The server public key for the AKE protocol.</t> l.</dd>
</li> <dt>credential_identifier:</dt><dd>A unique identifier for the client's
<li> credential generated by the server.</dd>
<t>credential_identifier: A unique identifier for the client's <dt>client_identity:</dt><dd>The optional client identity as described i
credential, generated by the server.</t> n <xref target="client-material"/>.</dd>
</li> <dt>oprf_seed:</dt><dd>A seed used to derive per-client OPRF keys.</dd>
<li> </dl>
<t>client_identity: The optional client identity as described in <xref
target="client-material"/>.</t>
</li>
<li>
<t>oprf_seed: A seed used to derive per-client OPRF keys.</t>
</li>
</ul>
<t>The registration protocol then runs as shown below:</t> <t>The registration protocol then runs as shown below:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Client Server Client Server
------------------------------------------------------ ------------------------------------------------------
(request, blind) = CreateRegistrationRequest(password) (request, blind) = CreateRegistrationRequest(password)
request request
-------------------------> ------------------------->
response = CreateRegistrationResponse(request, response = CreateRegistrationResponse(request,
skipping to change at line 668 skipping to change at line 712
record record
-------------------------> ------------------------->
]]></artwork> ]]></artwork>
<t><xref target="registration-messages"/> describes the formats for the ab ove messages, and <t><xref target="registration-messages"/> describes the formats for the ab ove messages, and
<xref target="registration-functions"/> describes details of the functions and t he <xref target="registration-functions"/> describes details of the functions and t he
corresponding parameters referenced above.</t> corresponding parameters referenced above.</t>
<t>At the end of this interaction, the server stores the <tt>record</tt> o bject as the <t>At the end of this interaction, the server stores the <tt>record</tt> o bject as the
credential file for each client along with the associated <tt>credential_identif ier</tt> credential file for each client along with the associated <tt>credential_identif ier</tt>
and <tt>client_identity</tt> (if different). Note that the values <tt>oprf_seed< /tt> and and <tt>client_identity</tt> (if different). Note that the values <tt>oprf_seed< /tt> and
<tt>server_private_key</tt> from the server's setup phase must also be persisted . <tt>server_private_key</tt> from the server's setup phase must also be persisted .
The <tt>oprf_seed</tt> value SHOULD be used for all clients; see <xref target="p reventing-client-enumeration"/> The <tt>oprf_seed</tt> value <bcp14>SHOULD</bcp14> be used for all clients; see <xref target="preventing-client-enumeration"/>
for the justification behind this, along with a description of the exception in which for the justification behind this, along with a description of the exception in which
applications may choose to avoid the use of a global <tt>oprf_seed</tt> value ac ross clients applications may choose to avoid the use of a global <tt>oprf_seed</tt> value ac ross clients
and instead sample OPRF keys uniquely for each client. The <tt>server_private_ke y</tt> may and instead sample OPRF keys uniquely for each client. The <tt>server_private_ke y</tt> may
be unique for each client.</t> be unique for each client.</t>
<t>Both client and server MUST validate the other party's public key befor e use. <t>Both client and server <bcp14>MUST</bcp14> validate the other party's p ublic key before use.
See <xref target="validation"/> for more details. Upon completion, the server st ores See <xref target="validation"/> for more details. Upon completion, the server st ores
the client's credentials for later use. Moreover, the client MAY use the output the client's credentials for later use. Moreover, the client <bcp14>MAY</bcp14> use the output
<tt>export_key</tt> for further application-specific purposes; see <xref target= "export-key-usage"/>.</t> <tt>export_key</tt> for further application-specific purposes; see <xref target= "export-key-usage"/>.</t>
<section anchor="registration-messages"> <section anchor="registration-messages">
<name>Registration Messages</name> <name>Registration Messages</name>
<t>This section contains definitions of the <tt>RegistrationRequest</tt> , <t>This section contains definitions of the <tt>RegistrationRequest</tt> ,
<tt>RegistrationResponse</tt>, and <tt>RegistrationRecord</tt> messages exchange d between <tt>RegistrationResponse</tt>, and <tt>RegistrationRecord</tt> messages exchange d between
client and server during registration.</t> client and server during registration.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
struct { struct {
uint8 blinded_message[Noe]; uint8 blinded_message[Noe];
} RegistrationRequest; } RegistrationRequest;
]]></artwork> ]]></sourcecode>
<t>blinded_message: A serialized OPRF group element.</t> <dl spacing="normal" newline="false">
<artwork><![CDATA[ <dt>blinded_message:</dt><dd>A serialized OPRF group element.</dd>
</dl>
<sourcecode type=""><![CDATA[
struct { struct {
uint8 evaluated_message[Noe]; uint8 evaluated_message[Noe];
uint8 server_public_key[Npk]; uint8 server_public_key[Npk];
} RegistrationResponse; } RegistrationResponse;
]]></artwork> ]]></sourcecode>
<t>evaluated_message: A serialized OPRF group element.</t> <dl spacing="normal" newline="false">
<t>server_public_key: The server's encoded public key that will be used <dt>evaluated_message:</dt><dd>A serialized OPRF group element.</dd>
for <dt>server_public_key:</dt><dd>The server's encoded public key that wi
the online AKE stage.</t> ll be
<artwork><![CDATA[ used for the online AKE stage.</dd>
</dl>
<sourcecode type=""><![CDATA[
struct { struct {
uint8 client_public_key[Npk]; uint8 client_public_key[Npk];
uint8 masking_key[Nh]; uint8 masking_key[Nh];
Envelope envelope; Envelope envelope;
} RegistrationRecord; } RegistrationRecord;
]]></artwork> ]]></sourcecode>
<t>client_public_key: The client's encoded public key, corresponding to <dl spacing="normal" newline="false">
the private key <tt>client_private_key</tt>.</t> <dt>client_public_key:</dt><dd>The client's encoded public key
<t>masking_key: An encryption key used by the server with the sole purpo corresponding to the private key <tt>client_private_key</tt>.</dd>
se <dt>masking_key:</dt><dd>An encryption key used by the server with
of defending against client enumeration attacks.</t> the sole purpose of defending against client enumeration
<t>envelope: The client's <tt>Envelope</tt> structure.</t> attacks.</dd>
<dt>envelope:</dt><dd>The client's <tt>Envelope</tt> structure.</dd>
</dl>
</section> </section>
<section anchor="registration-functions"> <section anchor="registration-functions">
<name>Registration Functions</name> <name>Registration Functions</name>
<t>This section contains definitions of the functions used by client and server <t>This section contains definitions of the functions used by client and server
during registration, including <tt>CreateRegistrationRequest</tt>, <tt>CreateReg istrationResponse</tt>, during registration, including <tt>CreateRegistrationRequest</tt>, <tt>CreateReg istrationResponse</tt>,
and <tt>FinalizeRegistrationRequest</tt>.</t> and <tt>FinalizeRegistrationRequest</tt>.</t>
<section anchor="createregistrationrequest"> <section anchor="createregistrationrequest">
<name>CreateRegistrationRequest</name> <name>CreateRegistrationRequest</name>
<t>To begin the registration flow, the client executes the following f unction. This function <t>To begin the registration flow, the client executes the following f unction. This function
can fail with an <tt>InvalidInputError</tt> error with negligible probability. A different input can fail with an <tt>InvalidInputError</tt> error with negligible probability. A different input
password is necessary in the event of this error.</t> password is necessary in the event of this error.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
CreateRegistrationRequest CreateRegistrationRequest
Input: Input:
- password, an opaque byte string containing the client's password. - password, an opaque byte string containing the client's password.
Output: Output:
- request, a RegistrationRequest structure. - request, a RegistrationRequest structure.
- blind, an OPRF scalar value. - blind, an OPRF scalar value.
Exceptions: Exceptions:
- InvalidInputError, when Blind fails - InvalidInputError, when Blind fails
def CreateRegistrationRequest(password): def CreateRegistrationRequest(password):
(blind, blinded_element) = Blind(password) (blind, blinded_element) = Blind(password)
blinded_message = SerializeElement(blinded_element) blinded_message = SerializeElement(blinded_element)
request = RegistrationRequest { request = RegistrationRequest {
blinded_message blinded_message
} }
return (request, blind) return (request, blind)
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="create-reg-response"> <section anchor="create-reg-response">
<name>CreateRegistrationResponse</name> <name>CreateRegistrationResponse</name>
<t>To process the client's registration request, the server executes <t>To process the client's registration request, the server executes
the following function. This function can fail with a <tt>DeriveKeyPairError</tt > the following function. This function can fail with a <tt>DeriveKeyPairError</tt >
error with negligible probability. In this case, applications can error with negligible probability. In this case, applications can
choose a new <tt>credential_identifier</tt> for this registration record choose a new <tt>credential_identifier</tt> for this registration record
and re-run this function.</t> and rerun this function.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
CreateRegistrationResponse CreateRegistrationResponse
Input: Input:
- request, a RegistrationRequest structure. - request, a RegistrationRequest structure.
- server_public_key, the server's public key. - server_public_key, the server's public key.
- credential_identifier, an identifier that uniquely represents - credential_identifier, an identifier that uniquely represents
the credential. the credential.
- oprf_seed, the seed of Nh bytes used by the server to generate - oprf_seed, the seed of Nh bytes used by the server to generate
an oprf_key. an oprf_key.
skipping to change at line 783 skipping to change at line 834
blinded_element = DeserializeElement(request.blinded_message) blinded_element = DeserializeElement(request.blinded_message)
evaluated_element = BlindEvaluate(oprf_key, blinded_element) evaluated_element = BlindEvaluate(oprf_key, blinded_element)
evaluated_message = SerializeElement(evaluated_element) evaluated_message = SerializeElement(evaluated_element)
response = RegistrationResponse { response = RegistrationResponse {
evaluated_message, evaluated_message,
server_public_key server_public_key
} }
return response return response
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="finalize-request"> <section anchor="finalize-request">
<name>FinalizeRegistrationRequest</name> <name>FinalizeRegistrationRequest</name>
<t>To create the user record used for subsequent authentication and co mplete the <t>To create the user record used for subsequent authentication and co mplete the
registration flow, the client executes the following function.</t> registration flow, the client executes the following function.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
FinalizeRegistrationRequest FinalizeRegistrationRequest
Input: Input:
- password, an opaque byte string containing the client's password. - password, an opaque byte string containing the client's password.
- blind, an OPRF scalar value. - blind, an OPRF scalar value.
- response, a RegistrationResponse structure. - response, a RegistrationResponse structure.
- 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:
skipping to change at line 826 skipping to change at line 877
Store(randomized_password, response.server_public_key, Store(randomized_password, response.server_public_key,
server_identity, client_identity) server_identity, client_identity)
record = RegistrationRecord { record = RegistrationRecord {
client_public_key, client_public_key,
masking_key, masking_key,
envelope envelope
} }
return (record, export_key) return (record, export_key)
]]></artwork> ]]></sourcecode>
<t>See <xref target="online-phase"/> for details about the output <tt> export_key</tt> usage.</t> <t>See <xref target="online-phase"/> for details about the output <tt> export_key</tt> usage.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="online-phase"> <section anchor="online-phase">
<name>Online Authenticated Key Exchange</name> <name>Online Authenticated Key Exchange</name>
<t>The generic outline of OPAQUE with a 3-message AKE protocol includes th <!-- [rfced] We have split the following text into multiple sentences to
ree messages: prevent a run-on sentence. Please let us know any objections.
<tt>KE1</tt>, <tt>KE2</tt>, and <tt>KE3</tt>, where <tt>KE1</tt> and <tt>KE2</tt
> include key exchange shares, e.g., DH values, sent Original:
by the client and server, respectively, and <tt>KE3</tt> provides explicit clien The generic outline of OPAQUE with a 3-message AKE protocol includes
t authentication and three messages: KE1, KE2, and KE3, where KE1 and KE2 include key
full forward security (without it, forward secrecy is only achieved against eave exchange shares, e.g., DH values, sent by the client and server,
sdroppers, respectively, and KE3 provides explicit client authentication and
which is insufficient for OPAQUE security).</t> full forward security (without it, forward secrecy is only achieved
against eavesdroppers, which is insufficient for OPAQUE security).
Current:
The generic outline of OPAQUE with a 3-message AKE protocol includes
three messages: KE1, KE2, and KE3. KE1 and KE2 include key
exchange shares (e.g., DH values) sent by the client and server,
respectively. KE3 provides explicit client authentication and
full forward security (without it, forward secrecy is only achieved
against eavesdroppers, which is insufficient for OPAQUE security).
-->
<t>The generic outline of OPAQUE with a 3-message AKE protocol includes three
messages: <tt>KE1</tt>, <tt>KE2</tt>, and <tt>KE3</tt>. <tt>KE1</tt> and <tt>KE2
</tt> include key exchange shares (e.g., DH
values) sent by the client and server, respectively. <tt>KE3</tt> provides expli
cit
client authentication and full forward security (without it, forward secrecy
is only achieved against eavesdroppers, which is insufficient for OPAQUE
security).</t>
<t>This section describes the online authenticated key exchange protocol f low, <t>This section describes the online authenticated key exchange protocol f low,
message encoding, and helper functions. This stage is composed of a concurrent message encoding, and helper functions. This stage is composed of a concurrent
OPRF and key exchange flow. The key exchange protocol is authenticated using the OPRF and key exchange flow. The key exchange protocol is authenticated using the
client and server credentials established during registration; see <xref target= "registration-phase"/>. client and server credentials established during registration; see <xref target= "registration-phase"/>.
In the end, the client proves its knowledge of the password, and both client and In the end, the client proves its knowledge of the password, and both client and
server agree on (1) a mutually authenticated shared secret key and (2) any optio nal server agree on (1) a mutually authenticated shared secret key and (2) any optio nal
application information exchange during the handshake.</t> application information exchange during the handshake.</t>
<t>In this stage, the client inputs the following values:</t> <t>In this stage, the client inputs the following values:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>password:</dt><dd>The client's password.</dd>
<t>password: The client's password.</t> <dt>client_identity:</dt><dd>The client identity as described in <xref t
</li> arget="client-material"/>.</dd>
<li> </dl>
<t>client_identity: The client identity, as described in <xref target=
"client-material"/>.</t>
</li>
</ul>
<t>The server inputs the following values:</t> <t>The server inputs the following values:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>server_private_key:</dt><dd>The server's private key for the AKE pro
<t>server_private_key: The server's private key for the AKE protocol.< tocol.</dd>
/t> <dt>server_public_key:</dt><dd>The server's public key for the AKE proto
</li> col.</dd>
<li> <dt>server_identity:</dt><dd>The server identity as described in <xref t
<t>server_public_key: The server's public key for the AKE protocol.</t arget="client-material"/>.</dd>
> <dt>record:</dt><dd>The <tt>RegistrationRecord</tt> object corresponding
</li> to the client's registration.</dd>
<li> <dt>credential_identifier:</dt><dd>An identifier that uniquely represent
<t>server_identity: The server identity, as described in <xref target= s the credential.</dd>
"client-material"/>.</t> <dt>oprf_seed:</dt><dd>The seed used to derive per-client OPRF keys.</dd
</li> >
<li> </dl>
<t>record: The <tt>RegistrationRecord</tt> object corresponding to the
client's registration.</t>
</li>
<li>
<t>credential_identifier: An identifier that uniquely represents the c
redential.</t>
</li>
<li>
<t>oprf_seed: The seed used to derive per-client OPRF keys.</t>
</li>
</ul>
<t>The client receives two outputs: a session secret and an export key. Th e export <t>The client receives two outputs: a session secret and an export key. Th e export
key is only available to the client and may be used for additional key is only available to the client and may be used for additional
application-specific purposes, as outlined in <xref target="export-key-usage"/>. application-specific purposes, as outlined in <xref target="export-key-usage"/>.
Clients MUST NOT use the output <tt>export_key</tt> before Clients <bcp14>MUST NOT</bcp14> use the output <tt>export_key</tt> before
authenticating the peer in the authenticated key exchange protocol. authenticating the peer in the authenticated key exchange protocol.
See <xref target="alternate-key-recovery"/> for more details about this See <xref target="alternate-key-recovery"/> for more details about this
requirement. The server receives a single output: a session secret matching the requirement. The server receives a single output: a session secret matching the
client's.</t> client's.</t>
<t>The protocol runs as shown below:</t> <t>The protocol runs as shown below:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Client Server Client Server
------------------------------------------------------ ------------------------------------------------------
ke1 = GenerateKE1(password) ke1 = GenerateKE1(password)
skipping to change at line 910 skipping to change at line 965
session_key, session_key,
export_key) = GenerateKE3(client_identity, export_key) = GenerateKE3(client_identity,
server_identity, ke2) server_identity, ke2)
ke3 ke3
-------------------------> ------------------------->
session_key = ServerFinish(ke3) session_key = ServerFinish(ke3)
]]></artwork> ]]></artwork>
<t>Both client and server may use implicit internal state objects to keep necessary <t>Both client and server may use implicit internal state objects to keep necessary
material for the OPRF and AKE, <tt>client_state</tt> and <tt>server_state</tt>, respectively.</t> material for the OPRF and AKE, <tt>client_state</tt>, and <tt>server_state</tt>, respectively.</t>
<t>The client state <tt>ClientState</tt> may have the following fields:</t > <t>The client state <tt>ClientState</tt> may have the following fields:</t >
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>password:</dt><dd>The client's password.</dd>
<t>password: The client's password.</t> <dt>blind:</dt><dd>The random blinding inverter returned by <tt>Blind()<
</li> /tt>.</dd>
<li> <dt>client_ake_state:</dt><dd>The <tt>ClientAkeState</tt> as defined in
<t>blind: The random blinding inverter returned by <tt>Blind()</tt>.</ <xref target="protocol-3dh"/>.</dd>
t> </dl>
</li>
<li>
<t>client_ake_state: The <tt>ClientAkeState</tt> defined in <xref targ
et="protocol-3dh"/>.</t>
</li>
</ul>
<t>The server state <tt>ServerState</tt> may have the following fields:</t > <t>The server state <tt>ServerState</tt> may have the following fields:</t >
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>server_ake_state:</dt><dd>The <tt>ServerAkeState</tt> as defined in
<t>server_ake_state: The <tt>ServerAkeState</tt> defined in <xref targ <xref target="protocol-3dh"/>.</dd>
et="protocol-3dh"/>.</t> </dl>
</li>
</ul>
<t>Both of these states are ephemeral and should be erased after the proto col completes.</t> <t>Both of these states are ephemeral and should be erased after the proto col completes.</t>
<t>The rest of this section describes these authenticated key exchange mes sages <t>The rest of this section describes these authenticated key exchange mes sages
and their parameters in more detail. <xref target="ake-messages"/> defines the s tructure of the and their parameters in more detail. <xref target="ake-messages"/> defines the s tructure of the
messages passed between client and server in the above setup. <xref target="ake- functions"/> messages passed between client and server in the above setup. <xref target="ake- functions"/>
describes details of the functions and corresponding parameters mentioned above. describes details of the functions and corresponding parameters mentioned above.
<xref target="cred-retrieval"/> discusses internal functions used for retrieving client <xref target="cred-retrieval"/> discusses internal functions used for retrieving client
credentials, and <xref target="protocol-3dh"/> discusses how these functions are used to execute credentials, and <xref target="protocol-3dh"/> discusses how these functions are used to execute
the authenticated key exchange protocol.</t> the authenticated key exchange protocol.</t>
<section anchor="ake-messages"> <section anchor="ake-messages">
<name>AKE Messages</name> <name>AKE Messages</name>
<t>In this section, we define the <tt>KE1</tt>, <tt>KE2</tt>, and <tt>KE 3</tt> structs that make up <t>In this section, we define the <tt>KE1</tt>, <tt>KE2</tt>, and <tt>KE 3</tt> structs that make up
the AKE messages used in the protocol. <tt>KE1</tt> is composed of a <tt>Credent ialRequest</tt> the AKE messages used in the protocol. <tt>KE1</tt> is composed of a <tt>Credent ialRequest</tt>
and <tt>AuthRequest</tt>, and <tt>KE2</tt> is composed of a <tt>CredentialRespon se</tt> and <tt>AuthRequest</tt>, and <tt>KE2</tt> is composed of a <tt>CredentialRespon se</tt>
and <tt>AuthResponse</tt>.</t> and <tt>AuthResponse</tt>.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
struct { struct {
uint8 client_nonce[Nn]; uint8 client_nonce[Nn];
uint8 client_public_keyshare[Npk]; uint8 client_public_keyshare[Npk];
} AuthRequest; } AuthRequest;
]]></artwork> ]]></sourcecode>
<t>client_nonce: A fresh randomly generated nonce of length <tt>Nn</tt>. <dl spacing="normal" newline="false">
</t> <dt>client_nonce:</dt><dd>A fresh randomly generated nonce of length <
<t>client_public_keyshare: A serialized client ephemeral public key of f tt>Nn</tt>.</dd>
ixed size <tt>Npk</tt>.</t> <dt>client_public_keyshare:</dt><dd>A serialized client ephemeral publ
<artwork><![CDATA[ ic key of fixed size <tt>Npk</tt>.</dd>
</dl>
<sourcecode type=""><![CDATA[
struct { struct {
CredentialRequest credential_request; CredentialRequest credential_request;
AuthRequest auth_request; AuthRequest auth_request;
} KE1; } KE1;
]]></artwork> ]]></sourcecode>
<t>credential_request: A <tt>CredentialRequest</tt> structure.</t> <dl spacing="normal" newline="false">
<t>auth_request: An <tt>AuthRequest</tt> structure.</t> <dt>credential_request:</dt><dd>A <tt>CredentialRequest</tt> structure
<artwork><![CDATA[ .</dd>
<dt>auth_request:</dt><dd>An <tt>AuthRequest</tt> structure.</dd>
</dl>
<sourcecode type=""><![CDATA[
struct { struct {
uint8 server_nonce[Nn]; uint8 server_nonce[Nn];
uint8 server_public_keyshare[Npk]; uint8 server_public_keyshare[Npk];
uint8 server_mac[Nm]; uint8 server_mac[Nm];
} AuthResponse; } AuthResponse;
]]></artwork> ]]></sourcecode>
<t>server_nonce: A fresh randomly generated nonce of length <tt>Nn</tt>. <dl spacing="normal" newline="false">
</t> <dt>server_nonce:</dt><dd>A fresh randomly generated nonce of length <
<t>server_public_keyshare: A server ephemeral public key of fixed size < tt>Nn</tt>.</dd>
tt>Npk</tt>, where <tt>Npk</tt> <dt>server_public_keyshare:</dt><dd>A server ephemeral public key of
depends on the corresponding prime order group.</t> fixed size <tt>Npk</tt>, where <tt>Npk</tt> depends on the
<t>server_mac: An authentication tag computed over the handshake transcr corresponding prime order group.</dd>
ipt <dt>server_mac:</dt><dd>An authentication tag computed over the
computed using <tt>Km2</tt>, defined below.</t> handshake transcript computed using <tt>Km2</tt>, which is defined
<artwork><![CDATA[ below.</dd>
</dl>
<sourcecode type=""><![CDATA[
struct { struct {
CredentialResponse credential_response; CredentialResponse credential_response;
AuthResponse auth_response; AuthResponse auth_response;
} KE2; } KE2;
]]></artwork> ]]></sourcecode>
<t>credential_response: A <tt>CredentialResponse</tt> structure.</t> <dl spacing="normal" newline="false">
<t>auth_response: An <tt>AuthResponse</tt> structure.</t> <dt>credential_response:</dt><dd>A <tt>CredentialResponse</tt> structu
<artwork><![CDATA[ re.</dd>
<dt>auth_response:</dt><dd>An <tt>AuthResponse</tt> structure.</dd>
</dl>
<sourcecode type=""><![CDATA[
struct { struct {
uint8 client_mac[Nm]; uint8 client_mac[Nm];
} KE3; } KE3;
]]></artwork> ]]></sourcecode>
<t>client_mac: An authentication tag computed over the handshake transcr <dl spacing="normal" newline="false">
ipt <!-- [rfced] For clarity, may we update the definition of "client_mac"?
of fixed size <tt>Nm</tt>, computed using <tt>Km2</tt>, defined below.</t>
Original:
client_mac: An authentication tag computed over the handshake
transcript of fixed size Nm, computed using Km2, defined below.
Perhaps:
client_mac: An authentication tag computed over the handshake
transcript of fixed size Nm, which is then computed using Km2
defined below.
-->
<dt>client_mac:</dt><dd>An authentication tag computed over the
handshake transcript of fixed size <tt>Nm</tt>, computed using
<tt>Km2</tt>, defined below.</dd>
</dl>
</section> </section>
<section anchor="ake-functions"> <section anchor="ake-functions">
<name>AKE Functions</name> <name>AKE Functions</name>
<t>In this section, we define the main functions used to produce the AKE messages <t>In this section, we define the main functions used to produce the AKE messages
in the protocol. Note that this section relies on definitions of subroutines def ined in the protocol. Note that this section relies on definitions of subroutines def ined
in later sections:</t> in later sections:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><tt>CreateCredentialRequest</tt>, <tt>CreateCredentialResponse</t <t><tt>CreateCredentialRequest</tt>, <tt>CreateCredentialResponse</t
t>, <tt>RecoverCredentials</tt> t>, and <tt>RecoverCredentials</tt> are defined in <xref target="cred-retrieval"
defined in <xref target="cred-retrieval"/></t> />.</t>
</li> </li>
<li> <li>
<t><tt>AuthClientStart</tt>, <tt>AuthServerRespond</tt>, <tt>AuthCli <t><tt>AuthClientStart</tt>, <tt>AuthServerRespond</tt>, <tt>AuthCli
entFinalize</tt>, and <tt>AuthServerFinalize</tt> entFinalize</tt>, and <tt>AuthServerFinalize</tt> are
defined in <xref target="ake-client"/> and <xref target="ake-server"/></t> defined in Sections <xref format="counter" target="ake-client"/> and <xref forma
t="counter" target="ake-server"/>.</t>
</li> </li>
</ul> </ul>
<section anchor="generateke1"> <section anchor="generateke1">
<name>GenerateKE1</name> <name>GenerateKE1</name>
<t>The <tt>GenerateKE1</tt> function begins the AKE protocol and produ ces the client's <tt>KE1</tt> <t>The <tt>GenerateKE1</tt> function begins the AKE protocol and produ ces the client's <tt>KE1</tt>
output for the server.</t> output for the server.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
GenerateKE1 GenerateKE1
State: State:
- state, a ClientState structure. - state, a ClientState structure.
Input: Input:
- password, an opaque byte string containing the client's password. - password, an opaque byte string containing the client's password.
Output: Output:
- ke1, a KE1 message structure. - ke1, a KE1 message structure.
def GenerateKE1(password): def GenerateKE1(password):
request, blind = CreateCredentialRequest(password) request, blind = CreateCredentialRequest(password)
state.password = password state.password = password
state.blind = blind state.blind = blind
ke1 = AuthClientStart(request) ke1 = AuthClientStart(request)
return ke1 return ke1
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="generateke2"> <section anchor="generateke2">
<name>GenerateKE2</name> <name>GenerateKE2</name>
<t>The <tt>GenerateKE2</tt> function continues the AKE protocol by pro cessing the client's <tt>KE1</tt> message <t>The <tt>GenerateKE2</tt> function continues the AKE protocol by pro cessing the client's <tt>KE1</tt> message
and producing the server's <tt>KE2</tt> output.</t> and producing the server's <tt>KE2</tt> output.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
GenerateKE2 GenerateKE2
State: State:
- state, a ServerState structure. - state, a ServerState structure.
Input: Input:
- server_identity, the optional encoded server identity, which is - server_identity, the optional encoded server identity, which is
set to server_public_key if not specified. set to server_public_key if not specified.
- server_private_key, the server's private key. - server_private_key, the server's private key.
- server_public_key, the server's public key. - server_public_key, the server's public key.
skipping to change at line 1075 skipping to change at line 1145
AuthServerRespond(cleartext_credentials, server_private_key, AuthServerRespond(cleartext_credentials, server_private_key,
record.client_public_key, ke1, record.client_public_key, ke1,
credential_response) credential_response)
ke2 = KE2 { ke2 = KE2 {
credential_response, credential_response,
auth_response auth_response
} }
return ke2 return ke2
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="generateke3"> <section anchor="generateke3">
<name>GenerateKE3</name> <name>GenerateKE3</name>
<t>The <tt>GenerateKE3</tt> function completes the AKE protocol for th e client and <t>The <tt>GenerateKE3</tt> function completes the AKE protocol for th e client and
produces the client's <tt>KE3</tt> output for the server, as well as the <tt>ses sion_key</tt> produces the client's <tt>KE3</tt> output for the server, as well as the <tt>ses sion_key</tt>
and <tt>export_key</tt> outputs from the AKE.</t> and <tt>export_key</tt> outputs from the AKE.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
GenerateKE3 GenerateKE3
State: State:
- state, a ClientState structure. - state, a ClientState structure.
Input: Input:
- 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.
- server_identity, the optional encoded server identity, which is - server_identity, the optional encoded server identity, which is
set to server_public_key if not specified. set to server_public_key if not specified.
skipping to change at line 1108 skipping to change at line 1178
- 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)
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="serverfinish"> <section anchor="serverfinish">
<name>ServerFinish</name> <name>ServerFinish</name>
<t>The <tt>ServerFinish</tt> function completes the AKE protocol for t he server, yielding the <tt>session_key</tt>. <t>The <tt>ServerFinish</tt> function completes the AKE protocol for t he server, yielding the <tt>session_key</tt>.
Since the OPRF is a two-message protocol, <tt>KE3</tt> has no element of the OPR <!-- [rfced] May we rephrase the following text to avoid interrupting the
F, and it, therefore, flow of the sentence?
Current:
Since the OPRF is a two-message protocol,
KE3 has no element of the OPRF, and it, therefore, invokes the AKE's
AuthServerFinalize directly.
Perhaps:
Since the OPRF is a two-message protocol,
KE3 has no element of the OPRF. Therefore, KE3 invokes the AKE's
AuthServerFinalize directly.
-->
Since the OPRF is a two-message protocol, <tt>KE3</tt> has no element of the OPR
F and it, therefore,
invokes the AKE's <tt>AuthServerFinalize</tt> directly. The <tt>AuthServerFinali ze</tt> function invokes the AKE's <tt>AuthServerFinalize</tt> directly. The <tt>AuthServerFinali ze</tt> function
takes <tt>KE3</tt> as input and MUST verify the client authentication material i t contains takes <tt>KE3</tt> as input and <bcp14>MUST</bcp14> verify the client authentica tion material it contains
before the <tt>session_key</tt> value can be used. This verification is necessar y to ensure before the <tt>session_key</tt> value can be used. This verification is necessar y to ensure
forward secrecy against active attackers.</t> forward secrecy against active attackers.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
ServerFinish ServerFinish
State: State:
- state, a ServerState structure. - state, a ServerState structure.
Input: Input:
- ke3, a KE3 structure. - ke3, a KE3 structure.
Output: Output:
- session_key, the shared session secret if and only if ke3 is valid. - session_key, the shared session secret if and only if ke3 is valid.
def ServerFinish(ke3): def ServerFinish(ke3):
return AuthServerFinalize(ke3) return AuthServerFinalize(ke3)
]]></artwork> ]]></sourcecode>
<t>This function MUST NOT return the <tt>session_key</tt> value if the <t>This function <bcp14>MUST NOT</bcp14> return the <tt>session_key</t
client authentication t> value if the client authentication
material is invalid, and may instead return an appropriate error message such as material is invalid and may instead return an appropriate error message, such as
<tt>ClientAuthenticationError</tt>, invoked from <tt>AuthServerFinalize</tt>.</t <tt>ClientAuthenticationError</tt>, which is invoked from <tt>AuthServerFinalize
> </tt>.</t>
</section> </section>
</section> </section>
<section anchor="cred-retrieval"> <section anchor="cred-retrieval">
<name>Credential Retrieval</name> <name>Credential Retrieval</name>
<t>This section describes the sub-protocol run during authentication to retrieve and <t>This section describes the sub-protocol run during authentication to retrieve and
recover the client credentials.</t> recover the client credentials.</t>
<section anchor="credential-retrieval-messages"> <section anchor="credential-retrieval-messages">
<name>Credential Retrieval Messages</name> <name>Credential Retrieval Messages</name>
<t>This section describes the <tt>CredentialRequest</tt> and <tt>Crede ntialResponse</tt> messages exchanged <t>This section describes the <tt>CredentialRequest</tt> and <tt>Crede ntialResponse</tt> messages exchanged
between client and server to perform credential retrieval.</t> between client and server to perform credential retrieval.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
struct { struct {
uint8 blinded_message[Noe]; uint8 blinded_message[Noe];
} CredentialRequest; } CredentialRequest;
]]></artwork> ]]></sourcecode>
<t>blinded_message: A serialized OPRF group element.</t> <dl spacing="normal" newline="false">
<artwork><![CDATA[ <dt>blinded_message:</dt><dd>A serialized OPRF group element.</dd>
</dl>
<sourcecode type=""><![CDATA[
struct { struct {
uint8 evaluated_message[Noe]; uint8 evaluated_message[Noe];
uint8 masking_nonce[Nn]; uint8 masking_nonce[Nn];
uint8 masked_response[Npk + Nn + Nm]; uint8 masked_response[Npk + Nn + Nm];
} CredentialResponse; } CredentialResponse;
]]></artwork> ]]></sourcecode>
<t>evaluated_message: A serialized OPRF group element.</t> <dl spacing="normal" newline="false">
<t>masking_nonce: A nonce used for the confidentiality of the <dt>evaluated_message:</dt><dd>A serialized OPRF group element.</dd>
<tt>masked_response</tt> field.</t> <dt>masking_nonce:</dt><dd>A nonce used for the confidentiality of
<t>masked_response: An encrypted form of the server's public key and t the <tt>masked_response</tt> field.</dd>
he <dt>masked_response:</dt><dd>An encrypted form of the server's
client's <tt>Envelope</tt> structure.</t> public key and the client's <tt>Envelope</tt> structure.</dd>
</dl>
</section> </section>
<section anchor="credential-retrieval-functions"> <section anchor="credential-retrieval-functions">
<name>Credential Retrieval Functions</name> <name>Credential Retrieval Functions</name>
<t>This section describes the <tt>CreateCredentialRequest</tt>, <tt>Cr eateCredentialResponse</tt>, <t>This section describes the <tt>CreateCredentialRequest</tt>, <tt>Cr eateCredentialResponse</tt>,
and <tt>RecoverCredentials</tt> functions used for credential retrieval.</t> and <tt>RecoverCredentials</tt> functions used for credential retrieval.</t>
<section anchor="create-credential-request"> <section anchor="create-credential-request">
<name>CreateCredentialRequest</name> <name>CreateCredentialRequest</name>
<t>The <tt>CreateCredentialRequest</tt> is used by the client to ini tiate the credential <t>The <tt>CreateCredentialRequest</tt> is used by the client to ini tiate the credential
retrieval process, and it produces a <tt>CredentialRequest</tt> message and OPRF state. retrieval process, and it produces a <tt>CredentialRequest</tt> message and OPRF state.
Like <tt>CreateRegistrationRequest</tt>, this function can fail with an <tt>Inva lidInputError</tt> Like <tt>CreateRegistrationRequest</tt>, this function can fail with an <tt>Inva lidInputError</tt>
error with negligible probability. However, this should not occur since error with negligible probability. However, this should not occur since
registration (via <tt>CreateRegistrationRequest</tt>) will fail when provided th e same registration (via <tt>CreateRegistrationRequest</tt>) will fail when provided th e same
password input.</t> password input.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
CreateCredentialRequest CreateCredentialRequest
Input: Input:
- password, an opaque byte string containing the client's password. - password, an opaque byte string containing the client's password.
Output: Output:
- request, a CredentialRequest structure. - request, a CredentialRequest structure.
- blind, an OPRF scalar value. - blind, an OPRF scalar value.
Exceptions: Exceptions:
- InvalidInputError, when Blind fails - InvalidInputError, when Blind fails
def CreateCredentialRequest(password): def CreateCredentialRequest(password):
(blind, blinded_element) = Blind(password) (blind, blinded_element) = Blind(password)
blinded_message = SerializeElement(blinded_element) blinded_message = SerializeElement(blinded_element)
request = CredentialRequest { request = CredentialRequest {
blinded_message blinded_message
} }
return (request, blind) return (request, blind)
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="create-credential-response"> <section anchor="create-credential-response">
<name>CreateCredentialResponse</name> <name>CreateCredentialResponse</name>
<t>The <tt>CreateCredentialResponse</tt> function is used by the ser ver to process the client's <t>The <tt>CreateCredentialResponse</tt> function is used by the ser ver to process the client's
<tt>CredentialRequest</tt> message and complete the credential retrieval process , producing <tt>CredentialRequest</tt> message and complete the credential retrieval process , producing
a <tt>CredentialResponse</tt>.</t> a <tt>CredentialResponse</tt>.</t>
<t>There are two scenarios to handle for the construction of a <tt>C redentialResponse</tt> <t>There are two scenarios to handle for the construction of a <tt>C redentialResponse</tt>
object: either the record for the client exists (corresponding to a properly object: either the record for the client exists (corresponding to a properly
registered client), or it was never created (corresponding to an unregistered registered client) or it was never created (corresponding to an unregistered
client identity, possibly the result of an enumeration attack attempt).</t> client identity, possibly the result of an enumeration attack attempt).</t>
<t>In the case of an existing record with the corresponding identifi er <t>In the case of an existing record with the corresponding identifi er
<tt>credential_identifier</tt>, the server invokes the following function to <tt>credential_identifier</tt>, the server invokes the following function to
produce a <tt>CredentialResponse</tt>:</t> produce a <tt>CredentialResponse</tt>:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
CreateCredentialResponse CreateCredentialResponse
Input: Input:
- request, a CredentialRequest structure. - request, a CredentialRequest structure.
- server_public_key, the public key of the server. - server_public_key, the public key of the server.
- record, an instance of RegistrationRecord which is the server's - record, an instance of RegistrationRecord which is the server's
output from registration. output from registration.
- credential_identifier, an identifier that uniquely represents - credential_identifier, an identifier that uniquely represents
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
skipping to change at line 1255 skipping to change at line 1343
masked_response = xor(credential_response_pad, masked_response = xor(credential_response_pad,
concat(server_public_key, record.envelope)) concat(server_public_key, record.envelope))
response = CredentialResponse { response = CredentialResponse {
evaluated_message, evaluated_message,
masking_nonce, masking_nonce,
masked_response masked_response
} }
return response return response
]]></artwork> ]]></sourcecode>
<t>In the case of a record that does not exist and if client enumera tion prevention is desired, <t>In the case of a record that does not exist and if client enumera tion prevention is desired,
the server MUST respond to the credential request to fake the existence of the r the server <bcp14>MUST</bcp14> respond to the credential request to fake the exi
ecord. stence of the record.
The server SHOULD invoke the <tt>CreateCredentialResponse</tt> function with a f The server <bcp14>SHOULD</bcp14> invoke the <tt>CreateCredentialResponse</tt> fu
ake client record nction with a fake client record
argument that is configured so that:</t> argument that is configured so that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><tt>record.client_public_key</tt> is set to a randomly genera ted public key of length <tt>Npk</tt></t> <t><tt>record.client_public_key</tt> is set to a randomly genera ted public key of length <tt>Npk</tt></t>
</li> </li>
<li> <li>
<t><tt>record.masking_key</tt> is set to a random byte string of length <tt>Nh</tt></t> <t><tt>record.masking_key</tt> is set to a random byte string of length <tt>Nh</tt></t>
</li> </li>
<li> <li>
<t><tt>record.envelope</tt> is set to the byte string consisting only of zeros of length <tt>Nn + Nm</tt></t> <t><tt>record.envelope</tt> is set to the byte string consisting only of zeros of length <tt>Nn + Nm</tt></t>
</li> </li>
</ul> </ul>
<t>It is RECOMMENDED that a fake client record is created once (e.g. <t>It is <bcp14>RECOMMENDED</bcp14> that a fake client record is cre
as the first user record ated once (e.g., as the first user record
of the application) and then stored alongside legitimate client records, to serv of the application) and then stored alongside legitimate client records to serve
e
subsequent client requests. This allows servers to retrieve the record in a time comparable subsequent client requests. This allows servers to retrieve the record in a time comparable
to that of a legitimate client record.</t> to that of a legitimate client record.</t>
<t>Note that the responses output by either scenario are indistingui shable to an adversary <t>Note that the responses output by either scenario are indistingui shable to an adversary
that is unable to guess the registered password for the client corresponding to <tt>credential_identifier</tt>.</t> that is unable to guess the registered password for the client corresponding to <tt>credential_identifier</tt>.</t>
</section> </section>
<section anchor="recover-credentials"> <section anchor="recover-credentials">
<name>RecoverCredentials</name> <name>RecoverCredentials</name>
<t>The <tt>RecoverCredentials</tt> function is used by the client to process the server's <t>The <tt>RecoverCredentials</tt> function is used by the client to process the server's
<tt>CredentialResponse</tt> message and produce the client's private key, server public <tt>CredentialResponse</tt> message and produce the client's private key, server public
key, and the <tt>export_key</tt>.</t> key, and the <tt>export_key</tt>.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
RecoverCredentials RecoverCredentials
Input: Input:
- password, an opaque byte string containing the client's password. - password, an opaque byte string containing the client's password.
- blind, an OPRF scalar value. - blind, an OPRF scalar value.
- response, a CredentialResponse structure. - response, a CredentialResponse structure.
- server_identity, The optional encoded server identity. - server_identity, The optional encoded server identity.
- client_identity, The encoded client identity. - client_identity, The encoded client identity.
Output: Output:
skipping to change at line 1327 skipping to change at line 1415
Npk + Nn + Nm) Npk + Nn + Nm)
concat(server_public_key, envelope) = concat(server_public_key, envelope) =
xor(credential_response_pad, response.masked_response) xor(credential_response_pad, response.masked_response)
(client_private_key, cleartext_credentials, export_key) = (client_private_key, cleartext_credentials, export_key) =
Recover(randomized_password, server_public_key, envelope, Recover(randomized_password, server_public_key, envelope,
server_identity, client_identity) server_identity, client_identity)
return (client_private_key, cleartext_credentials, export_key) return (client_private_key, cleartext_credentials, export_key)
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="protocol-3dh"> <section anchor="protocol-3dh">
<name>3DH Protocol</name> <name>3DH Protocol</name>
<t>This section describes the authenticated key exchange protocol for OP AQUE using <t>This section describes the authenticated key exchange protocol for OP AQUE using
3DH, a 3-message AKE which satisfies the forward secrecy and KCI properties 3DH, a 3-message AKE that satisfies the forward secrecy and KCI properties
discussed in <xref target="security-considerations"/>.</t> discussed in <xref target="security-considerations"/>.</t>
<t>The client AKE state <tt>ClientAkeState</tt> mentioned in <xref targe t="online-phase"/> has the <t>The client AKE state <tt>ClientAkeState</tt> mentioned in <xref targe t="online-phase"/> has the
following fields:</t> following fields:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>client_secret:</dt><dd>An opaque byte string of length <tt>Nsk</tt
<t>client_secret: An opaque byte string of length <tt>Nsk</tt>.</t> >.</dd>
</li> <dt>ke1:</dt><dd>A value of type <tt>KE1</tt>.</dd>
<li> </dl>
<t>ke1: A value of type <tt>KE1</tt>.</t>
</li>
</ul>
<t>The server AKE state <tt>ServerAkeState</tt> mentioned in <xref targe t="online-phase"/> has the <t>The server AKE state <tt>ServerAkeState</tt> mentioned in <xref targe t="online-phase"/> has the
following fields:</t> following fields:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>expected_client_mac:</dt><dd>An opaque byte string of length <tt>N
<t>expected_client_mac: An opaque byte string of length <tt>Nm</tt>. m</tt>.</dd>
</t> <dt>session_key:</dt><dd>An opaque byte string of length <tt>Nx</tt>.<
</li> /dd>
<li> </dl>
<t>session_key: An opaque byte string of length <tt>Nx</tt>.</t> <t>Sections <xref format="counter" target="ake-client"/> and <xref forma
</li> t="counter" target="ake-server"/> specify the inner workings of client and
</ul>
<t><xref target="ake-client"/> and <xref target="ake-server"/> specify t
he inner workings of client and
server functions, respectively.</t> server functions, respectively.</t>
<section anchor="key-creation"> <section anchor="key-creation">
<name>3DH Key Exchange Functions</name> <name>3DH Key Exchange Functions</name>
<t>We assume the following functions to exist for all Diffie-Hellman k ey exchange <t>We assume the following functions exist for all Diffie-Hellman key exchange
variants:</t> variants:</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>DeriveDiffieHellmanKeyPair(seed):</dt><dd>Derive a private and
<t>DeriveDiffieHellmanKeyPair(seed): Derive a private and public D public Diffie-Hellman key pair deterministically from the input
iffie-Hellman <tt>seed</tt>. The type of the private key depends on the
key pair deterministically from the input <tt>seed</tt>. The type of the private implementation, whereas the type of the public key is a byte
key string of <tt>Npk</tt> bytes.</dd>
depends on the implementation, whereas the type of the public key is a <dt>DiffieHellman(k, B):</dt><dd>A function that performs the
byte string of <tt>Npk</tt> bytes.</t> Diffie-Hellman operation between the private input <tt>k</tt> and
</li> public input <tt>B</tt>. The output of this function is a unique,
<li> fixed-length byte string.</dd>
<t>DiffieHellman(k, B): A function that performs the Diffie-Hellma </dl>
n operation <t>It is <bcp14>RECOMMENDED</bcp14> to use Elliptic Curve Diffie-Hellm
between the private input <tt>k</tt> and public input <tt>B</tt>. an for this key exchange protocol.
The output of this function is a unique, fixed-length byte string.</t>
</li>
</ul>
<t>It is RECOMMENDED to use Elliptic Curve Diffie-Hellman for this key
exchange protocol.
Implementations for recommended groups in <xref target="configurations"/>, as we ll as groups Implementations for recommended groups in <xref target="configurations"/>, as we ll as groups
covered by test vectors in <xref target="test-vectors"/>, are described in the f ollowing sections.</t> covered by test vectors in <xref target="test-vectors"/>, are described in the f ollowing sections.</t>
<section anchor="dh-ristretto255"> <section anchor="dh-ristretto255">
<name>3DH ristretto255</name> <name>3DH ristretto255</name>
<t>This section describes the implementation of the Diffie-Hellman k <t>This section describes the implementation of the Diffie-Hellman k
ey exchange functions based on ristretto255, ey exchange functions based on ristretto255
as defined in <xref target="RISTRETTO"/>.</t> as defined in <xref target="RFC9496"/>.</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>DeriveDiffieHellmanKeyPair(seed):</dt><dd>This function is
<t>DeriveDiffieHellmanKeyPair(seed): This function is implemente implemented as DeriveKeyPair(seed,
d as "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair is as
DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair is specified in <xref section="3.2" target="RFC9497"/>. The public
as specified in Section 3.2 of <xref target="RFC9497"/>. The public value from D value from DeriveKeyPair is encoded using SerializeElement from
eriveKeyPair <xref section="2.1" target="RFC9497"/>.</dd>
is encoded using SerializeElement from Section 2.1 of <xref target="RFC9497"/>.< <dt>DiffieHellman(k, B):</dt><dd>Implemented as scalar
/t> multiplication as described in <xref
</li> target="RFC9496"/> after decoding
<li> <tt>B</tt> from its encoded input using the Decode function in
<t>DiffieHellman(k, B): Implemented as scalar multiplication as <xref section="4.3.1"
described in target="RFC9496"/>. The output is
Section 4 of <xref target="RISTRETTO"/> after decoding <tt>B</tt> from its encod then encoded using the SerializeElement function of the OPRF
ed input using group described in <xref section="2.1" target="RFC9497"/>.</dd>
the Decode function in Section 4.3.1 of <xref target="RISTRETTO"/>. The output i </dl>
s then
encoded using the SerializeElement function of the OPRF group described in
Section 2.1 of <xref target="RFC9497"/>.</t>
</li>
</ul>
</section> </section>
<section anchor="dh-p-256"> <section anchor="dh-p-256">
<name>3DH P-256</name> <name>3DH P-256</name>
<t>This section describes the implementation of the Diffie-Hellman k ey exchange functions based on NIST P-256, <t>This section describes the implementation of the Diffie-Hellman k ey exchange functions based on NIST P-256
as defined in <xref target="NISTCurves"/>.</t> as defined in <xref target="NISTCurves"/>.</t>
<ul spacing="normal">
<li> <!--[rfced] We note that the following definition appears in both
<t>DeriveDiffieHellmanKeyPair(seed): This function is implemente Sections 6.4.1.1 and 6.4.1.2. Would you like to condense the second
d as instance as follows to avoid repetition/redundancy?
DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair is
as specified in Section 3.2 of <xref target="RFC9497"/>. The public value from D Original (Section 6.4.1.2):
eriveKeyPair DeriveDiffieHellmanKeyPair(seed): This function is implemented as
is encoded using SerializeElement from Section 2.1 of <xref target="RFC9497"/>.< DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"), where
/t> DeriveKeyPair is as specified in Section 3.2 of [RFC9497]. The
</li> public value from DeriveKeyPair is encoded using SerializeElement
<li> from Section 2.1 of [RFC9497].
<t>DiffieHellman(k, B): Implemented as scalar multiplication as
described in Perhaps:
<xref target="NISTCurves"/>, after decoding <tt>B</tt> from its encoded input us DeriveDiffieHellmanKeyPair(seed): See Section 6.4.1.1.
ing -->
the compressed Octet-String-to-Elliptic-Curve-Point method according to <xref ta <dl spacing="normal" newline="false">
rget="NISTCurves"/>. <dt>DeriveDiffieHellmanKeyPair(seed):</dt><dd>This function is
The output is then encoded using the SerializeElement function of the OPRF implemented as DeriveKeyPair(seed,
group described in Section 2.1 of <xref target="RFC9497"/>.</t> "OPAQUE-DeriveDiffieHellmanKeyPair"), where DeriveKeyPair is as
</li> specified in <xref section="3.2" target="RFC9497"/>. The public
</ul> value from DeriveKeyPair is encoded using SerializeElement from
<xref section="2.1" target="RFC9497"/>.</dd>
<dt>DiffieHellman(k, B):</dt><dd>Implemented as scalar
multiplication as described in <xref target="NISTCurves"/>,
after decoding <tt>B</tt> from its encoded input using the
compressed Octet-String-to-Elliptic-Curve-Point method according
to <xref target="NISTCurves"/>. The output is then encoded
using the SerializeElement function of the OPRF group described
in <xref section="2.1" target="RFC9497"/>.</dd>
</dl>
</section> </section>
<section anchor="dh-curve25519"> <section anchor="dh-curve25519">
<name>3DH Curve25519</name> <name>3DH Curve25519</name>
<t>This section describes the implementation of the Diffie-Hellman k <t>This section describes the implementation of the Diffie-Hellman k
ey exchange functions based on Curve25519, ey exchange functions based on Curve25519
as defined in <xref target="Curve25519"/>.</t> as defined in <xref target="RFC7748"/>.</t>
<ul spacing="normal"> <dl spacing="normal" newline="false">
<li> <dt>DeriveDiffieHellmanKeyPair(seed):</dt><dd>This function is
<t>DeriveDiffieHellmanKeyPair(seed): This function is implemente implemented by returning the private key <tt>k</tt> based on
d by returning the private seed (of length <tt>Nseed = 32</tt> bytes) as described in
key <tt>k</tt> based on seed (of length <tt>Nseed = 32</tt> bytes), as described <xref section="5" target="RFC7748"/>, as well as the result of
in Section 5 of <xref target="Curve25519"/>, DiffieHellman(k, B), where B is the base point of
as well as the result of DiffieHellman(k, B), where B is the base point of Curve Curve25519.</dd>
25519.</t> <dt>DiffieHellman(k, B):</dt><dd>Implemented using the X25519
</li> function in <xref section="5" target="RFC7748"/>. The output
<li> is then used raw with no processing.</dd>
<t>DiffieHellman(k, B): Implemented using the X25519 function in </dl>
Section 5 of <xref target="Curve25519"/>.
The output is then used raw, with no processing.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="key-schedule-functions"> <section anchor="key-schedule-functions">
<name>Key Schedule Functions</name> <name>Key Schedule Functions</name>
<t>This section contains functions used for the AKE key schedule.</t> <t>This section contains functions used for the AKE key schedule.</t>
<section anchor="transcript-functions"> <section anchor="transcript-functions">
<name>Transcript Functions</name> <name>Transcript Functions</name>
<t>The OPAQUE-3DH key derivation procedures make use of the function <t>The OPAQUE-3DH key derivation procedures make use of the function
s below, s below that are repurposed from TLS 1.3 <xref target="RFC8446"/>.</t>
re-purposed from TLS 1.3 <xref target="RFC8446"/>.</t> <sourcecode type=""><![CDATA[
<artwork><![CDATA[
Expand-Label(Secret, Label, Context, Length) = Expand-Label(Secret, Label, Context, Length) =
Expand(Secret, CustomLabel, Length) Expand(Secret, CustomLabel, Length)
]]></artwork> ]]></sourcecode>
<t>Where CustomLabel is specified and encoded (following Section 3.4 <t>Where CustomLabel is specified and encoded (following <xref secti
of <xref target="RFC8446"/>) as:</t> on="3.4" target="RFC8446"/>) as:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
struct { struct {
uint16 length = Length; uint16 length = Length;
opaque label<8..255> = "OPAQUE-" + Label; opaque label<8..255> = "OPAQUE-" + Label;
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)
]]></artwork> ]]></sourcecode>
<t>Note that the <tt>Label</tt> parameter is not a NULL-terminated s tring.</t> <t>Note that the <tt>Label</tt> parameter is not a NULL-terminated s tring.</t>
<t>OPAQUE-3DH can optionally include application-specific, shared <t t>context</tt> information in the <t>OPAQUE-3DH can optionally include application-specific, shared <t t>context</tt> information in the
transcript, such as configuration parameters or application-specific info, e.g. transcript, such as configuration parameters or application-specific info, e.g.,
"appXYZ-v1.2.3".</t> "appXYZ-v1.2.3".</t>
<t>The OPAQUE-3DH key schedule requires a preamble, which is compute d as follows.</t> <t>The OPAQUE-3DH key schedule requires a preamble, which is compute d as follows.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
Preamble Preamble
Parameters: Parameters:
- context, optional shared context information. - context, optional shared context information.
Input: Input:
- client_identity, the optional encoded client identity, which is set - client_identity, the optional encoded client identity, which is set
to client_public_key if not specified. to client_public_key if not specified.
- ke1, a KE1 message structure. - ke1, a KE1 message structure.
- server_identity, the optional encoded server identity, which is set - server_identity, the optional encoded server identity, which is set
skipping to change at line 1494 skipping to change at line 1587
server_nonce, server_public_keyshare): 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
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="shared-secret-derivation"> <section anchor="shared-secret-derivation">
<name>Shared Secret Derivation</name> <name>Shared Secret Derivation</name>
<t>The OPAQUE-3DH shared secret derived during the key exchange prot ocol is <t>The OPAQUE-3DH shared secret derived during the key exchange prot ocol is
computed using the following helper function.</t> computed using the following helper function.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
DeriveKeys DeriveKeys
Input: Input:
- ikm, input key material. - ikm, input key material.
- preamble, the protocol transcript with identities and messages. - preamble, the protocol transcript with identities and messages.
Output: Output:
- Km2, a MAC authentication key. - Km2, a MAC authentication key.
- Km3, a MAC authentication key. - Km3, a MAC authentication key.
- session_key, the shared session secret. - session_key, the shared session secret.
def DeriveKeys(ikm, preamble): def DeriveKeys(ikm, preamble):
prk = Extract("", ikm) prk = Extract("", ikm)
handshake_secret = handshake_secret =
Derive-Secret(prk, "HandshakeSecret",Hash(preamble)) Derive-Secret(prk, "HandshakeSecret",Hash(preamble))
session_key = session_key =
Derive-Secret(prk, "SessionKey", Hash(preamble)) Derive-Secret(prk, "SessionKey", Hash(preamble))
Km2 = Derive-Secret(handshake_secret, "ServerMAC", "") Km2 = Derive-Secret(handshake_secret, "ServerMAC", "")
Km3 = Derive-Secret(handshake_secret, "ClientMAC", "") Km3 = Derive-Secret(handshake_secret, "ClientMAC", "")
return (Km2, Km3, session_key) return (Km2, Km3, session_key)
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="ake-client"> <section anchor="ake-client">
<name>3DH Client Functions</name> <name>3DH Client Functions</name>
<t>The <tt>AuthClientStart</tt> function is used by the client to crea te a <t>The <tt>AuthClientStart</tt> function is used by the client to crea te a
<tt>KE1</tt> structure.</t> <tt>KE1</tt> structure.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
AuthClientStart AuthClientStart
Parameters: Parameters:
- Nn, the nonce length. - Nn, the nonce length.
State: State:
- state, a ClientAkeState structure. - state, a ClientAkeState structure.
Input: Input:
- credential_request, a CredentialRequest structure. - credential_request, a CredentialRequest structure.
skipping to change at line 1562 skipping to change at line 1655
} }
ke1 = KE1 { ke1 = KE1 {
credential_request, credential_request,
auth_request auth_request
} }
state.client_secret = client_secret state.client_secret = client_secret
state.ke1 = ke1 state.ke1 = ke1
return ke1 return ke1
]]></artwork> ]]></sourcecode>
<t>The <tt>AuthClientFinalize</tt> function is used by the client to c reate a <tt>KE3</tt> <t>The <tt>AuthClientFinalize</tt> function is used by the client to c reate a <tt>KE3</tt>
message and output <tt>session_key</tt> using the server's <tt>KE2</tt> message and message and output <tt>session_key</tt> using the server's <tt>KE2</tt> message and
recovered credential information.</t> recovered credential information.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
AuthClientFinalize AuthClientFinalize
State: State:
- state, a ClientAkeState structure. - state, a ClientAkeState structure.
Input: Input:
- cleartext_credentials, a CleartextCredentials structure. - cleartext_credentials, a CleartextCredentials structure.
- 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.
skipping to change at line 1609 skipping to change at line 1702
ke2.auth_response.server_public_keyshare) ke2.auth_response.server_public_keyshare)
Km2, Km3, session_key = DeriveKeys(ikm, preamble) Km2, Km3, session_key = DeriveKeys(ikm, preamble)
expected_server_mac = MAC(Km2, Hash(preamble)) expected_server_mac = MAC(Km2, Hash(preamble))
if !ct_equal(ke2.auth_response.server_mac, expected_server_mac), if !ct_equal(ke2.auth_response.server_mac, expected_server_mac),
raise ServerAuthenticationError raise ServerAuthenticationError
client_mac = MAC(Km3, Hash(concat(preamble, expected_server_mac))) client_mac = MAC(Km3, Hash(concat(preamble, expected_server_mac)))
ke3 = KE3 { ke3 = KE3 {
client_mac client_mac
} }
return (ke3, session_key) return (ke3, session_key)
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="ake-server"> <section anchor="ake-server">
<name>3DH Server Functions</name> <name>3DH Server Functions</name>
<t>The <tt>AuthServerRespond</tt> function is used by the server to pr ocess the client's <t>The <tt>AuthServerRespond</tt> function is used by the server to pr ocess the client's
<tt>KE1</tt> message and public credential information to create a <tt>KE2</tt> message.</t> <tt>KE1</tt> message and public credential information to create a <tt>KE2</tt> message.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
AuthServerRespond AuthServerRespond
Parameters: Parameters:
- Nn, the nonce length. - Nn, the nonce length.
State: State:
- state, a ServerAkeState structure. - state, a ServerAkeState structure.
Input: Input:
- cleartext_credentials, a CleartextCredentials structure. - cleartext_credentials, a CleartextCredentials structure.
skipping to change at line 1668 skipping to change at line 1761
MAC(Km3, Hash(concat(preamble, server_mac))) MAC(Km3, Hash(concat(preamble, server_mac)))
state.session_key = session_key state.session_key = session_key
auth_response = AuthResponse { auth_response = AuthResponse {
server_nonce, server_nonce,
server_public_keyshare, server_public_keyshare,
server_mac server_mac
} }
return auth_response return auth_response
]]></artwork> ]]></sourcecode>
<t>The <tt>AuthServerFinalize</tt> function is used by the server to p rocess the client's <t>The <tt>AuthServerFinalize</tt> function is used by the server to p rocess the client's
<tt>KE3</tt> message and output the final <tt>session_key</tt>.</t> <tt>KE3</tt> message and output the final <tt>session_key</tt>.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
AuthServerFinalize AuthServerFinalize
State: State:
- state, a ServerAkeState structure. - state, a ServerAkeState structure.
Input: Input:
- ke3, a KE3 structure. - ke3, a KE3 structure.
Output: Output:
- session_key, the shared session secret if and only if ke3 is valid. - session_key, the shared session secret if and only if ke3 is valid.
Exceptions: Exceptions:
- ClientAuthenticationError, the handshake fails. - ClientAuthenticationError, the handshake fails.
def AuthServerFinalize(ke3): def AuthServerFinalize(ke3):
if !ct_equal(ke3.client_mac, state.expected_client_mac): if !ct_equal(ke3.client_mac, state.expected_client_mac):
raise ClientAuthenticationError raise ClientAuthenticationError
return state.session_key return state.session_key
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="configurations"> <section anchor="configurations">
<name>Configurations</name> <name>Configurations</name>
<t>An OPAQUE-3DH configuration is a tuple (OPRF, KDF, MAC, Hash, KSF, Grou p, Context) <t>An OPAQUE-3DH configuration is a tuple (OPRF, KDF, MAC, Hash, KSF, Grou p, Context)
such that the following conditions are met:</t> such that the following conditions are met:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The OPRF protocol uses the <tt>modeOPRF</tt> configuration of Secti on 3.1 of <xref target="RFC9497"/> and <t>The OPRF protocol uses the <tt>modeOPRF</tt> configuration in <xref section="3.1" target="RFC9497"/> and
implements the interface in <xref target="dependencies"/>. Examples include rist retto255-SHA512 implements the interface in <xref target="dependencies"/>. Examples include rist retto255-SHA512
and P256-SHA256.</t> and P256-SHA256.</t>
</li> </li>
<li> <li>
<t>The KDF, MAC, and Hash functions implement the interfaces in <xref target="dependencies"/>. <t>The KDF, MAC, and Hash functions implement the interfaces in <xref target="dependencies"/>.
Examples include HKDF <xref target="RFC5869"/> for the KDF, HMAC <xref target="R FC2104"/> for the MAC, Examples include HKDF <xref target="RFC5869"/> for the KDF, HMAC <xref target="R FC2104"/> for the MAC,
and SHA-256 and SHA-512 for the Hash functions. If an extensible output function and SHA-256 and SHA-512 for the Hash functions. If an extensible output function
such as SHAKE128 <xref target="FIPS202"/> is used then the output length <tt>Nh< /tt> MUST be chosen such as SHAKE128 <xref target="FIPS202"/> is used, then the output length <tt>Nh </tt> <bcp14>MUST</bcp14> be chosen
to align with the target security level of the OPAQUE configuration. For example , to align with the target security level of the OPAQUE configuration. For example ,
if the target security parameter for the configuration is 128 bits, then <tt>Nh< /tt> SHOULD if the target security parameter for the configuration is 128 bits, then <tt>Nh< /tt> <bcp14>SHOULD</bcp14>
be at least 32 bytes.</t> be at least 32 bytes.</t>
</li> </li>
<li> <li>
<t>The KSF is determined by the application and implements the interfa ce in <t>The KSF is determined by the application and implements the interfa ce in
<xref target="dependencies"/>. As noted, collision resistance is required. Examp les for KSF <xref target="dependencies"/>. As noted, collision resistance is required. Examp les for KSF
include Argon2id <xref target="ARGON2"/>, scrypt <xref target="SCRYPT"/>, and PB include Argon2id <xref target="RFC9106"/>, scrypt <xref target="RFC7914"/>, and
KDF2 PBKDF2
<xref target="PBKDF2"/> with fixed parameter choices. See <xref target="app-cons <xref target="RFC8018"/> with fixed parameter choices. See <xref target="app-con
iderations"/> siderations"/>
for more information about this choice of function.</t> for more information about this choice of function.</t>
</li> </li>
<li> <li>
<t>The Group mode identifies the group used in the OPAQUE-3DH AKE. Thi s SHOULD <t>The Group mode identifies the group used in the OPAQUE-3DH AKE. Thi s <bcp14>SHOULD</bcp14>
match that of the OPRF. For example, if the OPRF is ristretto255-SHA512, match that of the OPRF. For example, if the OPRF is ristretto255-SHA512,
then Group SHOULD be ristretto255.</t> then Group <bcp14>SHOULD</bcp14> be ristretto255.</t>
</li> </li>
</ul> </ul>
<t>Context is the shared parameter used to construct the preamble in <xref target="transcript-functions"/>. <t>Context is the shared parameter used to construct the preamble in <xref target="transcript-functions"/>.
This parameter SHOULD include any application-specific configuration information or This parameter <bcp14>SHOULD</bcp14> include any application-specific configurat ion information or
parameters that are needed to prevent cross-protocol or downgrade attacks.</t> parameters that are needed to prevent cross-protocol or downgrade attacks.</t>
<t>Absent an application-specific profile, the following configurations ar e RECOMMENDED:</t> <t>Absent an application-specific profile, the following configurations ar e <bcp14>RECOMMENDED</bcp14>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>ristretto255-SHA512, HKDF-SHA-512, HMAC-SHA-512, SHA-512, <t>ristretto255-SHA512, HKDF-SHA-512, HMAC-SHA-512, SHA-512,
Argon2id(S = zeroes(16), p = 4, T = Nh, m = 2^21, t = 1, v = 0x13, K = nil, X = nil, y = 2), ristretto255</t> Argon2id(S = zeroes(16), p = 4, T = Nh, m = 2^21, t = 1, v = 0x13, K = nil, X = nil, y = 2), ristretto255</t>
</li> </li>
<li> <li>
<t>P256-SHA256, HKDF-SHA-256, HMAC-SHA-256, SHA-256, <t>P256-SHA256, HKDF-SHA-256, HMAC-SHA-256, SHA-256,
Argon2id(S = zeroes(16), p = 4, T = Nh, m = 2^21, t = 1, v = 0x13, K = nil, X = nil, y = 2), P-256</t> Argon2id(S = zeroes(16), p = 4, T = Nh, m = 2^21, t = 1, v = 0x13, K = nil, X = nil, y = 2), P-256</t>
</li> </li>
<li> <li>
<t>P256-SHA256, HKDF-SHA-256, HMAC-SHA-256, SHA-256, <t>P256-SHA256, HKDF-SHA-256, HMAC-SHA-256, SHA-256,
scrypt(S = zeroes(16), N = 32768, r = 8, p = 1, dkLen = 32), P-256</t> scrypt(S = zeroes(16), N = 32768, r = 8, p = 1, dkLen = 32), P-256</t>
</li> </li>
</ul> </ul>
<t>The above recommended configurations target 128-bit security.</t> <t>The above recommended configurations target 128-bit security.</t>
<t>Future configurations may specify different combinations of dependent a lgorithms, <t>Future configurations may specify different combinations of dependent a lgorithms
with the following considerations:</t> with the following considerations:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The size of AKE public and private keys -- <tt>Npk</tt> and <tt>Nsk </tt>, respectively -- must adhere <t>The size of AKE public and private keys -- <tt>Npk</tt> and <tt>Nsk </tt>, respectively -- must adhere
to the output length limitations of the KDF Expand function. If HKDF is used, th is means to the output length limitations of the KDF Expand function. If HKDF is used, th is means
Npk, Nsk &lt;= 255 * Nx, where Nx is the output size of the underlying hash func tion. Npk, Nsk &lt;= 255 * Nx, where Nx is the output size of the underlying hash func tion.
See <xref target="RFC5869"/> for details.</t> See <xref target="RFC5869"/> for details.</t>
</li> </li>
<li> <li>
<t>The output size of the Hash function SHOULD be long enough to produ ce a key for <t>The output size of the Hash function <bcp14>SHOULD</bcp14> be long enough to produce a key for
MAC of suitable length. For example, if MAC is HMAC-SHA256, then <tt>Nh</tt> cou ld be MAC of suitable length. For example, if MAC is HMAC-SHA256, then <tt>Nh</tt> cou ld be
32 bytes.</t> 32 bytes.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="app-considerations"> <section anchor="app-considerations">
<name>Application Considerations</name> <name>Application Considerations</name>
<t>Beyond choosing an appropriate configuration, there are several paramet <t>Beyond choosing an appropriate configuration, there are several paramet
ers which ers that applications can use to control OPAQUE:</t>
applications can use to control OPAQUE:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Credential identifier: As described in <xref target="registration-p hase"/>, this is a unique <t>Credential identifier: As described in <xref target="registration-p hase"/>, this is a unique
handle to the client's credential being stored. In applications where there are alternate handle to the client's credential being stored. In applications where there are alternate
client identities that accompany an account, such as a username or email address , this client identities that accompany an account, such as a username or email address , this
identifier can be set to those alternate values. For simplicity, applications ma y choose identifier can be set to those alternate values. For simplicity, applications ma y choose
to set <tt>credential_identifier</tt> to be equal to <tt>client_identity</tt>. A pplications to set <tt>credential_identifier</tt> to be equal to <tt>client_identity</tt>. A pplications
MUST NOT use the same credential identifier for multiple clients.</t> <bcp14>MUST NOT</bcp14> use the same credential identifier for multiple clients. </t>
</li> </li>
<li> <li>
<t>Context information: As described in <xref target="configurations"/ >, applications may include <t>Context information: As described in <xref target="configurations"/ >, applications may include
a shared context string that is authenticated as part of the handshake. This par ameter a shared context string that is authenticated as part of the handshake. This par ameter
SHOULD include any configuration information or parameters that are needed to pr event <bcp14>SHOULD</bcp14> include any configuration information or parameters that a re needed to prevent
cross-protocol or downgrade attacks. This context information is not sent over t he cross-protocol or downgrade attacks. This context information is not sent over t he
wire in any key exchange messages. However, applications may choose to send it a longside wire in any key exchange messages. However, applications may choose to send it a longside
key exchange messages if needed for their use case.</t> key exchange messages if needed for their use case.</t>
</li> </li>
<li> <li>
<t>Client and server identities: As described in <xref target="client- material"/>, clients <t>Client and server identities: As described in <xref target="client- material"/>, clients
and servers are identified with their public keys by default. However, applicati ons and servers are identified with their public keys by default. However, applicati ons
may choose alternate identities that are pinned to these public keys. For exampl e, may choose alternate identities that are pinned to these public keys. For exampl e,
servers may use a domain name instead of a public key as their identifier. Absen servers may use a domain name instead of a public key as their identifier.
t
alternate notions of identity, applications SHOULD set these identities to nil Absent
alternate notions of identity, applications <bcp14>SHOULD</bcp14> set these iden
tities to nil
and rely solely on public key information.</t> and rely solely on public key information.</t>
</li> </li>
<li> <li>
<t>Configuration and envelope updates: Applications may wish to update or change their <t>Configuration and envelope updates: Applications may wish to update or change their
configuration or other parameters that affect the client's RegistrationRecord ov er configuration or other parameters that affect the client's RegistrationRecord ov er
time. Some reasons for changing these are to use different cryptographic algorit hms, time. Some reasons for changing these are to use different cryptographic algorit hms,
e.g., a different KSF with improved parameters, or to update key material that i s e.g., a different KSF with improved parameters, or to update key material that i s
cryptographically bound to the RegistrationRecord, such as the server's public k ey cryptographically bound to the RegistrationRecord, such as the server's public k ey
(server_public_key). Any such change will require users to re-register to create a (server_public_key). Any such change will require users to reregister to create a
new RegistrationRecord. Supporting these types of updates can be helpful for app lications new RegistrationRecord. Supporting these types of updates can be helpful for app lications
that anticipate such changes in their deployment setting.</t> that anticipate such changes in their deployment setting.</t>
</li> </li>
<li> <li>
<t>Password hardening parameters: Key stretching is done to help preve nt password disclosure <t>Password hardening parameters: Key stretching is done to help preve nt password disclosure
in the event of server compromise; see <xref target="key-stretch"/>. There is no ideal or default in the event of server compromise; see <xref target="key-stretch"/>. There is no ideal or default
set of parameters, though relevant specifications for KSFs give some reasonable set of parameters, though relevant specifications for KSFs give some reasonable
defaults.</t> defaults.</t>
</li> </li>
<li> <li>
<t>Enumeration prevention: As described in <xref target="create-creden <t>Enumeration prevention: If servers
tial-response"/>, if servers receive a credential request for a non-existent client, they <bcp14>SHOULD</bcp1
receive a credential request for a non-existent client, they SHOULD respond with 4> respond with a
a "fake" response to prevent active client enumeration attacks as described in <xr
"fake" response to prevent active client enumeration attacks. Servers that ef target="create-credential-response"/>. Servers that
implement this mitigation SHOULD use the same configuration information (such as implement this mitigation <bcp14>SHOULD</bcp14> use the same configuration infor
mation (such as
the oprf_seed) for all clients; see <xref target="preventing-client-enumeration" />. In settings the oprf_seed) for all clients; see <xref target="preventing-client-enumeration" />. In settings
where this attack is not a concern, servers may choose to not support this funct ionality.</t> where this attack is not a concern, servers may choose to not support this funct ionality.</t>
</li> </li>
<li> <li>
<t>Handling password changes: In the event of a password change, the c lient and <t>Handling password changes: In the event of a password change, the c lient and
server can run the registration phase using the new password as a server can run the registration phase using the new password as a
fresh instance (ensuring to resample all random values). The resulting fresh instance (ensuring to resample all random values). The resulting
registration record can then replace the previous record corresponding to registration record can then replace the previous record corresponding to
the client's old password registration.</t> the client's old password registration.</t>
</li> </li>
skipping to change at line 1834 skipping to change at line 1928
<t>This section documents considerations for OPAQUE implementations. This includes <t>This section documents considerations for OPAQUE implementations. This includes
implementation safeguards and error handling considerations.</t> implementation safeguards and error handling considerations.</t>
<section anchor="implementation-safeguards"> <section anchor="implementation-safeguards">
<name>Implementation Safeguards</name> <name>Implementation Safeguards</name>
<t>Certain information created, exchanged, and processed in OPAQUE is se nsitive. <t>Certain information created, exchanged, and processed in OPAQUE is se nsitive.
Specifically, all private key material and intermediate values, along with the Specifically, all private key material and intermediate values, along with the
outputs of the key exchange phase, are all secret. Implementations should not outputs of the key exchange phase, are all secret. Implementations should not
retain these values in memory when no longer needed. Moreover, all operations, retain these values in memory when no longer needed. Moreover, all operations,
particularly the cryptographic and group arithmetic operations, should be particularly the cryptographic and group arithmetic operations, should be
constant-time and independent of the bits of any secrets. This includes any constant-time and independent of the bits of any secrets. This includes any
conditional branching during the creation of the credential response, as needed conditional branching during the creation of the credential response as needed
to mitigate client enumeration attacks.</t> to mitigate client enumeration attacks.</t>
<t>As specified in <xref target="registration-phase"/> and <xref target= "online-phase"/>, OPAQUE only requires <t>As specified in <xref target="registration-phase"/> and <xref target= "online-phase"/>, OPAQUE only requires
the client password as input to the OPRF for registration and authentication. the client password as input to the OPRF for registration and authentication.
However, if <tt>client_identity</tt> can be bound to the client's registration r ecord However, if <tt>client_identity</tt> can be bound to the client's registration r ecord
(in that the identity will not change during the lifetime of the record), (i.e., the identity will not change during the lifetime of the record),
then an implementation SHOULD incorporate <tt>client_identity</tt> alongside the then an implementation <bcp14>SHOULD</bcp14> incorporate <tt>client_identity</tt
password as input to the OPRF. Furthermore, it is RECOMMENDED to incorporate > alongside the
password as input to the OPRF. Furthermore, it is <bcp14>RECOMMENDED</bcp14> to
incorporate
<tt>server_identity</tt> alongside the password as input to the OPRF. These <tt>server_identity</tt> alongside the password as input to the OPRF. These
additions provide domain separation for clients and servers; see additions provide domain separation for clients and servers; see
<xref target="security-analysis"/>.</t> <xref target="security-analysis"/>.</t>
</section> </section>
<section anchor="handling-online-guessing-attacks"> <section anchor="handling-online-guessing-attacks">
<name>Handling Online Guessing Attacks</name> <name>Handling Online Guessing Attacks</name>
<t>Online guessing attacks (against any aPAKE) can be done from <t>Online guessing attacks (against any aPAKE) can be done from
both the client side and the server side. In particular, a malicious server can both the client side and the server side. In particular, a malicious server can
attempt to simulate honest responses to learn the client's password. attempt to simulate honest responses to learn the client's password.
<!-- [rfced] May we rephrase this sentence for clarity?
Original:
While this constitutes an exhaustive online attack, hence
as expensive as an online guessing attack from the client side, it
can be mitigated when the channel between client and server is
authenticated, e.g., using server-authenticated TLS.
Perhaps:
While this constitutes an exhaustive online attack (as expensive
as a guessing attack from the client side), it can be mitigated when
the channel between client and server is authenticated, e.g., using
server-authenticated TLS.
-->
While this constitutes an exhaustive online attack, hence as expensive as an While this constitutes an exhaustive online attack, hence as expensive as an
online guessing attack from the client side, it can be mitigated when the channe l online guessing attack from the client side, it can be mitigated when the channe l
between client and server is authenticated, e.g., using server-authenticated TLS . between client and server is authenticated, e.g., using server-authenticated TLS .
In such cases, these online attacks are limited to clients and the authenticated server In such cases, these online attacks are limited to clients and the authenticated server
itself. Moreover, such a channel provides privacy of user information, including identity itself. Moreover, such a channel provides privacy of user information, including identity
and envelope values.</t> and envelope values.</t>
<t>Additionally, note that a client participating in the online login st age <t>Additionally, note that a client participating in the online login st age
will learn whether or not authentication is successful after receiving the will learn whether or not authentication is successful after receiving the
<tt>KE2</tt> message. This means that the server should treat any client which f ails to <tt>KE2</tt> message. This means that the server should treat any client which f ails to
send a subsequent <tt>KE3</tt> message as an authentication failure. This can be handled send a subsequent <tt>KE3</tt> message as an authentication failure. This can be handled
skipping to change at line 1902 skipping to change at line 2010
then an implementation should produce an error.</t> then an implementation should produce an error.</t>
<t>The errors in this document are meant as a guide for implementors. Th ey are not an <t>The errors in this document are meant as a guide for implementors. Th ey are not an
exhaustive list of all the errors an implementation might emit. For example, an exhaustive list of all the errors an implementation might emit. For example, an
implementation might run out of memory.</t> implementation might run out of memory.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>OPAQUE is defined as the composition of two functionalities: an OPRF an d <t>OPAQUE is defined as the composition of two functionalities: an OPRF an d
an AKE protocol. It can be seen as a "compiler" for transforming any AKE an AKE protocol. It can be seen as a "compiler" for transforming any AKE
protocol (with KCI security and forward secrecy; see <xref target="security-anal ysis"/>) protocol (with Key Compromise Impersonation (KCI) security and forward secrecy; see <xref target="security-analysis"/>)
into a secure aPAKE protocol. In OPAQUE, the client derives a private key into a secure aPAKE protocol. In OPAQUE, the client derives a private key
during password registration and retrieves this key each time during password registration and retrieves this key each time
it needs to authenticate to the server. The OPRF security properties it needs to authenticate to the server. The OPRF security properties
ensure that only the correct password can unlock the private key ensure that only the correct password can unlock the private key
while at the same time avoiding potential offline guessing attacks. while at the same time avoiding potential offline guessing attacks.
This general composability property provides great flexibility and This general composability property provides great flexibility and
enables a variety of OPAQUE instantiations, from optimized enables a variety of OPAQUE instantiations, from optimized
performance to integration with existing authenticated key exchange performance to integration with existing authenticated key exchange
protocols such as TLS.</t> protocols such as TLS.</t>
<section anchor="notable-design-differences"> <section anchor="notable-design-differences">
<name>Notable Design Differences</name> <name>Notable Design Differences</name>
<t>The specification as written here differs from the original cryptogra phic design in <xref target="JKX18"/> <t>The specification as written here differs from the original cryptogra phic design in <xref target="JKX18"/>
and the corresponding CFRG document <xref target="I-D.krawczyk-cfrg-opaque-06"/> , both of which were used and the corresponding CFRG document <xref target="I-D.krawczyk-cfrg-opaque"/>, b oth of which were used
as input to the CFRG PAKE competition. This section describes these differences, including as input to the CFRG PAKE competition. This section describes these differences, including
their motivation and explanation as to why they preserve the provable security o f OPAQUE based their motivation and explanation as to why they preserve the provable security o f OPAQUE based
on <xref target="JKX18"/>.</t> on <xref target="JKX18"/>.</t>
<t>The following list enumerates important functional differences that w ere made <t>The following list enumerates important functional differences that w ere made
as part of the protocol specification process to address application or as part of the protocol specification process to address application or
implementation considerations.</t> implementation considerations.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Clients construct envelope contents without revealing the passwor d to the <t>Clients construct envelope contents without revealing the passwor d to the
server, as described in <xref target="registration-phase"/>, whereas the servers construct server, as described in <xref target="registration-phase"/>, whereas the servers construct
envelopes in <xref target="JKX18"/>. This change adds to the security of the pro tocol. envelopes in <xref target="JKX18"/>. This change adds to the security of the pro tocol.
<xref target="JKX18"/> considered the case where the envelope was constructed by the <xref target="JKX18"/> considered the case where the envelope was constructed by the
server for reasons of compatibility with previous UC security modeling. <xref ta rget="HJKW23"/> server for reasons of compatibility with previous Universal Composability (UC) s ecurity modeling. <xref target="HJKW23"/>
analyzes the registration phase as specified in this document. This analyzes the registration phase as specified in this document. This
change was made to support registration flows where the client chooses the change was made to support registration flows where the client chooses the
password and wishes to keep it secret from the server, and it is compatible password and wishes to keep it secret from the server, and it is compatible
with the variant in <xref target="JKX18"/> that was originally analyzed.</t> with the variant in <xref target="JKX18"/> that was originally analyzed.</t>
</li> </li>
<li> <li>
<t>Envelopes do not contain encrypted credentials. Instead, envelope s contain <t>Envelopes do not contain encrypted credentials. Instead, envelope s contain
information used to derive client private key material for the AKE. information used to derive client private key material for the AKE.
This change improves the assumption behind the protocol by getting rid of This change improves the assumption behind the protocol by getting rid of
equivocality and random key robustness for the encryption function. equivocality and random key robustness for the encryption function.
skipping to change at line 1950 skipping to change at line 2058
needed for the MAC function. This change was made for two reasons. First, it needed for the MAC function. This change was made for two reasons. First, it
reduces the number of bytes stored in envelopes, which is a helpful reduces the number of bytes stored in envelopes, which is a helpful
improvement for large applications of OPAQUE with many registered users. improvement for large applications of OPAQUE with many registered users.
Second, it removes the need for client applications to generate private Second, it removes the need for client applications to generate private
keys during registration. Instead, this responsibility is handled by OPAQUE, keys during registration. Instead, this responsibility is handled by OPAQUE,
thereby simplifying the client interface to the protocol.</t> thereby simplifying the client interface to the protocol.</t>
</li> </li>
<li> <li>
<t>Envelopes are masked with a per-user masking key as a way of prev enting <t>Envelopes are masked with a per-user masking key as a way of prev enting
client enumeration attacks. See <xref target="preventing-client-enumeration"/> f or more client enumeration attacks. See <xref target="preventing-client-enumeration"/> f or more
details. This extension is not needed for the security of OPAQUE as an aPAKE details. This extension is not needed for the security of OPAQUE as an aPAKE,
but only used to provide a defense against enumeration attacks. In the but is only used to provide a defense against enumeration attacks. In the
analysis, the masking key can be simulated as a (pseudo) random key. This analysis, the masking key can be simulated as a (pseudo) random key. This
change was made to support real-world use cases where client or user change was made to support real-world use cases where client or user
enumeration is a security (or privacy) risk.</t> enumeration is a security (or privacy) risk.</t>
</li> </li>
<li> <li>
<t>Per-user OPRF keys are derived from a client identity and cross-u ser PRF seed <t>Per-user OPRF keys are derived from a client identity and cross-u ser PRF seed
as a mitigation against client enumeration attacks. See as a mitigation against client enumeration attacks. See
<xref target="preventing-client-enumeration"/> for more details. The analysis of OPAQUE <xref target="preventing-client-enumeration"/> for more details. The analysis of OPAQUE
assumes OPRF keys of different users are independently random or assumes OPRF keys of different users are independently random or
pseudorandom. Deriving these keys via a single PRF (i.e., with a single pseudorandom. Deriving these keys via a single PRF (i.e., with a single
skipping to change at line 2005 skipping to change at line 2113
<li> <li>
<t>The protocol admits application-specific context information conf igured <t>The protocol admits application-specific context information conf igured
out-of-band in the AKE transcript. This allows domain separation between out-of-band in the AKE transcript. This allows domain separation between
different application uses of OPAQUE. This is a mechanism for the AKE different application uses of OPAQUE. This is a mechanism for the AKE
component and is best practice for domain separation between different component and is best practice for domain separation between different
applications of the protocol. This change was made to allow different applications of the protocol. This change was made to allow different
applications to use OPAQUE without the risk of cross-protocol attacks.</t> applications to use OPAQUE without the risk of cross-protocol attacks.</t>
</li> </li>
<li> <li>
<t>Servers use a separate identifier for computing OPRF evaluations and <t>Servers use a separate identifier for computing OPRF evaluations and
indexing into the registration record storage, called the credential_identifier. indexing into the registration record storage called the credential_identifier.
This allows clients to change their application-layer identity This allows clients to change their application-layer identity
(client_identity) without inducing server-side changes, e.g., by changing (client_identity) without inducing server-side changes, e.g., by changing
an email address associated with a given account. This mechanism is part an email address associated with a given account. This mechanism is part
of the derivation of OPRF keys via a single PRF. As long as the derivation of 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, the of different OPRF keys from a single PRF has different PRF inputs, the
protocol is secure. The choice of such inputs is up to the application.</t> protocol is secure. The choice of such inputs is up to the application.</t>
</li> </li>
<li> <li>
<!-- [rfced] May we specify which entity is running an offline dictionary
attack and rephrase the text for clarity?
Original:
The authors
suggest implementing the OPRF phase as a threshold OPRF [TOPPSS],
effectively forcing an attacker to act online or to control at
least t key shares (among the total n), where t is the threshold
number of shares necessary to recombine the secret OPRF key, and
only then be able to run an offline dictionary attack.
Perhaps:
The authors suggest implementing the OPRF phase as a threshold OPRF
[TOPPSS], effectively forcing an attacker to act online or control at
least t key shares (of the total n), where t is the threshold number
of shares necessary to recombine the secret OPRF key. Only then would
an attacker be able to run an offline dictionary attack.
-->
<t><xref target="JKX18"/> comments on a defense against offline <t><xref target="JKX18"/> comments on a defense against offline
dictionary attacks upon server compromise or honest-but-curious servers. dictionary attacks upon server compromise or honest-but-curious servers.
The authors suggest implementing the OPRF phase as a threshold OPRF <xref target ="TOPPSS"/>, The authors suggest implementing the OPRF phase as a threshold OPRF <xref target ="TOPPSS"/>,
effectively forcing an attacker to act online or to control at least t key effectively forcing an attacker to act online or to control at least t key
shares (among the total n), where t is the threshold number of shares necessary shares (among the total n), where t is the threshold number of shares necessary
to recombine the secret OPRF key, and only then be able to run an offline dictio nary to recombine the secret OPRF key, and only then be able to run an offline dictio nary
attack. This implementation only affects the server and changes nothing for the client. attack. This implementation only affects the server and changes nothing for the client.
Furthermore, if the threshold OPRF servers holding these keys are separate from Furthermore, if the threshold OPRF servers holding these keys are separate from
the authentication server, then recovering all n shares would still not suffice the authentication server, then recovering all n shares would still not suffice
to run an offline dictionary attack without access to the client record database . to run an offline dictionary attack without access to the client record database .
However, this mechanism is out of scope for this document.</t> However, this mechanism is out of scope for this document.</t>
</li> </li>
</ul> </ul>
<t>The following list enumerates notable differences and refinements fro m the original <t>The following list enumerates notable differences and refinements fro m the original
cryptographic design in <xref target="JKX18"/> and the corresponding CFRG docume nt cryptographic design in <xref target="JKX18"/> and the corresponding CFRG docume nt
<xref target="I-D.krawczyk-cfrg-opaque-06"/> that were made to make this specifi cation <xref target="I-D.krawczyk-cfrg-opaque"/> that were made to make this specificat ion
suitable for interoperable implementations.</t> suitable for interoperable implementations.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><xref target="JKX18"/> used a generic prime-order group for the D H-OPRF and HMQV operations, <t><xref target="JKX18"/> used a generic prime-order group for the D H-OPRF and HMQV operations,
and includes necessary prime-order subgroup checks when receiving attacker-contr olled and includes necessary prime-order subgroup checks when receiving attacker-contr olled
values over the wire. This specification instantiates the prime-order group used for values over the wire. This specification instantiates the prime-order group used for
3DH using prime-order groups based on elliptic curves, as described in 3DH using prime-order groups based on elliptic curves as described in
Section 2.1 of <xref target="RFC9497"/>. This specification also delegates OPRF <xref section="2.1" target="RFC9497"/>. This specification also delegates OPRF g
group roup
choice and operations to Section 4 of <xref target="RFC9497"/>. As such, the pri choice and operations to <xref section="4" target="RFC9497"/>. As such, the prim
me-order group as used e-order group as used
in the OPRF and 3DH as specified in this document both adhere to the requirement in the OPRF and 3DH as specified in this document both adhere to the requirement
s as s in
<xref target="JKX18"/>.</t> <xref target="JKX18"/>.</t>
</li> </li>
<li> <li>
<!-- [rfced] Does the following text refer to Appendix B of this document or
to an appendix in [JKX18]? Please review.
Original:
* [JKX18] specified DH-OPRF (see Appendix B) to instantiate the OPRF
functionality in the protocol.
-->
<t><xref target="JKX18"/> specified DH-OPRF (see Appendix B) to inst antiate <t><xref target="JKX18"/> specified DH-OPRF (see Appendix B) to inst antiate
the OPRF functionality in the protocol. A critical part of DH-OPRF is the the OPRF functionality in the protocol. A critical part of DH-OPRF is the
hash-to-group operation, which was not instantiated in the original analysis. hash-to-group operation, which was not instantiated in the original analysis.
However, the requirements for this operation were included. This specification However, the requirements for this operation were included. This specification
instantiates the OPRF functionality based on Section 3.3.1 of <xref target="RFC9 497"/>, which instantiates the OPRF functionality based on <xref section="3.3.1" target="RFC94 97"/>, which
is identical to the DH-OPRF functionality in <xref target="JKX18"/> and, concret ely, uses is identical to the DH-OPRF functionality in <xref target="JKX18"/> and, concret ely, uses
the hash-to-curve functions in <xref target="RFC9380"/>. All hash-to-curve the hash-to-curve functions in <xref target="RFC9380"/>. All hash-to-curve
methods in <xref target="RFC9380"/> are compliant with the requirement methods in <xref target="RFC9380"/> are compliant with the requirement
in <xref target="JKX18"/>, namely, that the output be a member of the prime-orde r group.</t> in <xref target="JKX18"/>, namely, that the output be a member of the prime-orde r group.</t>
</li> </li>
<li> <li>
<t><xref target="JKX18"/> and <xref target="I-D.krawczyk-cfrg-opaque -06"/> both used HMQV as the AKE <t><xref target="JKX18"/> and <xref target="I-D.krawczyk-cfrg-opaque "/> both used HMQV as the AKE
for the protocol. However, this document fully specifies 3DH instead of HMQV for the protocol. However, this document fully specifies 3DH instead of HMQV
(though a sketch for how to instantiate OPAQUE using HMQV is included in <xref t arget="hmqv-sketch"/>). (though a sketch for how to instantiate OPAQUE using HMQV is included in <xref t arget="hmqv-sketch"/>).
Since 3DH satisfies the essential requirements for the AKE as described in <xref target="JKX18"/> Since 3DH satisfies the essential requirements for the AKE as described in <xref target="JKX18"/>
and <xref target="I-D.krawczyk-cfrg-opaque-06"/>, as recalled in <xref target="s ecurity-analysis"/>, this change and <xref target="I-D.krawczyk-cfrg-opaque"/>, as recalled in <xref target="secu rity-analysis"/>, this change
preserves the overall security of the protocol. 3DH was chosen for its preserves the overall security of the protocol. 3DH was chosen for its
simplicity and ease of implementation.</t> simplicity and ease of implementation.</t>
</li> </li>
<li> <li>
<t>The DH-OPRF and HMQV instantiation of OPAQUE in <xref target="JKX <!-- [rfced] It does not appear that [JKX18] has a Figure 12; it
18"/>, Figure 12 uses appears to go up to Figure 10. However, [JKX18Full] has a Figure 12.
Please review and let us know how this text should be updated.
Original:
* The DH-OPRF and HMQV instantiation of OPAQUE in [JKX18], Figure 12
uses a different transcript than that which is described in this
specification.
Perhaps (if you intended Figure 12 in [JKX18Full]):
* The DH-OPRF and HMQV instantiation of OPAQUE as shown in Figure 12
of [JKX18Full] uses a different transcript than that which is
described in this specification.
-->
<t>The DH-OPRF and HMQV instantiation of OPAQUE in Figure 12 <xref t
arget="JKX18"/> uses
a different transcript than that which is described in this specification. In pa rticular, a different transcript than that which is described in this specification. In pa rticular,
the key exchange transcript specified in <xref target="protocol-3dh"/> is a supe rset of the transcript the key exchange transcript specified in <xref target="protocol-3dh"/> is a supe rset of the transcript
as defined in <xref target="JKX18"/>. This was done to align with best practices as defined in <xref target="JKX18"/>. This was done to align with best practices
, such as is , like what is done for key exchange protocols like TLS 1.3 <xref target="RFC844
done for key exchange protocols like TLS 1.3 <xref target="RFC8446"/>.</t> 6"/>.</t>
</li> </li>
<li> <li>
<t>Neither <xref target="JKX18"/> nor <xref target="I-D.krawczyk-cfr g-opaque-06"/> included wire format details for the <t>Neither <xref target="JKX18"/> nor <xref target="I-D.krawczyk-cfr g-opaque"/> included wire format details for the
protocol, which is essential for interoperability. This specification fills this protocol, which is essential for interoperability. This specification fills this
gap by including such wire format details and corresponding test vectors; see <x ref target="test-vectors"/>.</t> gap by including such wire format details and corresponding test vectors; see <x ref target="test-vectors"/>.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="security-analysis"> <section anchor="security-analysis">
<name>Security Analysis</name> <name>Security Analysis</name>
<t>Jarecki et al. <xref target="JKX18"/> proved the security of OPAQUE ( modulo the <t>Jarecki et al.&nbsp;<xref target="JKX18"/> proved the security of OPA QUE (modulo the
design differences outlined in <xref target="notable-design-differences"/>) design differences outlined in <xref target="notable-design-differences"/>)
in a strong aPAKE model that ensures security against pre-computation attacks in a strong aPAKE model that ensures security against precomputation attacks
and is formulated in the Universal Composability (UC) framework <xref target="Ca and is formulated in the UC framework <xref target="Canetti01"/>
netti01"/>
under the random oracle model. This assumes security of the OPRF under the random oracle model. This assumes security of the OPRF
function and the underlying key exchange protocol.</t> function and the underlying key exchange protocol.</t>
<t>OPAQUE's design builds on a line of work initiated in the seminal <t>OPAQUE's design builds on a line of work initiated in the seminal
paper of Ford and Kaliski <xref target="FK00"/> and is based on the HPAKE protoc ol paper of Ford and Kaliski <xref target="FK00"/> and is based on the HPAKE protoc ol
of Xavier Boyen <xref target="Boyen09"/> and the (1,1)-PPSS protocol from Jareck i of Xavier Boyen <xref target="Boyen09"/> and the (1,1)-PPSS protocol from Jareck i
et al. <xref target="JKKX16"/>. None of these papers considered security against et al.&nbsp;<xref target="JKKX16"/>. None of these papers considered security ag
pre-computation attacks or presented a proof of aPAKE security ainst
precomputation attacks or presented a proof of aPAKE security
(not even in a weak model).</t> (not even in a weak model).</t>
<t>The KCI property required from AKE protocols for use with OPAQUE <t>The KCI property required from AKE protocols for use with OPAQUE
states that knowledge of a party's private key does not allow an attacker states that knowledge of a party's private key does not allow an attacker
to impersonate others to that party. This is an important security to impersonate others to that party. This is an important security
property achieved by most public-key-based AKE protocols, including property achieved by most public-key-based AKE protocols, including
protocols that use signatures or public key encryption for protocols that use signatures or public key encryption for
authentication. It is also a property of many implicitly authentication. It is also a property of many implicitly
authenticated protocols, e.g., HMQV, but not all of them. We also note that authenticated protocols, e.g., HMQV, but not all of them. We also note that
key exchange protocols based on shared keys do not satisfy the KCI key exchange protocols based on shared keys do not satisfy the KCI
requirement, hence they are not considered in the OPAQUE setting. requirement, hence they are not considered in the OPAQUE setting.
We note that KCI is needed to ensure a crucial property of OPAQUE: even upon We note that KCI is needed to ensure a crucial property of OPAQUE. Even upon
compromise of the server, the attacker cannot impersonate the client to the compromise of the server, the attacker cannot impersonate the client to the
server without first running an exhaustive dictionary attack. server without first running an exhaustive dictionary attack.
Another essential requirement from AKE protocols for use in OPAQUE is to Another essential requirement from AKE protocols for use in OPAQUE is to
provide forward secrecy (against active attackers).</t> provide forward secrecy (against active attackers).</t>
<t>In <xref target="JKX18"/>, security is proven for one instance (i.e., one <t>In <xref target="JKX18"/>, security is proven for one instance (i.e., one
key) of the OPAQUE protocol, and without batching. There is currently no key) 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.</t> document in a setting with multiple server keys or batching.</t>
<t>As stated in <xref target="implementation-safeguards"/>, incorporatin g <tt>client_identity</tt> <t>As stated in <xref target="implementation-safeguards"/>, incorporatin g <tt>client_identity</tt>
adds domain separation, in particular against servers that choose the same adds domain separation, particularly against servers that choose the same
OPRF key for multiple clients. The <tt>client_identity</tt> as input to the OPRF OPRF key for multiple clients. The <tt>client_identity</tt> as input to the OPRF
also acts as a key identifier that would be required for a proof of the 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 <xref target="JKX18"/> assumes protocol in the multi-key setting; the OPAQUE analysis in <xref target="JKX18"/> assumes
single server-key instances. Adding <tt>server_identity</tt> to the OPRF input single server-key instances. Adding <tt>server_identity</tt> to the OPRF input
provides domain separation for clients that reuse the same <tt>client_identity</ tt> provides domain separation for clients that reuse the same <tt>client_identity</ tt>
across different server instantiations.</t> across different server instantiations.</t>
</section> </section>
<section anchor="identities"> <section anchor="identities">
<name>Identities</name> <name>Identities</name>
<t>AKE protocols generate keys that need to be uniquely and verifiably b ound to a pair <t>AKE protocols generate keys that need to be uniquely and verifiably b ound to a pair
of identities. In the case of OPAQUE, those identities correspond to client_iden tity and server_identity. of identities. In the case of OPAQUE, those identities correspond to client_iden tity and server_identity.
Thus, it is essential for the parties to agree on such identities, including an Thus, it is essential for the parties to agree on such identities, including an
agreed bit representation of these identities as needed.</t> agreed bit representation of these identities as needed.</t>
<t>Note that the method of transmission of client_identity from client t o server is outside <t>Note that the method of transmission of client_identity from client t o server is outside
the scope of this protocol, and it is up to an application to choose how this id the scope of this protocol and it is up to an application to choose how this ide
entity ntity
should be delivered (for instance, alongside the first OPAQUE message, or perhap should be delivered (for instance, alongside the first OPAQUE message or agreed
s agreed upon before upon before
the OPAQUE protocol begins).</t> the OPAQUE protocol begins).</t>
<t>Applications may have different policies about how and when identitie s are <t>Applications may have different policies about how and when identitie s are
determined. A natural approach is to tie client_identity to the identity the ser ver uses determined. A natural approach is to tie client_identity to the identity the ser ver uses
to fetch the envelope (determined during password registration) and to tie serve r_identity to fetch the envelope (determined during password registration) and tie server_i dentity
to the server identity used by the client to initiate an offline password to the server identity used by the client to initiate an offline password
registration or online authenticated key exchange session. server_identity and c lient_identity can also registration or online authenticated key exchange session. server_identity and c lient_identity can also
be part of the envelope or be tied to the parties' public keys. In principle, id entities be part of the envelope or tied to the parties' public keys. In principle, ident ities
may change across different sessions as long as there is a policy that may change across different sessions as long as there is a policy that
can establish if the identity is acceptable or not to the peer. However, we note can establish if the identity is acceptable or not to the peer. However, we note
that the public keys of both the server and the client must always be those defi ned that the public keys of both the server and the client must always be those defi ned
at the time of password registration.</t> at the time of password registration.</t>
<t>The client identity (client_identity) and server identity (server_ide ntity) are <t>The client identity (client_identity) and server identity (server_ide ntity) are
optional parameters that are left to the application to designate as aliases for optional parameters that are left to the application to designate as aliases for
the client and server. If the application layer does not supply values for these the client and server. If the application layer does not supply values for these
parameters, then they will be omitted from the creation of the envelope parameters, then they will be omitted from the creation of the envelope
during the registration stage. Furthermore, they will be substituted with during the registration stage. Furthermore, they will be substituted with
client_identity = client_public_key and server_identity = server_public_key duri ng client_identity = client_public_key and server_identity = server_public_key duri ng
skipping to change at line 2157 skipping to change at line 2303
are protected by the authentication from the envelope. Then, the client can veri fy that the are protected by the authentication from the envelope. Then, the client can veri fy that the
client_identity and server_identity contained in its envelope match the client_i dentity client_identity and server_identity contained in its envelope match the client_i dentity
and server_identity supplied by the server.</t> and server_identity supplied by the server.</t>
<t>However, if this extra layer of verification is unnecessary for the a pplication, then simply <t>However, if this extra layer of verification is unnecessary for the a pplication, then simply
leaving client_identity and server_identity unspecified (and using client_public _key and leaving client_identity and server_identity unspecified (and using client_public _key and
server_public_key instead) is acceptable.</t> server_public_key instead) is acceptable.</t>
</section> </section>
<section anchor="export-key-usage"> <section anchor="export-key-usage">
<name>Export Key Usage</name> <name>Export Key Usage</name>
<t>The export key can be used (separately from the OPAQUE protocol) to p rovide <t>The export key can be used (separately from the OPAQUE protocol) to p rovide
confidentiality and integrity to other data which only the client should be confidentiality and integrity to other data that only the client should be
able to process. For instance, if the client wishes to store secrets with a able to process. For instance, if the client wishes to store secrets with a
third party, then this export key can be used by the client to encrypt these third party, then this export key can be used by the client to encrypt these
secrets so that they remain hidden from a passive adversary that does not have secrets so that they remain hidden from a passive adversary that does not have
access to the server's secret keys or the client's password.</t> access to the server's secret keys or the client's password.</t>
</section> </section>
<section anchor="static-diffie-hellman-oracles"> <section anchor="static-diffie-hellman-oracles">
<name>Static Diffie-Hellman Oracles</name> <name>Static Diffie-Hellman Oracles</name>
<t>While one can expect the practical security of the OPRF function (nam ely, <t>While one can expect the practical security of the OPRF function (nam ely,
the hardness of computing the function without knowing the key) to be in the the hardness of computing the function without knowing the key) to be in the
order of computing discrete logarithms or solving Diffie-Hellman, Brown and order of computing discrete logarithms or solving Diffie-Hellman, Brown and
Gallant <xref target="BG04"/> and Cheon <xref target="Cheon06"/> show an attack that slightly improves Gallant <xref target="BG04"/> and Cheon <xref target="Cheon06"/> show an attack that slightly improves
on generic attacks. For typical curves, the attack requires an infeasible on generic attacks. For typical curves, the attack requires an infeasible
number of calls to the OPRF or results in insignificant security loss; number of calls to the OPRF or results in insignificant security loss;
see Section 7.2.3 of <xref target="RFC9497"/> for more information. For OPAQUE, these attacks see <xref section="7.2.3" target="RFC9497"/> for more information. For OPAQUE, t hese attacks
are particularly impractical as they translate into an infeasible number of are particularly impractical as they translate into an infeasible number of
failed authentication attempts directed at individual users.</t> failed authentication attempts directed at individual users.</t>
</section> </section>
<section anchor="rkr-mac"> <section anchor="rkr-mac">
<name>Random-Key Robust MACs</name> <name>Random-Key Robust MACs</name>
<t>The random-key robustness property for a MAC states <t>The random-key robustness property for a MAC states
that, given two random keys k1 and k2, it is infeasible to find a message m that, given two random keys k1 and k2, it is infeasible to find a message m
such that MAC(k1, m) = MAC(k2, m). Note that in general, not every MAC function such that MAC(k1, m) = MAC(k2, m). Note that in general, not every MAC function
is key-robust. In particular, GMAC (which underlies GCM) does not satisfy is key-robust. In particular, GMAC (which underlies GCM) does not satisfy
key-robustness, whereas HMAC with a collision-resistant hash function does key-robustness, whereas HMAC with a collision-resistant hash function does
satisfy key-robustness.</t> satisfy key-robustness.</t>
<t>An application can choose to use a non-key-robust MAC within the AKE portion of <t>An application can choose to use a non-key-robust MAC within the AKE portion of
the protocol described in <xref target="protocol-3dh"/>, but it MUST use a key-r obust MAC the protocol described in <xref target="protocol-3dh"/>, but it <bcp14>MUST</bcp 14> use a key-robust MAC
for the creation of the <tt>auth_tag</tt> parameter in <xref target="envelope-cr eation"/>.</t> for the creation of the <tt>auth_tag</tt> parameter in <xref target="envelope-cr eation"/>.</t>
</section> </section>
<section anchor="validation"> <section anchor="validation">
<name>Input Validation</name> <name>Input Validation</name>
<t>Both client and server MUST validate the other party's public key(s) used <t>Both client and server <bcp14>MUST</bcp14> validate the other party's public key(s) used
for the execution of OPAQUE. This includes the keys shared during the for the execution of OPAQUE. This includes the keys shared during the
registration phase, as well as any keys shared during the online registration phase, as well as any keys shared during the online
key agreement phase. The validation procedure varies depending on the key agreement phase. The validation procedure varies depending on the
type of key. For example, for OPAQUE instantiations type of key. For example, for OPAQUE instantiations
using 3DH with P-256, P-384, or P-521 as the underlying group, validation using 3DH with P-256, P-384, or P-521 as the underlying group, validation
is as specified in Section 5.6.2.3.4 of <xref target="keyagreement"/>. This incl udes is as specified in Section 5.6.2.3.4 of <xref target="keyagreement"/>. This incl udes
checking that the coordinates are in the correct range, that the point checking that the coordinates are in the correct range, that the point
is on the curve, and that the point is not the point at infinity. is on the curve, and that the point is not the point at infinity.
Additionally, validation MUST ensure the Diffie-Hellman shared secret is Additionally, validation <bcp14>MUST</bcp14> ensure the Diffie-Hellman shared se cret is
not the point at infinity.</t> not the point at infinity.</t>
</section> </section>
<section anchor="key-stretch"> <section anchor="key-stretch">
<name>OPRF Key Stretching</name> <name>OPRF Key Stretching</name>
<t>Applying a key stretching function to the output of the OPRF greatly increases the cost of an offline <t>Applying a key stretching function to the output of the OPRF greatly increases the cost of an offline
attack upon the compromise of the credential file on the server. Applications attack upon the compromise of the credential file on the server. Applications
SHOULD select parameters for the KSF that balance cost and complexity across <bcp14>SHOULD</bcp14> select parameters for the KSF that balance cost and comple xity across
different client implementations and deployments. Note that in OPAQUE, the different client implementations and deployments. Note that in OPAQUE, the
key stretching function is executed by the client, as opposed to the server in key stretching function is executed by the client as opposed to the server in
traditional password hashing scenarios. This means that applications must consid er traditional password hashing scenarios. This means that applications must consid er
a tradeoff between the performance of the protocol on clients (specifically low- end a tradeoff between the performance of the protocol on clients (specifically low- end
devices) and protection against offline attacks after a server compromise.</t> devices) and protection against offline attacks after a server compromise.</t>
</section> </section>
<section anchor="preventing-client-enumeration"> <section anchor="preventing-client-enumeration">
<name>Client Enumeration</name> <name>Client Enumeration</name>
<t>Client enumeration refers to attacks where the attacker tries to lear n whether <t>Client enumeration refers to attacks where the attacker tries to lear n whether
a given user identity is registered with a server or whether a re-registration a given user identity is registered with a server or whether a reregistration
or change of password was performed for that user. OPAQUE counters these or change of password was performed for that user. OPAQUE counters these
attacks by requiring servers to act with unregistered client identities in a attacks by requiring servers to act with unregistered client identities in a
way that is indistinguishable from their behavior with existing registered clien ts. way that is indistinguishable from their behavior with existing registered clien ts.
Servers do this by simulating a fake CredentialResponse as specified in Servers do this by simulating a fake CredentialResponse as specified in
<xref target="create-credential-response"/> for unregistered users, and also enc rypting <xref target="create-credential-response"/> for unregistered users and encryptin g
CredentialResponse using a masking key. In this way, real and fake CredentialRes ponse CredentialResponse using a masking key. In this way, real and fake CredentialRes ponse
messages are indistinguishable from one another. messages are indistinguishable from one another.
Implementations must also take care to avoid side-channel leakage (e.g., timing Implementations must also take care to avoid side-channel leakage (e.g., timing
attacks) from helping differentiate these operations from a regular server attacks) from helping differentiate these operations from a regular server
response. Note that this may introduce possible abuse vectors since the response. Note that this may introduce possible abuse vectors since the
server's cost of generating a CredentialResponse is less than that of the server's cost of generating a CredentialResponse is less than that of the
client's cost of generating a CredentialRequest. Server implementations client's cost of generating a CredentialRequest. Server implementations
may choose to forego the construction of a simulated credential response may choose to forego the construction of a simulated credential response
message for an unregistered client if these client enumeration attacks can message for an unregistered client if these client enumeration attacks can
be mitigated through other application-specific means or are otherwise not be mitigated through other application-specific means or are otherwise not
applicable for their threat model.</t> applicable for their threat model.</t>
<t>OPAQUE does not prevent this type of attack during the registration f low. <t>OPAQUE does not prevent this type of attack during the registration f low.
Servers necessarily react differently during the registration flow between Servers necessarily react differently during the registration flow between
registered and unregistered clients. This allows an attacker to use the server's registered and unregistered clients. This allows an attacker to use the server's
response during registration as an oracle for whether a given client identity is response during registration as an oracle for whether a given client identity is
registered. Applications should mitigate against this type of attack by rate registered. Applications should mitigate against this type of attack by rate
limiting or otherwise restricting the registration flow.</t> limiting or otherwise restricting the registration flow.</t>
<t>Finally, applications that do not require protection against <t>Finally, applications that do not require protection against
client enumeration attacks can choose to derive independent OPRF keys for differ ent client enumeration attacks can choose to derive independent OPRF keys for differ ent
clients. The advantage to using independently-derived OPRF keys is that the serv er clients. The advantage to using independently-derived OPRF keys is that the serv er
avoids keeping the <tt>oprf_seed</tt> value across different clients, which if l avoids keeping the <tt>oprf_seed</tt> value across different clients, which, if
eaked would leaked, would
compromise the security for all clients reliant on <tt>oprf_seed</tt>, as noted compromise the security for all clients reliant on <tt>oprf_seed</tt> as noted i
in <xref target="DL24"/>.</t> n <xref target="DL24"/>.</t>
</section> </section>
<section anchor="protecting-the-registration-masking-key"> <section anchor="protecting-the-registration-masking-key">
<name>Protecting the Registration Masking Key</name> <name>Protecting the Registration Masking Key</name>
<t>The user enumeration prevention method described in this document use s a <t>The user enumeration prevention method described in this document use s a
symmetric encryption key, masking_key, generated and sent to the server symmetric encryption key, masking_key, generated and sent to the server
by the client during registration. This requires a confidential channel by the client during registration. This requires a confidential channel
between client and server during registration, e.g., using TLS <xref target="RFC 8446"/>. between client and server during registration, e.g., using TLS <xref target="RFC 8446"/>.
If the channel is only authenticated (this is a requirement for correct If the channel is only authenticated (this is a requirement for correct
identification of the parties), a confidential channel can be established identification of the parties), a confidential channel can be established
using public-key encryption, e.g., with HPKE <xref target="RFC9180"/>. However, the details using public-key encryption, e.g., with HPKE <xref target="RFC9180"/>. However, the details
of this mechanism are out of scope for this document.</t> of this mechanism are out of scope for this document.</t>
</section> </section>
<section anchor="password-salt-and-storage-implications"> <section anchor="password-salt-and-storage-implications">
<name>Password Salt and Storage Implications</name> <name>Password Salt and Storage Implications</name>
<t>In OPAQUE, the OPRF key acts as the secret salt value that ensures th e infeasibility <t>In OPAQUE, the OPRF key acts as the secret salt value that ensures th e infeasibility
of pre-computation attacks. No extra salt value is needed. Also, clients never of precomputation attacks. No extra salt value is needed. Also, clients never
disclose their passwords to the server, even during registration. Note that a co rrupted disclose their passwords to the server, even during registration. Note that a co rrupted
server can run an exhaustive offline dictionary attack to validate guesses for t he client's server can run an exhaustive offline dictionary attack to validate guesses for t he client's
password; this is inevitable in any (single-server) aPAKE protocol. It can be av oided in password; this is inevitable in any (single-server) aPAKE protocol. It can be av oided in
the case of OPAQUE by resorting to a multi-server threshold OPRF implementation, the case of OPAQUE by resorting to a multi-server threshold OPRF implementation,
e.g., <xref target="TOPPSS"/>. Furthermore, if the server does not e.g., <xref target="TOPPSS"/>. Furthermore, if the server does not
sample the PRF seed with sufficiently high entropy, or if it is not kept hidden from an sample the PRF seed with sufficiently high entropy, or if it is not kept hidden from an
adversary, then any derivatives from the client's password may also be susceptib le to an adversary, then any derivatives from the client's password may also be susceptib le to an
offline dictionary attack to recover the original password.</t> offline dictionary attack to recover the original password.</t>
<t>Some applications may require learning the client's password to enfor ce password <t>Some applications may require learning the client's password to enfor ce password
rules. Doing so invalidates this important security property of OPAQUE and is rules. Doing so invalidates this important security property of OPAQUE and is
NOT RECOMMENDED, unless it is not possible for applications to move such checks <bcp14>NOT RECOMMENDED</bcp14> unless it is not possible for applications to mov e such checks
to the client. Note that limited checks at the server are possible to implement, e.g., to the client. Note that limited checks at the server are possible to implement, e.g.,
detecting repeated passwords upon re-registrations or password change.</t> detecting repeated passwords upon reregistrations or password change.</t>
<t>In general, passwords should be selected with sufficient entropy to a void being susceptible <t>In general, passwords should be selected with sufficient entropy to a void being susceptible
to recovery through dictionary attacks, both online and offline.</t> to recovery through dictionary attacks, both online and offline.</t>
</section> </section>
<section anchor="ake-private-key-storage"> <section anchor="ake-private-key-storage">
<name>AKE Private Key Storage</name> <name>AKE Private Key Storage</name>
<t>Server implementations of OPAQUE do not need access to the raw AKE pr ivate key. They only require <t>Server implementations of OPAQUE do not need access to the raw AKE pr ivate key. They only require
the ability to compute shared secrets as specified in <xref target="key-schedule -functions"/>. Thus, applications the ability to compute shared secrets as specified in <xref target="key-schedule -functions"/>. Thus, applications
may store the server AKE private key in a Hardware Security Module (HSM) or may store the server AKE private key in a Hardware Security Module (HSM) or
similar. Upon compromise of <tt>oprf_seed</tt> and client envelopes, this would prevent an similar. Upon compromise of <tt>oprf_seed</tt> and client envelopes, this would prevent an
attacker from using this data to mount a server spoofing attack. Supporting impl ementations attacker from using this data to mount a server spoofing attack. Supporting impl ementations
skipping to change at line 2299 skipping to change at line 2445
computed in <xref target="finalize-request"/>) so that upon a future login attem pt, the client can computed in <xref target="finalize-request"/>) so that upon a future login attem pt, the client can
authenticate to the server using <tt>randomized_password</tt> instead of the ori ginal password. authenticate to the server using <tt>randomized_password</tt> instead of the ori ginal password.
This can be achieved by supplying an arbitrary password as input to This can be achieved by supplying an arbitrary password as input to
<tt>CreateCredentialRequest</tt> in the login phase, and then using <tt>randomiz ed_password</tt> from <tt>CreateCredentialRequest</tt> in the login phase, and then using <tt>randomiz ed_password</tt> from
the backup in <tt>RecoverCredentials</tt> (invoked by <tt>GenerateKE3</tt>) rath er than computing it from the backup in <tt>RecoverCredentials</tt> (invoked by <tt>GenerateKE3</tt>) rath er than computing it from
the password.</t> the password.</t>
<t>This provides an advantage over the regular authentication flow for l ogin <t>This provides an advantage over the regular authentication flow for l ogin
in that if <tt>randomized_password</tt> is compromised, an adversary cannot use this value to in that if <tt>randomized_password</tt> is compromised, an adversary cannot use this value to
successfully impersonate the server to the client during login. The drawback is that it is successfully impersonate the server to the client during login. The drawback is that it is
only applicable to settings where <tt>randomized_password</tt> can be treated as a credential only applicable to settings where <tt>randomized_password</tt> can be treated as a credential
which can be stored securely after registration and retrieved upon login.</t> that can be stored securely after registration and retrieved upon login.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no IANA requests.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9496" to="RISTRETTO"/>
<displayreference target="RFC8018" to="PBKDF2"/>
<displayreference target="RFC7748" to="Curve25519"/>
<displayreference target="RFC9106" to="ARGON2"/>
<displayreference target="RFC7914" to="SCRYPT"/>
<displayreference target="I-D.krawczyk-cfrg-opaque" to="Krawczyk20"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
le> 174.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<date month="March" year="1997"/> 086.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<t>In many standards track documents several words are used to sig 104.xml"/>
nify the requirements in the specification. These words are often capitalized. T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
his document defines these words as they should be interpreted in IETF documents 497.xml"/>
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC4086">
<front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="J. Schiller" initials="J." surname="Schiller"/>
<author fullname="S. Crocker" initials="S." surname="Crocker"/>
<date month="June" year="2005"/>
<abstract>
<t>Security systems are built on strong cryptographic algorithms t
hat foil pattern analysis attempts. However, the security of these systems is de
pendent on generating secret quantities for passwords, cryptographic keys, and s
imilar quantities. The use of pseudo-random processes to generate secret quantit
ies can result in pseudo-security. A sophisticated attacker may find it easier t
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re solution is not available, and it gives examples of how large such quantities
need to be for some applications. This document specifies an Internet Best Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="RFC2104">
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
<author fullname="M. Bellare" initials="M." surname="Bellare"/>
<author fullname="R. Canetti" initials="R." surname="Canetti"/>
<date month="February" year="1997"/>
<abstract>
<t>This document describes HMAC, a mechanism for message authentic
ation using cryptographic hash functions. HMAC can be used with any iterative cr
yptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared
key. The cryptographic strength of HMAC depends on the properties of the underl
ying hash function. This memo provides information for the Internet community. T
his memo does not specify an Internet standard of any kind</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2104"/>
<seriesInfo name="DOI" value="10.17487/RFC2104"/>
</reference>
<reference anchor="RFC9497">
<front>
<title>Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Gr
oups</title>
<author fullname="A. Davidson" initials="A." surname="Davidson"/>
<author fullname="A. Faz-Hernandez" initials="A." surname="Faz-Herna
ndez"/>
<author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
<author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
<date month="December" year="2023"/>
<abstract>
<t>An Oblivious Pseudorandom Function (OPRF) is a two-party protoc
ol between a client and a server for computing the output of a Pseudorandom Func
tion (PRF). The server provides the PRF private key, and the client provides the
PRF input. At the end of the protocol, the client learns the PRF output without
learning anything about the PRF private key, and the server learns neither the
PRF input nor output. An OPRF can also satisfy a notion of 'verifiability', call
ed a VOPRF. A VOPRF ensures clients can verify that the server used a specific p
rivate key during the execution of the protocol. A VOPRF can also be partially o
blivious, called a POPRF. A POPRF allows clients and servers to provide public i
nput to the PRF computation. This document specifies an OPRF, VOPRF, and POPRF i
nstantiated within standard prime-order groups, including elliptic curves. This
document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9497"/>
<seriesInfo name="DOI" value="10.17487/RFC9497"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.krawczyk-cfrg-opaque-06" target="https://datatrac <!-- [rfced] References
ker.ietf.org/doc/html/draft-krawczyk-cfrg-opaque-06">
<front> a) We note that the following reference is a version of the I-D
<title>The OPAQUE Asymmetric PAKE Protocol</title> that was replaced by draft-irtf-cfrg-opaque, which became the
<author> current document. Would it be helpful to the reader to make this
<organization/> more clear in the text of the document?
</author>
<date>n.d.</date> Current (Section 10.1):
</front> The specification as written here differs from the original
</reference> cryptographic design in [JKX18] and the corresponding CFRG document
[Krawczyk20], both of which were used as input to the CFRG PAKE
competition.
where in Section 12.2:
[Krawczyk20]
Krawczyk, H., "The OPAQUE Asymmetric PAKE Protocol", Work
in Progress, Internet-Draft, draft-krawczyk-cfrg-opaque-
06, 19 June 2020, <https://datatracker.ietf.org/doc/html/
draft-krawczyk-cfrg-opaque-06>.
b) It appears that [JKX18Full] and [JKX16] are different versions of the same
paper. There are instances in the text where it seems like the text is
referring to info from [JKX18Full] but cited [JKX16]. Would it be simpler if
only the full version of the paper [JKX18Full] is referenced?
c) The original date for this reference was 2016. However, the date provided
for the blog post is 27 July 2013. We have updated the reference to match this
date. Please let us know if you prefer otherwise.
Original:
[TripleDH] "Simplifying OTR deniability",
https://signal.org/blog/simplifying-otr-deniability ,
2016.
Current:
[TripleDH] Marlinspike, M., "Simplifying OTR deniability", Signal
Blog, 27 July 2013,
<https://signal.org/blog/simplifying-otr-deniability>.
d) Please review the following reference. NIST FIPS 186-4 has been withdrawn
and replaced by NIST FIPS 186-5. Would you like to update this reference to
use the most current version?
Current:
[NISTCurves]
NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-4,
DOI 10.6028/nist.fips.186-4, 2013,
<https://doi.org/10.6028/nist.fips.186-4>.
Perhaps:
[NISTCurves]
NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5,
DOI 10.6028/nist.fips.186-5, 2013,
<https://doi.org/10.6028/nist.fips.186-5>.
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draft-kr
awczyk-cfrg-opaque-06.xml"/>
<reference anchor="Boyen09"> <reference anchor="Boyen09">
<front> <front>
<title>HPAKE: Password Authentication Secure against Cross-Site User Impersonation</title> <title>HPAKE: Password Authentication Secure against Cross-Site User Impersonation</title>
<author initials="X." surname="Boyen" fullname="Xavier Boyen"> <author initials="X." surname="Boyen" fullname="Xavier Boyen">
<organization/> <organization/>
</author> </author>
<date year="2009"/> <date year="2009"/>
</front> </front>
<seriesInfo name="Cryptology and Network Security (CANS)" value=""/> <refcontent>Cryptology and Network Security (CANS 2009), Lecture Notes
in Computer Science, vol. 5888, pp. 279-298</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-642-10433-6_19"/>
</reference> </reference>
<reference anchor="BG04">
<reference anchor="BG04" target="https://eprint.iacr.org/2004/306">
<front> <front>
<title>The static Diffie-Hellman problem</title> <title>The Static Diffie-Hellman Problem</title>
<author initials="D." surname="Brown" fullname="Daniel R. L. Brown"> <author initials="D." surname="Brown" fullname="Daniel R. L. Brown">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Galant" fullname="Robert P. Galant"> <author initials="R." surname="Galant" fullname="Robert P. Galant">
<organization/> <organization/>
</author> </author>
<date year="2004"/> <date year="2004"/>
</front> </front>
<seriesInfo name="http://eprint.iacr.org/2004/306" value=""/> <refcontent>Cryptology ePrint Archive, Paper 2004/306</refcontent>
</reference> </reference>
<reference anchor="Canetti01">
<reference anchor="Canetti01">
<front> <front>
<title>Universally composable security: A new paradigm for cryptogra phic protocols</title> <title>Universally composable security: A new paradigm for cryptogra phic protocols</title>
<author initials="R." surname="Canetti" fullname="Ran Canetti"> <author initials="R." surname="Canetti" fullname="Ran Canetti">
<organization/> <organization/>
</author> </author>
<date year="2001"/> <date year="2001"/>
</front> </front>
<seriesInfo name="IEEE Symposium on Foundations of Computer Science (F <seriesInfo name="DOI" value="10.1109/SFCS.2001.959888"/>
OCS)" value=""/> <refcontent>42nd IEEE Symposium on Foundations of Computer Science, pp
. 136-145</refcontent>
</reference> </reference>
<reference anchor="Cheon06"> <reference anchor="Cheon06">
<front> <front>
<title>Security analysis of the strong Diffie-Hellman problem</title > <title>Security Analysis of the Strong Diffie-Hellman Problem</title >
<author initials="J. H." surname="Cheon" fullname="Jung Hee Cheon"> <author initials="J. H." surname="Cheon" fullname="Jung Hee Cheon">
<organization/> <organization/>
</author> </author>
<date year="2006"/> <date year="2006"/>
</front> </front>
<seriesInfo name="Eurocrypt" value=""/> <refcontent>Advances in Cryptology - EUROCRYPT 2006, Lecture Notes in
Computer Science, vol. 4004, pp. 1-11</refcontent>
<seriesInfo name="DOI" value="10.1007/11761679_1"/>
</reference> </reference>
<reference anchor="DL24">
<reference anchor="DL24" target="https://eprint.iacr.org/2024/756">
<front> <front>
<title>(Strong) aPAKE Revisited: Capturing Multi-User Security and S alting</title> <title>(Strong) aPAKE Revisited: Capturing Multi-User Security and S alting</title>
<author initials="D." surname="Dayanikli" fullname="Dennis Dayanikli "> <author initials="D." surname="Dayanikli" fullname="Dennis Dayanikli ">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Lehmann" fullname="Anja Lehmann"> <author initials="A." surname="Lehmann" fullname="Anja Lehmann">
<organization/> <organization/>
</author> </author>
<date year="2024"/> <date year="2024"/>
</front> </front>
<seriesInfo name="https://eprint.iacr.org/2024/756" value=""/> <refcontent>Cryptology ePrint Archive, Paper 2024/756</refcontent>
</reference> </reference>
<reference anchor="FK00"> <reference anchor="FK00">
<front> <front>
<title>Server-assisted generation of a strong secret from a password </title> <title>Server-assisted generation of a strong secret from a password </title>
<author initials="W." surname="Ford" fullname="Warwick Ford"> <author initials="W." surname="Ford" fullname="Warwick Ford">
<organization/> <organization/>
</author> </author>
<author initials="B. S." surname="Kaliski, Jr" fullname="Burton S. K aliski, Jr"> <author initials="B. S." surname="Kaliski, Jr" fullname="Burton S. K aliski, Jr">
<organization/> <organization/>
</author> </author>
<date year="2000"/> <date year="2000"/>
</front> </front>
<seriesInfo name="WETICE" value=""/> <refcontent>IEEE 9th International Workshops on Enabling Technologies:
Infrastructure for Collaborative Enterprises (WET ICE 2000), pp. 176-180</refco
ntent>
<seriesInfo name="DOI" value="10.1109/ENABL.2000.883724"/>
</reference> </reference>
<reference anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/FI PS/NIST.FIPS.202.pdf"> <reference anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/FI PS/NIST.FIPS.202.pdf">
<front> <front>
<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title> <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
<author> <author>
<organization>National Institute of Standards and Technology (NIST )</organization> <organization>NIST</organization>
</author> </author>
<date year="2015" month="August"/> <date year="2015" month="August"/>
</front> </front>
<seriesInfo name="NIST FIPS" value="202"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
</reference> </reference>
<reference anchor="HJKW23"> <reference anchor="HJKW23">
<front> <front>
<title>Password-Authenticated TLS via OPAQUE and Post-Handshake Auth entication</title> <title>Password-Authenticated TLS via OPAQUE and Post-Handshake Auth entication</title>
<author initials="J." surname="Hesse" fullname="Julia Hesse"> <author initials="J." surname="Hesse" fullname="Julia Hesse">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Jarecki" fullname="Stanislaw Jarecki" > <author initials="S." surname="Jarecki" fullname="Stanislaw Jarecki" >
<organization/> <organization/>
</author> </author>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk"> <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization/> <organization/>
</author> </author>
<author initials="C." surname="Wood" fullname="Christopher Wood"> <author initials="C." surname="Wood" fullname="Christopher Wood">
<organization/> <organization/>
</author> </author>
<date year="2023"/> <date year="2023"/>
</front> </front>
<seriesInfo name="EUROCRYPT" value=""/> <refcontent>Advances in Cryptology – EUROCRYPT 2023, Lecture Notes in
Computer Science, vol. 14008, pp. 98-127</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-031-30589-4_4"/>
</reference> </reference>
<reference anchor="keyagreement"> <reference anchor="keyagreement">
<front> <front>
<title>Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography</title> <title>Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography</title>
<author fullname="Elaine Barker" initials="E." surname="Barker"> <author fullname="Elaine Barker" initials="E." surname="Barker">
<organization/> <organization/>
</author> </author>
<author fullname="Lily Chen" initials="L." surname="Chen"> <author fullname="Lily Chen" initials="L." surname="Chen">
<organization/> <organization/>
</author> </author>
<author fullname="Allen Roginsky" initials="A." surname="Roginsky"> <author fullname="Allen Roginsky" initials="A." surname="Roginsky">
<organization/> <organization/>
</author> </author>
<author fullname="Apostol Vassilev" initials="A." surname="Vassilev" > <author fullname="Apostol Vassilev" initials="A." surname="Vassilev" >
<organization/> <organization/>
</author> </author>
<author fullname="Richard Davis" initials="R." surname="Davis"> <author fullname="Richard Davis" initials="R." surname="Davis">
<organization/> <organization/>
</author> </author>
<date month="April" year="2018"/> <date month="April" year="2018"/>
</front> </front>
<seriesInfo name="DOI" value="10.6028/nist.sp.800-56ar3"/> <seriesInfo name="DOI" value="10.6028/nist.sp.800-56ar3"/>
<refcontent>National Institute of Standards and Technology</refcontent > <seriesInfo name="NIST SP" value="800-56Ar3"/>
</reference> </reference>
<reference anchor="JKX18"> <reference anchor="JKX18">
<front> <front>
<title>OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Comput ation Attacks</title> <title>OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Comput ation Attacks</title>
<author initials="S." surname="Jarecki" fullname="Stanislaw Jarecki" > <author initials="S." surname="Jarecki" fullname="Stanislaw Jarecki" >
<organization/> <organization/>
</author> </author>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk"> <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Xu" fullname="Jiayu Xu"> <author initials="J." surname="Xu" fullname="Jiayu Xu">
<organization/> <organization/>
</author> </author>
<date year="2018"/> <date year="2018"/>
</front> </front>
<seriesInfo name="Eurocrypt" value=""/> <refcontent>Advances in Cryptology – EUROCRYPT 2018, Lecture Notes in
Computer Science, vol. 10822, pp. 456-486</refcontent>
<seriesInfo name="DOI" value="10.1007/978-3-319-78372-7_15"/>
</reference> </reference>
<reference anchor="JKX18Full">
<reference anchor="JKX18Full" target="https://eprint.iacr.org/2018/163">
<front> <front>
<title>OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Comput ation Attacks (Full Version)</title> <title>OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Comput ation Attacks</title>
<author initials="S." surname="Jarecki" fullname="Stanislaw Jarecki" > <author initials="S." surname="Jarecki" fullname="Stanislaw Jarecki" >
<organization/> <organization/>
</author> </author>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk"> <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Xu" fullname="Jiayu Xu"> <author initials="J." surname="Xu" fullname="Jiayu Xu">
<organization/> <organization/>
</author> </author>
<date year="2018"/> <date year="2018"/>
</front> </front>
<seriesInfo name="https://eprint.iacr.org/2018/163" value=""/> <refcontent>Cryptology ePrint Archive, Paper 2018/163</refcontent>
</reference> </reference>
<reference anchor="JKKX16"> <reference anchor="JKKX16">
<front> <front>
<title>Highly-efficient and composable password-protected secret sha ring (or: how to protect your bitcoin wallet online)</title> <title>Highly-Efficient and Composable Password-Protected Secret Sha ring (Or: How to Protect Your Bitcoin Wallet Online)</title>
<author initials="S." surname="Jarecki" fullname="Stanislaw Jarecki" > <author initials="S." surname="Jarecki" fullname="Stanislaw Jarecki" >
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Kiayias" fullname="Aggelos Kiayias"> <author initials="A." surname="Kiayias" fullname="Aggelos Kiayias">
<organization/> <organization/>
</author> </author>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk"> <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Xu" fullname="Jiayu Xu"> <author initials="J." surname="Xu" fullname="Jiayu Xu">
<organization/> <organization/>
</author> </author>
<date year="2016"/> <date year="2016"/>
</front> </front>
<seriesInfo name="IEEE European Symposium on Security and Privacy" val <refcontent>2016 IEEE European Symposium on Security and Privacy (Euro
ue=""/> S&amp;P), pp. 276-291</refcontent>
<seriesInfo name="DOI" value="10.1109/EuroSP.2016.30"/>
</reference> </reference>
<reference anchor="LGR20" target="https://eprint.iacr.org/2020/1491.pdf" > <reference anchor="LGR20" target="https://eprint.iacr.org/2020/1491.pdf" >
<front> <front>
<title>Partitioning Oracle Attacks</title> <title>Partitioning Oracle Attacks</title>
<author initials="J." surname="Len" fullname="Julia Len"> <author initials="J." surname="Len" fullname="Julia Len">
<organization/> <organization/>
</author> </author>
<author initials="P." surname="Grubbs" fullname="Paul Grubbs"> <author initials="P." surname="Grubbs" fullname="Paul Grubbs">
<organization/> <organization/>
</author> </author>
<author initials="T." surname="Ristenpart" fullname="Thomas Ristenpa rt"> <author initials="T." surname="Ristenpart" fullname="Thomas Ristenpa rt">
<organization/> <organization/>
</author> </author>
<date>n.d.</date> <date year="2021"/>
</front> </front>
<refcontent>Cryptology ePrint Archive, Paper 2020/1491</refcontent>
</reference> </reference>
<reference anchor="HMQV">
<reference anchor="HMQV" target="https://eprint.iacr.org/2005/176">
<front> <front>
<title>HMQV: A high-performance secure Diffie-Hellman protocol</titl e> <title>HMQV: A High-Performance Secure Diffie-Hellman Protocol</titl e>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk"> <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization/> <organization/>
</author> </author>
<date year="2005"/> <date year="2005"/>
</front> </front>
<seriesInfo name="CRYPTO" value=""/> <refcontent>Cryptology ePrint Archive, Paper 2005/176</refcontent>
</reference> </reference>
<reference anchor="SIGMA-I">
<reference anchor="SIGMA-I" target="https://www.iacr.org/cryptodb/archiv
e/2003/CRYPTO/1495/1495.pdf">
<front> <front>
<title>SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-He llman and its Use in the IKE Protocols</title> <title>SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-He llman and its Use in the IKE Protocols</title>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk"> <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization/> <organization/>
</author> </author>
<date year="2003"/> <date year="2003"/>
</front> </front>
<seriesInfo name="https://www.iacr.org/cryptodb/archive/2003/CRYPTO/14 95/1495.pdf" value=""/>
</reference> </reference>
<reference anchor="TripleDH">
<reference anchor="TripleDH" target="https://signal.org/blog/simplifying
-otr-deniability">
<front> <front>
<title>Simplifying OTR deniability</title> <title>Simplifying OTR deniability</title>
<author> <author fullname="Moxie Marlinspike">
<organization/> <organization/>
</author> </author>
<date year="2016"/> <date day="27" month="July" year="2013"/>
</front> </front>
<seriesInfo name="https://signal.org/blog/simplifying-otr-deniability" value=""/> <refcontent>Signal Blog</refcontent>
</reference> </reference>
<reference anchor="WhatsAppE2E" target="https://www.whatsapp.com/securit y/WhatsApp_Security_Encrypted_Backups_Whitepaper.pdf"> <reference anchor="WhatsAppE2E" target="https://www.whatsapp.com/securit y/WhatsApp_Security_Encrypted_Backups_Whitepaper.pdf">
<front> <front>
<title>Security of End-to-End Encrypted Backups</title> <title>Security of End-to-End Encrypted Backups</title>
<author initials="" surname="WhatsApp" fullname="WhatsApp"> <author>
<organization/> <organization>WhatsApp</organization>
</author> </author>
<date>n.d.</date> <date day="10" month="September" year="2021"/>
</front> </front>
<refcontent>WhatsApp Security Whitepaper</refcontent>
</reference> </reference>
<reference anchor="TOPPSS"> <reference anchor="TOPPSS">
<front> <front>
<title>TOPPSS: Cost-minimal Password-Protected Secret Sharing based on Threshold OPRF</title> <title>TOPPSS: Cost-Minimal Password-Protected Secret Sharing based on Threshold OPRF</title>
<author initials="S." surname="Jarecki" fullname="Stanislaw Jarecki" > <author initials="S." surname="Jarecki" fullname="Stanislaw Jarecki" >
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Kiayias" fullname="Aggelos Kiayias"> <author initials="A." surname="Kiayias" fullname="Aggelos Kiayias">
<organization/> <organization/>
</author> </author>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk"> <author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization/> <organization/>
</author> </author>
<author initials="J." surname="Xu" fullname="Jiayu Xu"> <author initials="J." surname="Xu" fullname="Jiayu Xu">
<organization/> <organization/>
</author> </author>
<date year="2017"/> <date year="2017"/>
</front> </front>
<seriesInfo name="Applied Cryptology and Network Security - ACNS 2017" <seriesInfo name="DOI" value="10.1007/978-3-319-61204-1_3"/>
value=""/> <refcontent>Applied Cryptology and Network Security - ACNS 2017, Lectu
</reference> re Notes in Computer Science, vol. 10355, pp. 39-58</refcontent>
<reference anchor="RFC5869">
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)<
/title>
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<date month="May" year="2010"/>
<abstract>
<t>This document specifies a simple Hashed Message Authentication
Code (HMAC)-based key derivation function (HKDF), which can be used as a buildin
g block in various protocols and applications. The key derivation function (KDF)
is intended to support a wide range of applications and requirements, and is co
nservative in its use of cryptographic hash functions. This document is not an I
nternet Standards Track specification; it is published for informational purpose
s.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5869"/>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>
<reference anchor="RFC8125">
<front>
<title>Requirements for Password-Authenticated Key Agreement (PAKE)
Schemes</title>
<author fullname="J. Schmidt" initials="J." surname="Schmidt"/>
<date month="April" year="2017"/>
<abstract>
<t>Password-Authenticated Key Agreement (PAKE) schemes are interac
tive protocols that allow the participants to authenticate each other and derive
shared cryptographic keys using a (weaker) shared password. This document revie
ws different types of PAKE schemes. Furthermore, it presents requirements and gi
ves recommendations to designers of new schemes. It is a product of the Crypto F
orum Research Group (CFRG).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8125"/>
<seriesInfo name="DOI" value="10.17487/RFC8125"/>
</reference>
<reference anchor="RFC8017">
<front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<author fullname="K. Moriarty" initials="K." role="editor" surname="
Moriarty"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
<author fullname="A. Rusch" initials="A." surname="Rusch"/>
<date month="November" year="2016"/>
<abstract>
<t>This document provides recommendations for the implementation o
f public-key cryptography based on the RSA algorithm, covering cryptographic pri
mitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax f
or representing keys and for identifying the schemes.</t>
<t>This document represents a republication of PKCS #1 v2.2 from R
SA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing
this RFC, change control is transferred to the IETF.</t>
<t>This document also obsoletes RFC 3447.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8017"/>
<seriesInfo name="DOI" value="10.17487/RFC8017"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference> </reference>
<reference anchor="RISTRETTO">
<front>
<title>The ristretto255 and decaf448 Groups</title>
<author fullname="Henry de Valence" initials="H." surname="de Valenc
e">
</author>
<author fullname="Jack Grigg" initials="J." surname="Grigg">
</author>
<author fullname="Mike Hamburg" initials="M." surname="Hamburg">
</author>
<author fullname="Isis Lovecruft" initials="I." surname="Lovecruft">
</author>
<author fullname="George Tankersley" initials="G." surname="Tankersl
ey">
</author>
<author fullname="Filippo Valsorda" initials="F." surname="Valsorda"
>
</author>
<date day="5" month="September" year="2023"/>
<abstract>
<t> This memo specifies two prime-order groups, ristretto255 and
decaf448, suitable for safely implementing higher-level and complex
cryptographic protocols. The ristretto255 group can be implemented
using Curve25519, allowing existing Curve25519 implementations to be
reused and extended to provide a prime-order group. Likewise, the
decaf448 group can be implemented using edwards448.
This document is a product of the Crypto Forum Research Group (CFRG) <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
in the IRTF. 869.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
125.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
017.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
496.xml"/>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-ristretto255-
decaf448-08"/>
</reference>
<reference anchor="NISTCurves"> <reference anchor="NISTCurves">
<front> <front>
<title>Digital signature standard (DSS)</title> <title>Digital Signature Standard (DSS)</title>
<author> <author>
<organization/> <organization>NIST</organization>
</author> </author>
<date year="2013"/> <date year="2013"/>
</front> </front>
<seriesInfo name="NIST FIPS" value="186-4"/>
<seriesInfo name="DOI" value="10.6028/nist.fips.186-4"/> <seriesInfo name="DOI" value="10.6028/nist.fips.186-4"/>
<refcontent>National Institute of Standards and Technology (U.S.)</ref content>
</reference> </reference>
<reference anchor="Curve25519">
<front> <!-- Note to PE: XML for most current version of [NISTCurves]
<title>Elliptic Curves for Security</title>
<author fullname="A. Langley" initials="A." surname="Langley"/> <reference anchor="NISTCurves">
<author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="January" year="2016"/>
<abstract>
<t>This memo specifies two elliptic curves over prime fields that
offer a high level of practical security in cryptographic applications, includin
g Transport Layer Security (TLS). These curves are intended to operate at the ~1
28-bit and ~224-bit security level, respectively, and are generated deterministi
cally based on a list of required properties.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7748"/>
<seriesInfo name="DOI" value="10.17487/RFC7748"/>
</reference>
<reference anchor="ARGON2">
<front>
<title>Argon2 Memory-Hard Function for Password Hashing and Proof-of
-Work Applications</title>
<author fullname="A. Biryukov" initials="A." surname="Biryukov"/>
<author fullname="D. Dinu" initials="D." surname="Dinu"/>
<author fullname="D. Khovratovich" initials="D." surname="Khovratovi
ch"/>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="September" year="2021"/>
<abstract>
<t>This document describes the Argon2 memory-hard function for pas
sword hashing and proof-of-work applications. We provide an implementer-oriented
description with test vectors. The purpose is to simplify adoption of Argon2 fo
r Internet protocols. This document is a product of the Crypto Forum Research Gr
oup (CFRG) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9106"/>
<seriesInfo name="DOI" value="10.17487/RFC9106"/>
</reference>
<reference anchor="SCRYPT">
<front>
<title>The scrypt Password-Based Key Derivation Function</title>
<author fullname="C. Percival" initials="C." surname="Percival"/>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="August" year="2016"/>
<abstract>
<t>This document specifies the password-based key derivation funct
ion scrypt. The function derives one or more secret keys from a secret string. I
t is based on memory-hard functions, which offer added protection against attack
s using custom hardware. The document also provides an ASN.1 schema.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7914"/>
<seriesInfo name="DOI" value="10.17487/RFC7914"/>
</reference>
<reference anchor="PBKDF2">
<front>
<title>PKCS #5: Password-Based Cryptography Specification Version 2.
1</title>
<author fullname="K. Moriarty" initials="K." role="editor" surname="
Moriarty"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<author fullname="A. Rusch" initials="A." surname="Rusch"/>
<date month="January" year="2017"/>
<abstract>
<t>This document provides recommendations for the implementation o
f password-based cryptography, covering key derivation functions, encryption sch
emes, message authentication schemes, and ASN.1 syntax identifying the technique
s.</t>
<t>This document represents a republication of PKCS #5 v2.1 from R
SA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing
this RFC, change control is transferred to the IETF.</t>
<t>This document also obsoletes RFC 2898.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8018"/>
<seriesInfo name="DOI" value="10.17487/RFC8018"/>
</reference>
<reference anchor="RFC9380">
<front>
<title>Hashing to Elliptic Curves</title>
<author fullname="A. Faz-Hernandez" initials="A." surname="Faz-Herna
ndez"/>
<author fullname="S. Scott" initials="S." surname="Scott"/>
<author fullname="N. Sullivan" initials="N." surname="Sullivan"/>
<author fullname="R. S. Wahby" initials="R. S." surname="Wahby"/>
<author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
<date month="August" year="2023"/>
<abstract>
<t>This document specifies a number of algorithms for encoding or
hashing an arbitrary string to a point on an elliptic curve. This document is a
product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9380"/>
<seriesInfo name="DOI" value="10.17487/RFC9380"/>
</reference>
<reference anchor="RFC9180">
<front> <front>
<title>Hybrid Public Key Encryption</title> <title>Digital Signature Standard (DSS)</title>
<author fullname="R. Barnes" initials="R." surname="Barnes"/> <author>
<author fullname="K. Bhargavan" initials="K." surname="Bhargavan"/> <organization>NIST</organization>
<author fullname="B. Lipp" initials="B." surname="Lipp"/> </author>
<author fullname="C. Wood" initials="C." surname="Wood"/> <date year="2013"/>
<date month="February" year="2022"/>
<abstract>
<t>This document describes a scheme for hybrid public key encrypti
on (HPKE). This scheme provides a variant of public key encryption of arbitrary-
sized plaintexts for a recipient public key. It also includes three authenticate
d variants, including one that authenticates possession of a pre-shared key and
two optional ones that authenticate possession of a key encapsulation mechanism
(KEM) private key. HPKE works for any combination of an asymmetric KEM, key deri
vation function (KDF), and authenticated encryption with additional data (AEAD)
encryption function. Some authenticated variants may not be supported by all KEM
s. We provide instantiations of the scheme using widely used and efficient primi
tives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based ke
y derivation function (HKDF), and SHA2.</t>
<t>This document is a product of the Crypto Forum Research Group (
CFRG) in the IRTF.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9180"/> <seriesInfo name="NIST FIPS" value="186-5"/>
<seriesInfo name="DOI" value="10.17487/RFC9180"/> <seriesInfo name="DOI" value="10.6028/nist.fips.186-5"/>
</reference> </reference>
-->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
748.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
106.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
914.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
018.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
380.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
180.xml"/>
</references> </references>
</references> </references>
<?line 2425?>
<section anchor="acknowledgments">
<name>Acknowledgments</name>
<t>We are indebted to the OPAQUE reviewers during CFRG's
aPAKE selection process, particularly Julia Hesse and Bjorn Tackmann.
This draft has benefited from comments by multiple people. Special thanks
to Richard Barnes, Dan Brown, Matt Campagna, Eric Crockett, Paul Grubbs,
Fredrik Kuivinen, Stefan Marsiske, Payman Mohassel, Marta Mularczyk,
Jason Resch, Greg Rubin, and Nick Sullivan. Hugo Krawczyk wishes to thank
his OPAQUE co-authors Stas Jarecki and Jiayu Xu without whom this work
would have not been possible.</t>
</section>
<section anchor="alternate-key-recovery"> <section anchor="alternate-key-recovery">
<name>Alternate Key Recovery Mechanisms</name> <name>Alternate Key Recovery Mechanisms</name>
<t>Client authentication material can be stored and retrieved using differ ent key <t>Client authentication material can be stored and retrieved using differ ent key
recovery mechanisms. Any key recovery mechanism that encrypts data recovery mechanisms. Any key recovery mechanism that encrypts data
in the envelope MUST use an authenticated encryption scheme with random in the envelope <bcp14>MUST</bcp14> use an authenticated encryption scheme with random
key-robustness (or key-committing). Deviating from the key-robustness key-robustness (or key-committing). Deviating from the key-robustness
requirement may open the protocol to attacks, e.g., <xref target="LGR20"/>. requirement may open the protocol to attacks, e.g., <xref target="LGR20"/>.
This specification enforces this property by using a MAC over the envelope This specification enforces this property by using a MAC over the envelope
contents.</t> contents.</t>
<t>We remark that export_key for authentication or encryption requires <t>We remark that export_key for authentication or encryption requires
no special properties from the authentication or encryption schemes no special properties from the authentication or encryption schemes
as long as export_key is used only after authentication material is successfully as long as export_key is used only after authentication material is successfully
recovered, i.e., after the MAC in RecoverCredentials passes verification.</t> recovered, i.e., after the MAC in RecoverCredentials passes verification.</t>
</section> </section>
<section anchor="alternate-akes"> <section anchor="alternate-akes">
<name>Alternate AKE Instantiations</name> <name>Alternate AKE Instantiations</name>
<t>It is possible to instantiate OPAQUE with other AKEs, such as HMQV <xre f target="HMQV"/> and <xref target="SIGMA-I"/>. <t>It is possible to instantiate OPAQUE with other AKEs, such as HMQV <xre f target="HMQV"/> and SIGMA-I <xref target="SIGMA-I"/>.
HMQV is similar to 3DH but varies in its key schedule. SIGMA-I uses digital sign atures HMQV is similar to 3DH but varies in its key schedule. SIGMA-I uses digital sign atures
rather than static DH keys for authentication. Specification of these instantiat ions is rather than static DH keys for authentication. Specification of these instantiat ions is
left to future documents. A sketch of how these instantiations might change is i ncluded left to future documents. A sketch of how these instantiations might change is i ncluded
in the next subsection for posterity.</t> in the next subsection for posterity.</t>
<t>OPAQUE may also be instantiated with any post-quantum (PQ) AKE protocol that has the message <t>OPAQUE may also be instantiated with any post-quantum (PQ) AKE protocol that has the message
flow above and security properties (KCI resistance and forward secrecy) outlined flow above and security properties (KCI resistance and forward secrecy) outlined
in <xref target="security-considerations"/>. Note that such an instantiation is not quantum-safe unless in <xref target="security-considerations"/>. Note that such an instantiation is not quantum-safe unless
the OPRF is quantum-safe. However, an OPAQUE instantiation where the AKE is quan tum-safe, the OPRF is quantum-safe. However, an OPAQUE instantiation where the AKE is quan tum-safe,
but the OPRF is not, would still ensure the confidentiality and integrity of app lication data encrypted but the OPRF is not, would still ensure the confidentiality and integrity of app lication data encrypted
under session_key (or a key derived from it) with a quantum-safe encryption func tion. under session_key (or a key derived from it) with a quantum-safe encryption func tion.
However, the only effect of a break of the OPRF by a future quantum attacker wou ld be However, the only effect of a break of the OPRF by a future quantum attacker wou ld be
the ability of this attacker to run at that time an exhaustive dictionary the ability of this attacker to run at that time an exhaustive dictionary
attack against the old user's password and only for users whose envelopes were attack against the old user's password and only for users whose envelopes were
harvested while in use (in the case of OPAQUE run over a TLS channel with the harvested while in use (in the case of OPAQUE run over a TLS channel with the
server, harvesting such envelopes requires targeted active attacks).</t> server, harvesting such envelopes requires targeted active attacks).</t>
<section anchor="hmqv-sketch"> <section anchor="hmqv-sketch">
<name>HMQV Instantiation Sketch</name> <name>HMQV Instantiation Sketch</name>
<t>An HMQV instantiation would work similarly to OPAQUE-3DH, differing p rimarily in the key <t>An HMQV instantiation would work similarly to OPAQUE-3DH, differing p rimarily in the key
schedule <xref target="HMQV"/>. First, the key schedule <tt>preamble</tt> value would use a different constant prefix schedule <xref target="HMQV"/>. First, the key schedule <tt>preamble</tt> value would use a different constant prefix
-- "HMQV" instead of "3DH" -- as shown below.</t> -- "HMQV" instead of "3DH" -- as shown below.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
preamble = concat("HMQV", preamble = concat("HMQV",
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,
KE2.credential_response, KE2.credential_response,
KE2.auth_response.server_nonce, KE2.auth_response.server_nonce,
KE2.auth_response.server_public_keyshare) KE2.auth_response.server_public_keyshare)
]]></artwork> ]]></sourcecode>
<t>Second, the IKM derivation would change. Assuming HMQV is instantiate d with a cyclic <t>Second, the IKM derivation would change. Assuming HMQV is instantiate d with a cyclic
group of prime order p with bit length L, clients would compute <tt>IKM</tt> as follows:</t> group of prime order p with bit length L, clients would compute <tt>IKM</tt> as follows:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
u' = (eskU + u \* skU) mod p u' = (eskU + u \* skU) mod p
IKM = (epkS \* pkS^s)^u' IKM = (epkS \* pkS^s)^u'
]]></artwork> ]]></sourcecode>
<t>Likewise, servers would compute <tt>IKM</tt> as follows:</t> <t>Likewise, servers would compute <tt>IKM</tt> as follows:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
s' = (eskS + s \* skS) mod p s' = (eskS + s \* skS) mod p
IKM = (epkU \* pkU^u)^s' IKM = (epkU \* pkU^u)^s'
]]></artwork> ]]></sourcecode>
<t>In both cases, <tt>u</tt> would be computed as follows:</t> <t>In both cases, <tt>u</tt> would be computed as follows:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
hashInput = concat(I2OSP(len(epkU), 2), epkU, hashInput = concat(I2OSP(len(epkU), 2), epkU,
I2OSP(len(info), 2), info, I2OSP(len(info), 2), info,
I2OSP(len("client"), 2), "client") I2OSP(len("client"), 2), "client")
u = Hash(hashInput) mod L u = Hash(hashInput) mod L
]]></artwork> ]]></sourcecode>
<t>Likewise, <tt>s</tt> would be computed as follows:</t> <t>Likewise, <tt>s</tt> would be computed as follows:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
hashInput = concat(I2OSP(len(epkS), 2), epkS, hashInput = concat(I2OSP(len(epkS), 2), epkS,
I2OSP(len(info), 2), info, I2OSP(len(info), 2), info,
I2OSP(len("server"), 2), "server") I2OSP(len("server"), 2), "server")
s = Hash(hashInput) mod L s = Hash(hashInput) mod L
]]></artwork> ]]></sourcecode>
<t>Hash is the same hash function used in the main OPAQUE protocol for k ey derivation. <t>Hash is the same hash function used in the main OPAQUE protocol for k ey derivation.
Its output length (in bits) must be at least L.</t> Its output length (in bits) must be at least L.</t>
<t>Both parties should perform validation (as in <xref target="validatio n"/>) on each other's <t>Both parties should perform validation (as in <xref target="validatio n"/>) on each other's
public keys before computing the above parameters.</t> public keys before computing the above parameters.</t>
</section> </section>
<section anchor="sigma-i-instantiation-sketch"> <section anchor="sigma-i-instantiation-sketch">
<name>SIGMA-I Instantiation Sketch</name> <name>SIGMA-I Instantiation Sketch</name>
<t>A <xref target="SIGMA-I"/> instantiation differs more drastically fro m OPAQUE-3DH since authentication <t>A SIGMA-I <xref target="SIGMA-I"/> instantiation differs more drastic ally from OPAQUE-3DH since authentication
uses digital signatures instead of Diffie-Hellman. In particular, both KE2 and K E3 uses digital signatures instead of Diffie-Hellman. In particular, both KE2 and K E3
would carry a digital signature, computed using the server and client private ke ys would carry a digital signature, computed using the server and client private ke ys
established during registration, respectively, as well as a MAC, where the MAC i s established during registration, respectively, as well as a MAC, where the MAC i s
computed as in OPAQUE-3DH but it also covers the identity of the sender.</t> computed as in OPAQUE-3DH but it also covers the identity of the sender.</t>
<t>The key schedule would also change. Specifically, the key schedule <t t>preamble</tt> value would <t>The key schedule would also change. Specifically, the key schedule <t t>preamble</tt> value would
use a different constant prefix -- "SIGMA-I" instead of "3DH" -- and the <tt>IKM </tt> computation use a different constant prefix -- "SIGMA-I" instead of "3DH" -- and the <tt>IKM </tt> computation
would use only the ephemeral public keys exchanged between client and server.</t > would use only the ephemeral public keys exchanged between client and server.</t >
</section> </section>
</section> </section>
<section anchor="test-vectors"> <section anchor="test-vectors">
<name>Test Vectors</name> <name>Test Vectors</name>
<t>This section contains real and fake test vectors for the OPAQUE-3DH spe cification. <t>This section contains real and fake test vectors for the OPAQUE-3DH spe cification.
Each real test vector in <xref target="real-vectors"/> specifies the configurati on information, Each real test vector in <xref target="real-vectors"/> specifies the configurati on information,
protocol inputs, intermediate values computed during registration and authentica tion, protocol inputs, intermediate values computed during registration and authentica tion,
and protocol outputs.</t> and protocol outputs.</t>
<t>Similarly, each fake test vector in <xref target="fake-vectors"/> speci fies <t>Similarly, each fake test vector in <xref target="fake-vectors"/> speci fies
the configuration information, protocol inputs, and protocol the configuration information, protocol inputs, and protocol
outputs computed during the authentication of an unknown or unregistered user. N ote that <tt>masking_key</tt>, outputs computed during the authentication of an unknown or unregistered user. N ote that <tt>masking_key</tt>,
<tt>client_private_key</tt>, and <tt>client_public_key</tt> are used as addition al inputs as described in <tt>client_private_key</tt>, and <tt>client_public_key</tt> are used as addition al inputs as described in
<xref target="create-credential-response"/>. <tt>client_public_key</tt> is used as the fake record's public key, and <xref target="create-credential-response"/>. <tt>client_public_key</tt> is used as the fake record's public key, and
<tt>masking_key</tt> for the fake record's masking key parameter.</t> <tt>masking_key</tt> is used for the fake record's masking key parameter.</t>
<t>All values are encoded in hexadecimal strings. The configuration inform ation <t>All values are encoded in hexadecimal strings. The configuration inform ation
includes the (OPRF, Hash, KSF, KDF, MAC, Group, Context) tuple, where the Group includes the (OPRF, Hash, KSF, KDF, MAC, Group, Context) tuple, where the Group
matches that which is used in the OPRF. The KSF used for each test vector is the matches that which is used in the OPRF. The KSF used for each test vector is the
identity function (denoted Identity), which returns as output the input message identity function (denoted Identity), which returns as output the input message
supplied to the function without any modification, i.e., msg = Stretch(msg).</t> supplied to the function without any modification, i.e., msg = Stretch(msg).</t>
<section anchor="real-vectors"> <section anchor="real-vectors">
<name>Real Test Vectors</name> <name>Real Test Vectors</name>
<section anchor="opaque-3dh-real-test-vector-1"> <section anchor="opaque-3dh-real-test-vector-1">
<name>OPAQUE-3DH Real Test Vector 1</name> <name>OPAQUE-3DH Real Test Vector 1</name>
<section anchor="configuration"> <section anchor="configuration">
<name>Configuration</name> <name>Configuration</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
OPRF: ristretto255-SHA512 OPRF: ristretto255-SHA512
Hash: SHA512 Hash: SHA512
KSF: Identity KSF: Identity
KDF: HKDF-SHA512 KDF: HKDF-SHA512
MAC: HMAC-SHA512 MAC: HMAC-SHA512
Group: ristretto255 Group: ristretto255
Context: 4f50415155452d504f43 Context: 4f50415155452d504f43
Nh: 64 Nh: 64
Npk: 32 Npk: 32
Nsk: 32 Nsk: 32
Nm: 64 Nm: 64
Nx: 64 Nx: 64
Nok: 32 Nok: 32
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="input-values"> <section anchor="input-values">
<name>Input Values</name> <name>Input Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
oprf_seed: f433d0227b0b9dd54f7c4422b600e764e47fb503f1f9a0f0a47c6606b0 oprf_seed: f433d0227b0b9dd54f7c4422b600e764e47fb503f1f9a0f0a47c6606b0
54a7fdc65347f1a08f277e22358bbabe26f823fca82c7848e9a75661f4ec5d5c1989e 54a7fdc65347f1a08f277e22358bbabe26f823fca82c7848e9a75661f4ec5d5c1989e
f f
credential_identifier: 31323334 credential_identifier: 31323334
password: 436f7272656374486f72736542617474657279537461706c65 password: 436f7272656374486f72736542617474657279537461706c65
envelope_nonce: ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d2 envelope_nonce: ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d2
3ba7a38dfec 3ba7a38dfec
masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80 masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80
f612fdfc6d f612fdfc6d
server_private_key: 47451a85372f8b3537e249d7b54188091fb18edde78094b43 server_private_key: 47451a85372f8b3537e249d7b54188091fb18edde78094b43
skipping to change at line 2997 skipping to change at line 3003
client_nonce: da7e07376d6d6f034cfa9bb537d11b8c6b4238c334333d1f0aebb38 client_nonce: da7e07376d6d6f034cfa9bb537d11b8c6b4238c334333d1f0aebb38
0cae6a6cc 0cae6a6cc
client_keyshare_seed: 82850a697b42a505f5b68fcdafce8c31f0af2b581f063cf client_keyshare_seed: 82850a697b42a505f5b68fcdafce8c31f0af2b581f063cf
1091933541936304b 1091933541936304b
server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a
1e85ff80da12f982f 1e85ff80da12f982f
blind_registration: 76cfbfe758db884bebb33582331ba9f159720ca8784a2a070 blind_registration: 76cfbfe758db884bebb33582331ba9f159720ca8784a2a070
a265d9c2d6abe01 a265d9c2d6abe01
blind_login: 6ecc102d2e7a7cf49617aad7bbe188556792d4acd60a1a8a8d2b65d4 blind_login: 6ecc102d2e7a7cf49617aad7bbe188556792d4acd60a1a8a8d2b65d4
b0790308 b0790308
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="intermediate-values"> <section anchor="intermediate-values">
<name>Intermediate Values</name> <name>Intermediate Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_public_key: 76a845464c68a5d2f7e442436bb1424953b17d3e2e289ccbac client_public_key: 76a845464c68a5d2f7e442436bb1424953b17d3e2e289ccbac
cafb57ac5c3675 cafb57ac5c3675
auth_key: 6cd32316f18d72a9a927a83199fa030663a38ce0c11fbaef82aa9003773 auth_key: 6cd32316f18d72a9a927a83199fa030663a38ce0c11fbaef82aa9003773
0494fc555c4d49506284516edd1628c27965b7555a4ebfed2223199f6c67966dde822 0494fc555c4d49506284516edd1628c27965b7555a4ebfed2223199f6c67966dde822
randomized_password: aac48c25ab036e30750839d31d6e73007344cb1155289fb7 randomized_password: aac48c25ab036e30750839d31d6e73007344cb1155289fb7
d329beb932e9adeea73d5d5c22a0ce1952f8aba6d66007615cd1698d4ac85ef1fcf15 d329beb932e9adeea73d5d5c22a0ce1952f8aba6d66007615cd1698d4ac85ef1fcf15
0031d1435d9 0031d1435d9
envelope: ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d23ba7a3 envelope: ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d23ba7a3
8dfec634b0f5b96109c198a8027da51854c35bee90d1e1c781806d07d49b76de6a28b 8dfec634b0f5b96109c198a8027da51854c35bee90d1e1c781806d07d49b76de6a28b
8d9e9b6c93b9f8b64d16dddd9c5bfb5fea48ee8fd2f75012a8b308605cdd8ba5 8d9e9b6c93b9f8b64d16dddd9c5bfb5fea48ee8fd2f75012a8b308605cdd8ba5
skipping to change at line 3023 skipping to change at line 3029
50ff528726332f1298fc6cc822a432c89504347c7a2ccd70316ae3da6a15e0399e6db 50ff528726332f1298fc6cc822a432c89504347c7a2ccd70316ae3da6a15e0399e6db
3f7c1b12 3f7c1b12
server_mac_key: 0d36b26cfe38f51f804f0a9361818f32ee1ce2a4e5578653b5271 server_mac_key: 0d36b26cfe38f51f804f0a9361818f32ee1ce2a4e5578653b5271
84af058d3b2d8075c296fd84d24677913d1baa109290cd81a13ed383f9091a3804e65 84af058d3b2d8075c296fd84d24677913d1baa109290cd81a13ed383f9091a3804e65
298dfc 298dfc
client_mac_key: 91750adbac54a5e8e53b4c233cc8d369fe83b0de1b6a3cd85575e client_mac_key: 91750adbac54a5e8e53b4c233cc8d369fe83b0de1b6a3cd85575e
eb0bb01a6a90a086a2cf5fe75fff2a9379c30ba9049510a33b5b0b1444a88800fc3ee eb0bb01a6a90a086a2cf5fe75fff2a9379c30ba9049510a33b5b0b1444a88800fc3ee
e2260d e2260d
oprf_key: 5d4c6a8b7c7138182afb4345d1fae6a9f18a1744afbcc3854f8f5a2b4b4 oprf_key: 5d4c6a8b7c7138182afb4345d1fae6a9f18a1744afbcc3854f8f5a2b4b4
c6d05 c6d05
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="output-values"> <section anchor="output-values">
<name>Output Values</name> <name>Output Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
registration_request: 5059ff249eb1551b7ce4991f3336205bde44a105a032e74 registration_request: 5059ff249eb1551b7ce4991f3336205bde44a105a032e74
7d21bf382e75f7a71 7d21bf382e75f7a71
registration_response: 7408a268083e03abc7097fc05b587834539065e86fb0c7 registration_response: 7408a268083e03abc7097fc05b587834539065e86fb0c7
b6342fcf5e01e5b019b2fe7af9f48cc502d016729d2fe25cdd433f2c4bc904660b2a3 b6342fcf5e01e5b019b2fe7af9f48cc502d016729d2fe25cdd433f2c4bc904660b2a3
82c9b79df1a78 82c9b79df1a78
registration_upload: 76a845464c68a5d2f7e442436bb1424953b17d3e2e289ccb registration_upload: 76a845464c68a5d2f7e442436bb1424953b17d3e2e289ccb
accafb57ac5c36751ac5844383c7708077dea41cbefe2fa15724f449e535dd7dd562e accafb57ac5c36751ac5844383c7708077dea41cbefe2fa15724f449e535dd7dd562e
66f5ecfb95864eadddec9db5874959905117dad40a4524111849799281fefe3c51fa8 66f5ecfb95864eadddec9db5874959905117dad40a4524111849799281fefe3c51fa8
2785c5ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d23ba7a38dfe 2785c5ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d23ba7a38dfe
c634b0f5b96109c198a8027da51854c35bee90d1e1c781806d07d49b76de6a28b8d9e c634b0f5b96109c198a8027da51854c35bee90d1e1c781806d07d49b76de6a28b8d9e
skipping to change at line 3060 skipping to change at line 3066
bc8b405d15bd6744945ba1a93438a162b6111699d98a16bb55b7bdddfe0fc5608b23d bc8b405d15bd6744945ba1a93438a162b6111699d98a16bb55b7bdddfe0fc5608b23d
a246e7bd73b47369169c5c90 a246e7bd73b47369169c5c90
KE3: 4455df4f810ac31a6748835888564b536e6da5d9944dfea9e34defb9575fe5e2 KE3: 4455df4f810ac31a6748835888564b536e6da5d9944dfea9e34defb9575fe5e2
661ef61d2ae3929bcf57e53d464113d364365eb7d1a57b629707ca48da18e442 661ef61d2ae3929bcf57e53d464113d364365eb7d1a57b629707ca48da18e442
export_key: 1ef15b4fa99e8a852412450ab78713aad30d21fa6966c9b8c9fb3262a export_key: 1ef15b4fa99e8a852412450ab78713aad30d21fa6966c9b8c9fb3262a
970dc62950d4dd4ed62598229b1b72794fc0335199d9f7fcc6eaedde92cc04870e63f 970dc62950d4dd4ed62598229b1b72794fc0335199d9f7fcc6eaedde92cc04870e63f
16 16
session_key: 42afde6f5aca0cfa5c163763fbad55e73a41db6b41bc87b8e7b62214 session_key: 42afde6f5aca0cfa5c163763fbad55e73a41db6b41bc87b8e7b62214
a8eedc6731fa3cb857d657ab9b3764b89a84e91ebcb4785166fbb02cedfcbdfda215b a8eedc6731fa3cb857d657ab9b3764b89a84e91ebcb4785166fbb02cedfcbdfda215b
96f 96f
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="opaque-3dh-real-test-vector-2"> <section anchor="opaque-3dh-real-test-vector-2">
<name>OPAQUE-3DH Real Test Vector 2</name> <name>OPAQUE-3DH Real Test Vector 2</name>
<section anchor="configuration-1"> <section anchor="configuration-1">
<name>Configuration</name> <name>Configuration</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
OPRF: ristretto255-SHA512 OPRF: ristretto255-SHA512
Hash: SHA512 Hash: SHA512
KSF: Identity KSF: Identity
KDF: HKDF-SHA512 KDF: HKDF-SHA512
MAC: HMAC-SHA512 MAC: HMAC-SHA512
Group: ristretto255 Group: ristretto255
Context: 4f50415155452d504f43 Context: 4f50415155452d504f43
Nh: 64 Nh: 64
Npk: 32 Npk: 32
Nsk: 32 Nsk: 32
Nm: 64 Nm: 64
Nx: 64 Nx: 64
Nok: 32 Nok: 32
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="input-values-1"> <section anchor="input-values-1">
<name>Input Values</name> <name>Input Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_identity: 616c696365 client_identity: 616c696365
server_identity: 626f62 server_identity: 626f62
oprf_seed: f433d0227b0b9dd54f7c4422b600e764e47fb503f1f9a0f0a47c6606b0 oprf_seed: f433d0227b0b9dd54f7c4422b600e764e47fb503f1f9a0f0a47c6606b0
54a7fdc65347f1a08f277e22358bbabe26f823fca82c7848e9a75661f4ec5d5c1989e 54a7fdc65347f1a08f277e22358bbabe26f823fca82c7848e9a75661f4ec5d5c1989e
f f
credential_identifier: 31323334 credential_identifier: 31323334
password: 436f7272656374486f72736542617474657279537461706c65 password: 436f7272656374486f72736542617474657279537461706c65
envelope_nonce: ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d2 envelope_nonce: ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d2
3ba7a38dfec 3ba7a38dfec
masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80 masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80
skipping to change at line 3113 skipping to change at line 3119
client_nonce: da7e07376d6d6f034cfa9bb537d11b8c6b4238c334333d1f0aebb38 client_nonce: da7e07376d6d6f034cfa9bb537d11b8c6b4238c334333d1f0aebb38
0cae6a6cc 0cae6a6cc
client_keyshare_seed: 82850a697b42a505f5b68fcdafce8c31f0af2b581f063cf client_keyshare_seed: 82850a697b42a505f5b68fcdafce8c31f0af2b581f063cf
1091933541936304b 1091933541936304b
server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a
1e85ff80da12f982f 1e85ff80da12f982f
blind_registration: 76cfbfe758db884bebb33582331ba9f159720ca8784a2a070 blind_registration: 76cfbfe758db884bebb33582331ba9f159720ca8784a2a070
a265d9c2d6abe01 a265d9c2d6abe01
blind_login: 6ecc102d2e7a7cf49617aad7bbe188556792d4acd60a1a8a8d2b65d4 blind_login: 6ecc102d2e7a7cf49617aad7bbe188556792d4acd60a1a8a8d2b65d4
b0790308 b0790308
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="intermediate-values-1"> <section anchor="intermediate-values-1">
<name>Intermediate Values</name> <name>Intermediate Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_public_key: 76a845464c68a5d2f7e442436bb1424953b17d3e2e289ccbac client_public_key: 76a845464c68a5d2f7e442436bb1424953b17d3e2e289ccbac
cafb57ac5c3675 cafb57ac5c3675
auth_key: 6cd32316f18d72a9a927a83199fa030663a38ce0c11fbaef82aa9003773 auth_key: 6cd32316f18d72a9a927a83199fa030663a38ce0c11fbaef82aa9003773
0494fc555c4d49506284516edd1628c27965b7555a4ebfed2223199f6c67966dde822 0494fc555c4d49506284516edd1628c27965b7555a4ebfed2223199f6c67966dde822
randomized_password: aac48c25ab036e30750839d31d6e73007344cb1155289fb7 randomized_password: aac48c25ab036e30750839d31d6e73007344cb1155289fb7
d329beb932e9adeea73d5d5c22a0ce1952f8aba6d66007615cd1698d4ac85ef1fcf15 d329beb932e9adeea73d5d5c22a0ce1952f8aba6d66007615cd1698d4ac85ef1fcf15
0031d1435d9 0031d1435d9
envelope: ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d23ba7a3 envelope: ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d23ba7a3
8dfec1ac902dc5589e9a5f0de56ad685ea8486210ef41449cd4d8712828913c5d2b68 8dfec1ac902dc5589e9a5f0de56ad685ea8486210ef41449cd4d8712828913c5d2b68
0b2b3af4a26c765cff329bfb66d38ecf1d6cfa9e7a73c222c6efe0d9520f7d7c 0b2b3af4a26c765cff329bfb66d38ecf1d6cfa9e7a73c222c6efe0d9520f7d7c
skipping to change at line 3139 skipping to change at line 3145
98c7e08155b885bfe7bc93451f9d887a0c1d0c19233e40a8e47b347a9ac3907f94032 98c7e08155b885bfe7bc93451f9d887a0c1d0c19233e40a8e47b347a9ac3907f94032
a4cff64f a4cff64f
server_mac_key: dad66bb9251073d17a13f8e5500f36e5998e3cde520ca0738e708 server_mac_key: dad66bb9251073d17a13f8e5500f36e5998e3cde520ca0738e708
5af62fd97812eb79a745c94d0bf8a6ac17f980cf435504cf64041eeb6bb237796d2c7 5af62fd97812eb79a745c94d0bf8a6ac17f980cf435504cf64041eeb6bb237796d2c7
f81e9a f81e9a
client_mac_key: f816fe2914f7c5b29852385615d7c7f31ac122adf202d7ccd4976 client_mac_key: f816fe2914f7c5b29852385615d7c7f31ac122adf202d7ccd4976
06d7aabd48930323d1d02b1cc9ecd456c4de6f46c7950becb18bffd921dd5876381b5 06d7aabd48930323d1d02b1cc9ecd456c4de6f46c7950becb18bffd921dd5876381b5
486ffe 486ffe
oprf_key: 5d4c6a8b7c7138182afb4345d1fae6a9f18a1744afbcc3854f8f5a2b4b4 oprf_key: 5d4c6a8b7c7138182afb4345d1fae6a9f18a1744afbcc3854f8f5a2b4b4
c6d05 c6d05
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="output-values-1"> <section anchor="output-values-1">
<name>Output Values</name> <name>Output Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
registration_request: 5059ff249eb1551b7ce4991f3336205bde44a105a032e74 registration_request: 5059ff249eb1551b7ce4991f3336205bde44a105a032e74
7d21bf382e75f7a71 7d21bf382e75f7a71
registration_response: 7408a268083e03abc7097fc05b587834539065e86fb0c7 registration_response: 7408a268083e03abc7097fc05b587834539065e86fb0c7
b6342fcf5e01e5b019b2fe7af9f48cc502d016729d2fe25cdd433f2c4bc904660b2a3 b6342fcf5e01e5b019b2fe7af9f48cc502d016729d2fe25cdd433f2c4bc904660b2a3
82c9b79df1a78 82c9b79df1a78
registration_upload: 76a845464c68a5d2f7e442436bb1424953b17d3e2e289ccb registration_upload: 76a845464c68a5d2f7e442436bb1424953b17d3e2e289ccb
accafb57ac5c36751ac5844383c7708077dea41cbefe2fa15724f449e535dd7dd562e accafb57ac5c36751ac5844383c7708077dea41cbefe2fa15724f449e535dd7dd562e
66f5ecfb95864eadddec9db5874959905117dad40a4524111849799281fefe3c51fa8 66f5ecfb95864eadddec9db5874959905117dad40a4524111849799281fefe3c51fa8
2785c5ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d23ba7a38dfe 2785c5ac13171b2f17bc2c74997f0fce1e1f35bec6b91fe2e12dbd323d23ba7a38dfe
c1ac902dc5589e9a5f0de56ad685ea8486210ef41449cd4d8712828913c5d2b680b2b c1ac902dc5589e9a5f0de56ad685ea8486210ef41449cd4d8712828913c5d2b680b2b
skipping to change at line 3176 skipping to change at line 3182
03552fc91fba4e7419029951c3970b2e2f0a9dea218d22e9e4e0000855bb6421aa361 03552fc91fba4e7419029951c3970b2e2f0a9dea218d22e9e4e0000855bb6421aa361
0d6fc0f4033a6517030d4341 0d6fc0f4033a6517030d4341
KE3: 7a026de1d6126905736c3f6d92463a08d209833eb793e46d0f7f15b3e0f62c76 KE3: 7a026de1d6126905736c3f6d92463a08d209833eb793e46d0f7f15b3e0f62c76
43763c02bbc6b8d3d15b63250cae98171e9260f1ffa789750f534ac11a0176d5 43763c02bbc6b8d3d15b63250cae98171e9260f1ffa789750f534ac11a0176d5
export_key: 1ef15b4fa99e8a852412450ab78713aad30d21fa6966c9b8c9fb3262a export_key: 1ef15b4fa99e8a852412450ab78713aad30d21fa6966c9b8c9fb3262a
970dc62950d4dd4ed62598229b1b72794fc0335199d9f7fcc6eaedde92cc04870e63f 970dc62950d4dd4ed62598229b1b72794fc0335199d9f7fcc6eaedde92cc04870e63f
16 16
session_key: ae7951123ab5befc27e62e63f52cf472d6236cb386c968cc47b7e34f session_key: ae7951123ab5befc27e62e63f52cf472d6236cb386c968cc47b7e34f
866aa4bc7638356a73cfce92becf39d6a7d32a1861f12130e824241fe6cab34fbd471 866aa4bc7638356a73cfce92becf39d6a7d32a1861f12130e824241fe6cab34fbd471
a57 a57
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="opaque-3dh-real-test-vector-3"> <section anchor="opaque-3dh-real-test-vector-3">
<name>OPAQUE-3DH Real Test Vector 3</name> <name>OPAQUE-3DH Real Test Vector 3</name>
<section anchor="configuration-2"> <section anchor="configuration-2">
<name>Configuration</name> <name>Configuration</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
OPRF: ristretto255-SHA512 OPRF: ristretto255-SHA512
Hash: SHA512 Hash: SHA512
KSF: Identity KSF: Identity
KDF: HKDF-SHA512 KDF: HKDF-SHA512
MAC: HMAC-SHA512 MAC: HMAC-SHA512
Group: curve25519 Group: curve25519
Context: 4f50415155452d504f43 Context: 4f50415155452d504f43
Nh: 64 Nh: 64
Npk: 32 Npk: 32
Nsk: 32 Nsk: 32
Nm: 64 Nm: 64
Nx: 64 Nx: 64
Nok: 32 Nok: 32
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="input-values-2"> <section anchor="input-values-2">
<name>Input Values</name> <name>Input Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
oprf_seed: a78342ab84d3d30f08d5a9630c79bf311c31ed7f85d9d4959bf492ec67 oprf_seed: a78342ab84d3d30f08d5a9630c79bf311c31ed7f85d9d4959bf492ec67
a0eec8a67dfbf4497248eebd49e878aab173e5e4ff76354288fdd53e949a5f7c9f7f1 a0eec8a67dfbf4497248eebd49e878aab173e5e4ff76354288fdd53e949a5f7c9f7f1
b b
credential_identifier: 31323334 credential_identifier: 31323334
password: 436f7272656374486f72736542617474657279537461706c65 password: 436f7272656374486f72736542617474657279537461706c65
envelope_nonce: 40d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cc envelope_nonce: 40d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cc
a9bf44d6e0b a9bf44d6e0b
masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80 masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80
f612fdfc6d f612fdfc6d
server_private_key: c06139381df63bfc91c850db0b9cfbec7a62e86d80040a41a server_private_key: c06139381df63bfc91c850db0b9cfbec7a62e86d80040a41a
skipping to change at line 3227 skipping to change at line 3233
client_nonce: da7e07376d6d6f034cfa9bb537d11b8c6b4238c334333d1f0aebb38 client_nonce: da7e07376d6d6f034cfa9bb537d11b8c6b4238c334333d1f0aebb38
0cae6a6cc 0cae6a6cc
client_keyshare_seed: 82850a697b42a505f5b68fcdafce8c31f0af2b581f063cf client_keyshare_seed: 82850a697b42a505f5b68fcdafce8c31f0af2b581f063cf
1091933541936304b 1091933541936304b
server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a
1e85ff80da12f982f 1e85ff80da12f982f
blind_registration: c575731ffe1cb0ca5ba63b42c4699767b8b9ab78ba39316ee blind_registration: c575731ffe1cb0ca5ba63b42c4699767b8b9ab78ba39316ee
04baddb2034a70a 04baddb2034a70a
blind_login: 6ecc102d2e7a7cf49617aad7bbe188556792d4acd60a1a8a8d2b65d4 blind_login: 6ecc102d2e7a7cf49617aad7bbe188556792d4acd60a1a8a8d2b65d4
b0790308 b0790308
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="intermediate-values-2"> <section anchor="intermediate-values-2">
<name>Intermediate Values</name> <name>Intermediate Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_public_key: 0936ea94ab030ec332e29050d266c520e916731a052d05ced7 client_public_key: 0936ea94ab030ec332e29050d266c520e916731a052d05ced7
e0cfe751142b48 e0cfe751142b48
auth_key: 7e880ab484f750e80e6f839d975aff476070ce65066d85ea62523d1d576 auth_key: 7e880ab484f750e80e6f839d975aff476070ce65066d85ea62523d1d576
4739d91307fac47186a4ab935e6a5c7f70cb47faa9473311947502c022cc67ae9440c 4739d91307fac47186a4ab935e6a5c7f70cb47faa9473311947502c022cc67ae9440c
randomized_password: 3a602c295a9c323d9362fe286f104567ed6862b25dbe30fa randomized_password: 3a602c295a9c323d9362fe286f104567ed6862b25dbe30fa
da844f19e41cf40047424b7118e15dc2c1a815a70fea5c8de6c30aa61440cd4b4b5e8 da844f19e41cf40047424b7118e15dc2c1a815a70fea5c8de6c30aa61440cd4b4b5e8
f3963fbb2e1 f3963fbb2e1
envelope: 40d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cca9bf44 envelope: 40d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cca9bf44
d6e0b20c1e81fef28e92e897ca8287d49a55075b47c3988ff0fff367d79a3e350ccac d6e0b20c1e81fef28e92e897ca8287d49a55075b47c3988ff0fff367d79a3e350ccac
150b4a3ff48b4770c8e84e437b3d4e68d2b95833f7788f7eb93fa6a8afb85ecb 150b4a3ff48b4770c8e84e437b3d4e68d2b95833f7788f7eb93fa6a8afb85ecb
skipping to change at line 3253 skipping to change at line 3259
5786f5e31c642608550c0c6f281c37ce259667dd72768af31630e0eb36f1096a2e642 5786f5e31c642608550c0c6f281c37ce259667dd72768af31630e0eb36f1096a2e642
1c2aa163 1c2aa163
server_mac_key: f3c6a8e069c54bb0d8905139f723c9e22f5c662dc08848243a665 server_mac_key: f3c6a8e069c54bb0d8905139f723c9e22f5c662dc08848243a665
4c8223800019b9823523d84da2ef67ca1c14277630aace464c113be8a0a658c39e181 4c8223800019b9823523d84da2ef67ca1c14277630aace464c113be8a0a658c39e181
a8bb71 a8bb71
client_mac_key: b1ee7ce52dbd0ab72872924ff11596cb196bbabfc319e74aca78a client_mac_key: b1ee7ce52dbd0ab72872924ff11596cb196bbabfc319e74aca78a
de54a0f74dd15dcf5621f6d2e79161b0c9b701381d494836dedbb86e584a65b34267a de54a0f74dd15dcf5621f6d2e79161b0c9b701381d494836dedbb86e584a65b34267a
370e01 370e01
oprf_key: 62ef7f7d9506a14600c34f642aaf6ef8019cc82a6755db4fded5248ea14 oprf_key: 62ef7f7d9506a14600c34f642aaf6ef8019cc82a6755db4fded5248ea14
6030a 6030a
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="output-values-2"> <section anchor="output-values-2">
<name>Output Values</name> <name>Output Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
registration_request: 26f3dbfd76b8e5f85b4da604f42889a7d4b1bc919f65538 registration_request: 26f3dbfd76b8e5f85b4da604f42889a7d4b1bc919f65538
1a67de02c59fd5436 1a67de02c59fd5436
registration_response: 506e8f1b89c098fb89b5b6210a05f7898cafdaea221761 registration_response: 506e8f1b89c098fb89b5b6210a05f7898cafdaea221761
e8d5272fc39e0f9f08a41e28269b4e97a66468cc00c5a57753e192e15276698977068 e8d5272fc39e0f9f08a41e28269b4e97a66468cc00c5a57753e192e15276698977068
8aa90486ef031 8aa90486ef031
registration_upload: 0936ea94ab030ec332e29050d266c520e916731a052d05ce registration_upload: 0936ea94ab030ec332e29050d266c520e916731a052d05ce
d7e0cfe751142b486d23c6ed818882f9bdfdcf91389fcbc0b7a3faf92bd0bd6be4a1e d7e0cfe751142b486d23c6ed818882f9bdfdcf91389fcbc0b7a3faf92bd0bd6be4a1e
7730277b694fc7c6ba327fbe786af18487688e0f7c148bbd54dc2fc80c28e7a976d9e 7730277b694fc7c6ba327fbe786af18487688e0f7c148bbd54dc2fc80c28e7a976d9e
f53c3540d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cca9bf44d6e0 f53c3540d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cca9bf44d6e0
b20c1e81fef28e92e897ca8287d49a55075b47c3988ff0fff367d79a3e350ccac150b b20c1e81fef28e92e897ca8287d49a55075b47c3988ff0fff367d79a3e350ccac150b
skipping to change at line 3290 skipping to change at line 3296
ac78bc3bc6f8747d5b35acf94eff3ec2ebe7d49b8cf16be64120b279fe92664e47be5 ac78bc3bc6f8747d5b35acf94eff3ec2ebe7d49b8cf16be64120b279fe92664e47be5
da7e60f08f12e91192652f79 da7e60f08f12e91192652f79
KE3: 550e923829a544496d8316c490da2b979b78c730dd75be3a17f237a26432c19f KE3: 550e923829a544496d8316c490da2b979b78c730dd75be3a17f237a26432c19f
bba54b6a0467b1c22ecbd6794bc5fa5b04215ba1ef974c6b090baa42c5bb984f bba54b6a0467b1c22ecbd6794bc5fa5b04215ba1ef974c6b090baa42c5bb984f
export_key: 9dec51d6d0f6ce7e4345f10961053713b07310cc2e45872f57bbd2fe5 export_key: 9dec51d6d0f6ce7e4345f10961053713b07310cc2e45872f57bbd2fe5
070fdf0fb5b77c7ddaa2f3dc5c35132df7417ad7fefe0f690ad266e5a54a21d045c9c 070fdf0fb5b77c7ddaa2f3dc5c35132df7417ad7fefe0f690ad266e5a54a21d045c9c
38 38
session_key: fd2fdd07c1bcc88e81c1b1d1de5ad62dfdef1c0b8209ff9d671e1fac session_key: fd2fdd07c1bcc88e81c1b1d1de5ad62dfdef1c0b8209ff9d671e1fac
55ce9c34d381c1fb2703ff53a797f77daccbe33047ccc167b8105171e10ec962eea20 55ce9c34d381c1fb2703ff53a797f77daccbe33047ccc167b8105171e10ec962eea20
3aa 3aa
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="opaque-3dh-real-test-vector-4"> <section anchor="opaque-3dh-real-test-vector-4">
<name>OPAQUE-3DH Real Test Vector 4</name> <name>OPAQUE-3DH Real Test Vector 4</name>
<section anchor="configuration-3"> <section anchor="configuration-3">
<name>Configuration</name> <name>Configuration</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
OPRF: ristretto255-SHA512 OPRF: ristretto255-SHA512
Hash: SHA512 Hash: SHA512
KSF: Identity KSF: Identity
KDF: HKDF-SHA512 KDF: HKDF-SHA512
MAC: HMAC-SHA512 MAC: HMAC-SHA512
Group: curve25519 Group: curve25519
Context: 4f50415155452d504f43 Context: 4f50415155452d504f43
Nh: 64 Nh: 64
Npk: 32 Npk: 32
Nsk: 32 Nsk: 32
Nm: 64 Nm: 64
Nx: 64 Nx: 64
Nok: 32 Nok: 32
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="input-values-3"> <section anchor="input-values-3">
<name>Input Values</name> <name>Input Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_identity: 616c696365 client_identity: 616c696365
server_identity: 626f62 server_identity: 626f62
oprf_seed: a78342ab84d3d30f08d5a9630c79bf311c31ed7f85d9d4959bf492ec67 oprf_seed: a78342ab84d3d30f08d5a9630c79bf311c31ed7f85d9d4959bf492ec67
a0eec8a67dfbf4497248eebd49e878aab173e5e4ff76354288fdd53e949a5f7c9f7f1 a0eec8a67dfbf4497248eebd49e878aab173e5e4ff76354288fdd53e949a5f7c9f7f1
b b
credential_identifier: 31323334 credential_identifier: 31323334
password: 436f7272656374486f72736542617474657279537461706c65 password: 436f7272656374486f72736542617474657279537461706c65
envelope_nonce: 40d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cc envelope_nonce: 40d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cc
a9bf44d6e0b a9bf44d6e0b
masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80 masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80
skipping to change at line 3343 skipping to change at line 3349
client_nonce: da7e07376d6d6f034cfa9bb537d11b8c6b4238c334333d1f0aebb38 client_nonce: da7e07376d6d6f034cfa9bb537d11b8c6b4238c334333d1f0aebb38
0cae6a6cc 0cae6a6cc
client_keyshare_seed: 82850a697b42a505f5b68fcdafce8c31f0af2b581f063cf client_keyshare_seed: 82850a697b42a505f5b68fcdafce8c31f0af2b581f063cf
1091933541936304b 1091933541936304b
server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a
1e85ff80da12f982f 1e85ff80da12f982f
blind_registration: c575731ffe1cb0ca5ba63b42c4699767b8b9ab78ba39316ee blind_registration: c575731ffe1cb0ca5ba63b42c4699767b8b9ab78ba39316ee
04baddb2034a70a 04baddb2034a70a
blind_login: 6ecc102d2e7a7cf49617aad7bbe188556792d4acd60a1a8a8d2b65d4 blind_login: 6ecc102d2e7a7cf49617aad7bbe188556792d4acd60a1a8a8d2b65d4
b0790308 b0790308
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="intermediate-values-3"> <section anchor="intermediate-values-3">
<name>Intermediate Values</name> <name>Intermediate Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_public_key: 0936ea94ab030ec332e29050d266c520e916731a052d05ced7 client_public_key: 0936ea94ab030ec332e29050d266c520e916731a052d05ced7
e0cfe751142b48 e0cfe751142b48
auth_key: 7e880ab484f750e80e6f839d975aff476070ce65066d85ea62523d1d576 auth_key: 7e880ab484f750e80e6f839d975aff476070ce65066d85ea62523d1d576
4739d91307fac47186a4ab935e6a5c7f70cb47faa9473311947502c022cc67ae9440c 4739d91307fac47186a4ab935e6a5c7f70cb47faa9473311947502c022cc67ae9440c
randomized_password: 3a602c295a9c323d9362fe286f104567ed6862b25dbe30fa randomized_password: 3a602c295a9c323d9362fe286f104567ed6862b25dbe30fa
da844f19e41cf40047424b7118e15dc2c1a815a70fea5c8de6c30aa61440cd4b4b5e8 da844f19e41cf40047424b7118e15dc2c1a815a70fea5c8de6c30aa61440cd4b4b5e8
f3963fbb2e1 f3963fbb2e1
envelope: 40d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cca9bf44 envelope: 40d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cca9bf44
d6e0bb4c0eab6143959a650c5f6b32acf162b1fbe95bb36c5c4f99df53865c4d3537d d6e0bb4c0eab6143959a650c5f6b32acf162b1fbe95bb36c5c4f99df53865c4d3537d
69061d80522d772cd0efdbe91f817f6bf7259a56e20b4eb9cbe9443702f4b759 69061d80522d772cd0efdbe91f817f6bf7259a56e20b4eb9cbe9443702f4b759
skipping to change at line 3369 skipping to change at line 3375
eb3d37303b90de35a8bf095df84471ac77d705f12fe232f1571de1d6a001d3e808998 eb3d37303b90de35a8bf095df84471ac77d705f12fe232f1571de1d6a001d3e808998
73a142dc 73a142dc
server_mac_key: a58135acfb2bde92d506cf59119729a6404ad94eba294e4b52a63 server_mac_key: a58135acfb2bde92d506cf59119729a6404ad94eba294e4b52a63
baf58cfe03f21bcf735222c7f2c27a60bd958be7f6aed50dc03a78f64e7ae4ac1ff07 baf58cfe03f21bcf735222c7f2c27a60bd958be7f6aed50dc03a78f64e7ae4ac1ff07
1b95aa 1b95aa
client_mac_key: 1e1a8ba156aadc4a302f707d2193c9dab477b355f430d450dd407 client_mac_key: 1e1a8ba156aadc4a302f707d2193c9dab477b355f430d450dd407
ce40dc75613f76ec33dec494f8a6bfdcf951eb060dac33e6572c693954fe92e33730c ce40dc75613f76ec33dec494f8a6bfdcf951eb060dac33e6572c693954fe92e33730c
9ab0a2 9ab0a2
oprf_key: 62ef7f7d9506a14600c34f642aaf6ef8019cc82a6755db4fded5248ea14 oprf_key: 62ef7f7d9506a14600c34f642aaf6ef8019cc82a6755db4fded5248ea14
6030a 6030a
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="output-values-3"> <section anchor="output-values-3">
<name>Output Values</name> <name>Output Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
registration_request: 26f3dbfd76b8e5f85b4da604f42889a7d4b1bc919f65538 registration_request: 26f3dbfd76b8e5f85b4da604f42889a7d4b1bc919f65538
1a67de02c59fd5436 1a67de02c59fd5436
registration_response: 506e8f1b89c098fb89b5b6210a05f7898cafdaea221761 registration_response: 506e8f1b89c098fb89b5b6210a05f7898cafdaea221761
e8d5272fc39e0f9f08a41e28269b4e97a66468cc00c5a57753e192e15276698977068 e8d5272fc39e0f9f08a41e28269b4e97a66468cc00c5a57753e192e15276698977068
8aa90486ef031 8aa90486ef031
registration_upload: 0936ea94ab030ec332e29050d266c520e916731a052d05ce registration_upload: 0936ea94ab030ec332e29050d266c520e916731a052d05ce
d7e0cfe751142b486d23c6ed818882f9bdfdcf91389fcbc0b7a3faf92bd0bd6be4a1e d7e0cfe751142b486d23c6ed818882f9bdfdcf91389fcbc0b7a3faf92bd0bd6be4a1e
7730277b694fc7c6ba327fbe786af18487688e0f7c148bbd54dc2fc80c28e7a976d9e 7730277b694fc7c6ba327fbe786af18487688e0f7c148bbd54dc2fc80c28e7a976d9e
f53c3540d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cca9bf44d6e0 f53c3540d6b67fdd7da7c49894750754514dbd2070a407166bd2a5237cca9bf44d6e0
bb4c0eab6143959a650c5f6b32acf162b1fbe95bb36c5c4f99df53865c4d3537d6906 bb4c0eab6143959a650c5f6b32acf162b1fbe95bb36c5c4f99df53865c4d3537d6906
skipping to change at line 3406 skipping to change at line 3412
51e365f0d46a7fed0e09d96f9afbb48868f5bb3c3e05a86ed8c9476fc22c58306c5a2 51e365f0d46a7fed0e09d96f9afbb48868f5bb3c3e05a86ed8c9476fc22c58306c5a2
91be34388e09548ba9d70f39 91be34388e09548ba9d70f39
KE3: d16344e791c3f18594d22ba068984fa18ec1e9bead662b75f66826ffd627932f KE3: d16344e791c3f18594d22ba068984fa18ec1e9bead662b75f66826ffd627932f
cd1ec40cd01dcf5f63f4055ebe45c7717a57a833aad360256cf1e1c20c0eae1c cd1ec40cd01dcf5f63f4055ebe45c7717a57a833aad360256cf1e1c20c0eae1c
export_key: 9dec51d6d0f6ce7e4345f10961053713b07310cc2e45872f57bbd2fe5 export_key: 9dec51d6d0f6ce7e4345f10961053713b07310cc2e45872f57bbd2fe5
070fdf0fb5b77c7ddaa2f3dc5c35132df7417ad7fefe0f690ad266e5a54a21d045c9c 070fdf0fb5b77c7ddaa2f3dc5c35132df7417ad7fefe0f690ad266e5a54a21d045c9c
38 38
session_key: f6116d3aa0e4089a179713bad4d98ed5cb57e5443cae8d36ef78996f session_key: f6116d3aa0e4089a179713bad4d98ed5cb57e5443cae8d36ef78996f
a60f3dc6e9fcdd63c001596b06dbc1285d80211035cc0e485506b3f7a650cbf78c5bf a60f3dc6e9fcdd63c001596b06dbc1285d80211035cc0e485506b3f7a650cbf78c5bf
fc9 fc9
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="opaque-3dh-real-test-vector-5"> <section anchor="opaque-3dh-real-test-vector-5">
<name>OPAQUE-3DH Real Test Vector 5</name> <name>OPAQUE-3DH Real Test Vector 5</name>
<section anchor="configuration-4"> <section anchor="configuration-4">
<name>Configuration</name> <name>Configuration</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
OPRF: P256-SHA256 OPRF: P256-SHA256
Hash: SHA256 Hash: SHA256
KSF: Identity KSF: Identity
KDF: HKDF-SHA256 KDF: HKDF-SHA256
MAC: HMAC-SHA256 MAC: HMAC-SHA256
Group: P256_XMD:SHA-256_SSWU_RO_ Group: P256_XMD:SHA-256_SSWU_RO_
Context: 4f50415155452d504f43 Context: 4f50415155452d504f43
Nh: 32 Nh: 32
Npk: 33 Npk: 33
Nsk: 32 Nsk: 32
Nm: 32 Nm: 32
Nx: 32 Nx: 32
Nok: 32 Nok: 32
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="input-values-4"> <section anchor="input-values-4">
<name>Input Values</name> <name>Input Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
oprf_seed: 62f60b286d20ce4fd1d64809b0021dad6ed5d52a2c8cf27ae6582543a0 oprf_seed: 62f60b286d20ce4fd1d64809b0021dad6ed5d52a2c8cf27ae6582543a0
a8dce2 a8dce2
credential_identifier: 31323334 credential_identifier: 31323334
password: 436f7272656374486f72736542617474657279537461706c65 password: 436f7272656374486f72736542617474657279537461706c65
envelope_nonce: a921f2a014513bd8a90e477a629794e89fec12d12206dde662ebd envelope_nonce: a921f2a014513bd8a90e477a629794e89fec12d12206dde662ebd
cf65670e51f cf65670e51f
masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80 masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80
f612fdfc6d f612fdfc6d
server_private_key: c36139381df63bfc91c850db0b9cfbec7a62e86d80040a41a server_private_key: c36139381df63bfc91c850db0b9cfbec7a62e86d80040a41a
a7725bf0e79d5e5 a7725bf0e79d5e5
skipping to change at line 3456 skipping to change at line 3462
client_nonce: ab3d33bde0e93eda72392346a7a73051110674bbf6b1b7ffab8be4f client_nonce: ab3d33bde0e93eda72392346a7a73051110674bbf6b1b7ffab8be4f
91fdaeeb1 91fdaeeb1
client_keyshare_seed: 633b875d74d1556d2a2789309972b06db21dfcc4f5ad51d client_keyshare_seed: 633b875d74d1556d2a2789309972b06db21dfcc4f5ad51d
7e74d783b7cfab8dc 7e74d783b7cfab8dc
server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a
1e85ff80da12f982f 1e85ff80da12f982f
blind_registration: 411bf1a62d119afe30df682b91a0a33d777972d4f2daa4b34 blind_registration: 411bf1a62d119afe30df682b91a0a33d777972d4f2daa4b34
ca527d597078153 ca527d597078153
blind_login: c497fddf6056d241e6cf9fb7ac37c384f49b357a221eb0a802c989b9 blind_login: c497fddf6056d241e6cf9fb7ac37c384f49b357a221eb0a802c989b9
942256c1 942256c1
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="intermediate-values-4"> <section anchor="intermediate-values-4">
<name>Intermediate Values</name> <name>Intermediate Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_public_key: 03b218507d978c3db570ca994aaf36695a731ddb2db272c817 client_public_key: 03b218507d978c3db570ca994aaf36695a731ddb2db272c817
f79746fc37ae5214 f79746fc37ae5214
auth_key: 5bd4be1602516092dc5078f8d699f5721dc1720a49fb80d8e5c16377abd auth_key: 5bd4be1602516092dc5078f8d699f5721dc1720a49fb80d8e5c16377abd
0987b 0987b
randomized_password: 06be0a1a51d56557a3adad57ba29c5510565dcd8b5078fa3 randomized_password: 06be0a1a51d56557a3adad57ba29c5510565dcd8b5078fa3
19151b9382258fb0 19151b9382258fb0
envelope: a921f2a014513bd8a90e477a629794e89fec12d12206dde662ebdcf6567 envelope: a921f2a014513bd8a90e477a629794e89fec12d12206dde662ebdcf6567
0e51fad30bbcfc1f8eda0211553ab9aaf26345ad59a128e80188f035fe4924fad67b8 0e51fad30bbcfc1f8eda0211553ab9aaf26345ad59a128e80188f035fe4924fad67b8
handshake_secret: 83a932431a8f25bad042f008efa2b07c6cd0faa8285f335b636 handshake_secret: 83a932431a8f25bad042f008efa2b07c6cd0faa8285f335b636
3546a9f9b235f 3546a9f9b235f
server_mac_key: 13e928581febfad28855e3e7f03306d61bd69489686f621535d44 server_mac_key: 13e928581febfad28855e3e7f03306d61bd69489686f621535d44
a1365b73b0d a1365b73b0d
client_mac_key: afdc53910c25183b08b930e6953c35b3466276736d9de2e9c5efa client_mac_key: afdc53910c25183b08b930e6953c35b3466276736d9de2e9c5efa
f150f4082c5 f150f4082c5
oprf_key: 2dfb5cb9aa1476093be74ca0d43e5b02862a05f5d6972614d7433acdc66 oprf_key: 2dfb5cb9aa1476093be74ca0d43e5b02862a05f5d6972614d7433acdc66
f7f31 f7f31
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="output-values-4"> <section anchor="output-values-4">
<name>Output Values</name> <name>Output Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
registration_request: 029e949a29cfa0bf7c1287333d2fb3dc586c41aa652f507 registration_request: 029e949a29cfa0bf7c1287333d2fb3dc586c41aa652f507
0d26a5315a1b50229f8 0d26a5315a1b50229f8
registration_response: 0350d3694c00978f00a5ce7cd08a00547e4ab5fb5fc2b2 registration_response: 0350d3694c00978f00a5ce7cd08a00547e4ab5fb5fc2b2
f6717cdaa6c89136efef035f40ff9cf88aa1f5cd4fe5fd3da9ea65a4923a5594f84fd f6717cdaa6c89136efef035f40ff9cf88aa1f5cd4fe5fd3da9ea65a4923a5594f84fd
9f2092d6067784874 9f2092d6067784874
registration_upload: 03b218507d978c3db570ca994aaf36695a731ddb2db272c8 registration_upload: 03b218507d978c3db570ca994aaf36695a731ddb2db272c8
17f79746fc37ae52147f0ed53532d3ae8e505ecc70d42d2b814b6b0e48156def71ea0 17f79746fc37ae52147f0ed53532d3ae8e505ecc70d42d2b814b6b0e48156def71ea0
29148b2803aafa921f2a014513bd8a90e477a629794e89fec12d12206dde662ebdcf6 29148b2803aafa921f2a014513bd8a90e477a629794e89fec12d12206dde662ebdcf6
5670e51fad30bbcfc1f8eda0211553ab9aaf26345ad59a128e80188f035fe4924fad6 5670e51fad30bbcfc1f8eda0211553ab9aaf26345ad59a128e80188f035fe4924fad6
7b8 7b8
skipping to change at line 3508 skipping to change at line 3514
0e66740c76b62c13b04a38a77926e19072953319ec65e41f9bfd2ae26837b6ce688bf 0e66740c76b62c13b04a38a77926e19072953319ec65e41f9bfd2ae26837b6ce688bf
9af2542f04eec9ab96a1b9328812dc2f5c89182ed47fead61f09f71cd9960ecef2fe0 9af2542f04eec9ab96a1b9328812dc2f5c89182ed47fead61f09f71cd9960ecef2fe0
d0f7494986fa3d8b2bb01963537e60efb13981e138e3d4a103c1701353219b53acf33 d0f7494986fa3d8b2bb01963537e60efb13981e138e3d4a103c1701353219b53acf33
7bf6456a83cefed8f563f1040b65afbf3b65d3bc9a19b50a73b145bc87a157e8c58c0 7bf6456a83cefed8f563f1040b65afbf3b65d3bc9a19b50a73b145bc87a157e8c58c0
342e2047ee22ae37b63db17e0a82a30fcc4ecf7b 342e2047ee22ae37b63db17e0a82a30fcc4ecf7b
KE3: e97cab4433aa39d598e76f13e768bba61c682947bdcf9936035e8a3a3ebfb66e KE3: e97cab4433aa39d598e76f13e768bba61c682947bdcf9936035e8a3a3ebfb66e
export_key: c3c9a1b0e33ac84dd83d0b7e8af6794e17e7a3caadff289fbd9dc769a export_key: c3c9a1b0e33ac84dd83d0b7e8af6794e17e7a3caadff289fbd9dc769a
853c64b 853c64b
session_key: 484ad345715ccce138ca49e4ea362c6183f0949aaaa1125dc3bc3f80 session_key: 484ad345715ccce138ca49e4ea362c6183f0949aaaa1125dc3bc3f80
876e7cd1 876e7cd1
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="opaque-3dh-real-test-vector-6"> <section anchor="opaque-3dh-real-test-vector-6">
<name>OPAQUE-3DH Real Test Vector 6</name> <name>OPAQUE-3DH Real Test Vector 6</name>
<section anchor="configuration-5"> <section anchor="configuration-5">
<name>Configuration</name> <name>Configuration</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
OPRF: P256-SHA256 OPRF: P256-SHA256
Hash: SHA256 Hash: SHA256
KSF: Identity KSF: Identity
KDF: HKDF-SHA256 KDF: HKDF-SHA256
MAC: HMAC-SHA256 MAC: HMAC-SHA256
Group: P256_XMD:SHA-256_SSWU_RO_ Group: P256_XMD:SHA-256_SSWU_RO_
Context: 4f50415155452d504f43 Context: 4f50415155452d504f43
Nh: 32 Nh: 32
Npk: 33 Npk: 33
Nsk: 32 Nsk: 32
Nm: 32 Nm: 32
Nx: 32 Nx: 32
Nok: 32 Nok: 32
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="input-values-5"> <section anchor="input-values-5">
<name>Input Values</name> <name>Input Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_identity: 616c696365 client_identity: 616c696365
server_identity: 626f62 server_identity: 626f62
oprf_seed: 62f60b286d20ce4fd1d64809b0021dad6ed5d52a2c8cf27ae6582543a0 oprf_seed: 62f60b286d20ce4fd1d64809b0021dad6ed5d52a2c8cf27ae6582543a0
a8dce2 a8dce2
credential_identifier: 31323334 credential_identifier: 31323334
password: 436f7272656374486f72736542617474657279537461706c65 password: 436f7272656374486f72736542617474657279537461706c65
envelope_nonce: a921f2a014513bd8a90e477a629794e89fec12d12206dde662ebd envelope_nonce: a921f2a014513bd8a90e477a629794e89fec12d12206dde662ebd
cf65670e51f cf65670e51f
masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80 masking_nonce: 38fe59af0df2c79f57b8780278f5ae47355fe1f817119041951c80
f612fdfc6d f612fdfc6d
skipping to change at line 3560 skipping to change at line 3566
client_nonce: ab3d33bde0e93eda72392346a7a73051110674bbf6b1b7ffab8be4f client_nonce: ab3d33bde0e93eda72392346a7a73051110674bbf6b1b7ffab8be4f
91fdaeeb1 91fdaeeb1
client_keyshare_seed: 633b875d74d1556d2a2789309972b06db21dfcc4f5ad51d client_keyshare_seed: 633b875d74d1556d2a2789309972b06db21dfcc4f5ad51d
7e74d783b7cfab8dc 7e74d783b7cfab8dc
server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a server_keyshare_seed: 05a4f54206eef1ba2f615bc0aa285cb22f26d1153b5b40a
1e85ff80da12f982f 1e85ff80da12f982f
blind_registration: 411bf1a62d119afe30df682b91a0a33d777972d4f2daa4b34 blind_registration: 411bf1a62d119afe30df682b91a0a33d777972d4f2daa4b34
ca527d597078153 ca527d597078153
blind_login: c497fddf6056d241e6cf9fb7ac37c384f49b357a221eb0a802c989b9 blind_login: c497fddf6056d241e6cf9fb7ac37c384f49b357a221eb0a802c989b9
942256c1 942256c1
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="intermediate-values-5"> <section anchor="intermediate-values-5">
<name>Intermediate Values</name> <name>Intermediate Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_public_key: 03b218507d978c3db570ca994aaf36695a731ddb2db272c817 client_public_key: 03b218507d978c3db570ca994aaf36695a731ddb2db272c817
f79746fc37ae5214 f79746fc37ae5214
auth_key: 5bd4be1602516092dc5078f8d699f5721dc1720a49fb80d8e5c16377abd auth_key: 5bd4be1602516092dc5078f8d699f5721dc1720a49fb80d8e5c16377abd
0987b 0987b
randomized_password: 06be0a1a51d56557a3adad57ba29c5510565dcd8b5078fa3 randomized_password: 06be0a1a51d56557a3adad57ba29c5510565dcd8b5078fa3
19151b9382258fb0 19151b9382258fb0
envelope: a921f2a014513bd8a90e477a629794e89fec12d12206dde662ebdcf6567 envelope: a921f2a014513bd8a90e477a629794e89fec12d12206dde662ebdcf6567
0e51f4d7773a36a208a866301dbb2858e40dc5638017527cf91aef32d3848eebe0971 0e51f4d7773a36a208a866301dbb2858e40dc5638017527cf91aef32d3848eebe0971
handshake_secret: 80bdcc498f22de492e90ee8101fcc7c101e158dd49c77f7c283 handshake_secret: 80bdcc498f22de492e90ee8101fcc7c101e158dd49c77f7c283
816ae329ed62f 816ae329ed62f
server_mac_key: 0f82432fbdb5b90daf27a91a3acc42299a9590dba1b77932c2207 server_mac_key: 0f82432fbdb5b90daf27a91a3acc42299a9590dba1b77932c2207
b4cb3d4a157 b4cb3d4a157
client_mac_key: 7f629eb0b1b69979b07ca1f564b3e92ed22f07569fd1d11725d93 client_mac_key: 7f629eb0b1b69979b07ca1f564b3e92ed22f07569fd1d11725d93
e46731fbe71 e46731fbe71
oprf_key: 2dfb5cb9aa1476093be74ca0d43e5b02862a05f5d6972614d7433acdc66 oprf_key: 2dfb5cb9aa1476093be74ca0d43e5b02862a05f5d6972614d7433acdc66
f7f31 f7f31
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="output-values-5"> <section anchor="output-values-5">
<name>Output Values</name> <name>Output Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
registration_request: 029e949a29cfa0bf7c1287333d2fb3dc586c41aa652f507 registration_request: 029e949a29cfa0bf7c1287333d2fb3dc586c41aa652f507
0d26a5315a1b50229f8 0d26a5315a1b50229f8
registration_response: 0350d3694c00978f00a5ce7cd08a00547e4ab5fb5fc2b2 registration_response: 0350d3694c00978f00a5ce7cd08a00547e4ab5fb5fc2b2
f6717cdaa6c89136efef035f40ff9cf88aa1f5cd4fe5fd3da9ea65a4923a5594f84fd f6717cdaa6c89136efef035f40ff9cf88aa1f5cd4fe5fd3da9ea65a4923a5594f84fd
9f2092d6067784874 9f2092d6067784874
registration_upload: 03b218507d978c3db570ca994aaf36695a731ddb2db272c8 registration_upload: 03b218507d978c3db570ca994aaf36695a731ddb2db272c8
17f79746fc37ae52147f0ed53532d3ae8e505ecc70d42d2b814b6b0e48156def71ea0 17f79746fc37ae52147f0ed53532d3ae8e505ecc70d42d2b814b6b0e48156def71ea0
29148b2803aafa921f2a014513bd8a90e477a629794e89fec12d12206dde662ebdcf6 29148b2803aafa921f2a014513bd8a90e477a629794e89fec12d12206dde662ebdcf6
5670e51f4d7773a36a208a866301dbb2858e40dc5638017527cf91aef32d3848eebe0 5670e51f4d7773a36a208a866301dbb2858e40dc5638017527cf91aef32d3848eebe0
971 971
skipping to change at line 3612 skipping to change at line 3618
0e66740c76b62c13b04a38a77926e19072953319ec65e41f9bfd2ae268d7f10604202 0e66740c76b62c13b04a38a77926e19072953319ec65e41f9bfd2ae268d7f10604202
1c80300e4c6f585980cf39fc51a4a6bba41b0729f9b240c729e5671cd9960ecef2fe0 1c80300e4c6f585980cf39fc51a4a6bba41b0729f9b240c729e5671cd9960ecef2fe0
d0f7494986fa3d8b2bb01963537e60efb13981e138e3d4a103c1701353219b53acf33 d0f7494986fa3d8b2bb01963537e60efb13981e138e3d4a103c1701353219b53acf33
7bf6456a83cefed8f563f1040b65afbf3b65d3bc9a19b84922c7e5d074838a8f27859 7bf6456a83cefed8f563f1040b65afbf3b65d3bc9a19b84922c7e5d074838a8f27859
2c53f61fb59f031e85ad480c0c71086b871e1b24 2c53f61fb59f031e85ad480c0c71086b871e1b24
KE3: 46833578cee137775f6be3f01b80748daac5a694101ad0e9e7025480552da56a KE3: 46833578cee137775f6be3f01b80748daac5a694101ad0e9e7025480552da56a
export_key: c3c9a1b0e33ac84dd83d0b7e8af6794e17e7a3caadff289fbd9dc769a export_key: c3c9a1b0e33ac84dd83d0b7e8af6794e17e7a3caadff289fbd9dc769a
853c64b 853c64b
session_key: 27766fabd8dd88ff37fbd0ef1a491e601d10d9f016c2b28c4bd1b0fb session_key: 27766fabd8dd88ff37fbd0ef1a491e601d10d9f016c2b28c4bd1b0fb
7511a3c3 7511a3c3
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="fake-vectors"> <section anchor="fake-vectors">
<name>Fake Test Vectors</name> <name>Fake Test Vectors</name>
<section anchor="opaque-3dh-fake-test-vector-1"> <section anchor="opaque-3dh-fake-test-vector-1">
<name>OPAQUE-3DH Fake Test Vector 1</name> <name>OPAQUE-3DH Fake Test Vector 1</name>
<section anchor="configuration-6"> <section anchor="configuration-6">
<name>Configuration</name> <name>Configuration</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
OPRF: ristretto255-SHA512 OPRF: ristretto255-SHA512
Hash: SHA512 Hash: SHA512
KSF: Identity KSF: Identity
KDF: HKDF-SHA512 KDF: HKDF-SHA512
MAC: HMAC-SHA512 MAC: HMAC-SHA512
Group: ristretto255 Group: ristretto255
Context: 4f50415155452d504f43 Context: 4f50415155452d504f43
Nh: 64 Nh: 64
Npk: 32 Npk: 32
Nsk: 32 Nsk: 32
Nm: 64 Nm: 64
Nx: 64 Nx: 64
Nok: 32 Nok: 32
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="input-values-6"> <section anchor="input-values-6">
<name>Input Values</name> <name>Input Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_identity: 616c696365 client_identity: 616c696365
server_identity: 626f62 server_identity: 626f62
oprf_seed: 743fc168d1f826ad43738933e5adb23da6fb95f95a1b069f0daa0522d0 oprf_seed: 743fc168d1f826ad43738933e5adb23da6fb95f95a1b069f0daa0522d0
a78b617f701fc6aa46d3e7981e70de7765dfcd6b1e13e3369a582eb8dc456b10aa53b a78b617f701fc6aa46d3e7981e70de7765dfcd6b1e13e3369a582eb8dc456b10aa53b
0 0
credential_identifier: 31323334 credential_identifier: 31323334
masking_nonce: 9c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c61 masking_nonce: 9c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c61
9e27b6e5a6 9e27b6e5a6
client_private_key: 2b98980aa95ab53a0f39f0291903d2fdf04b00c167f081416 client_private_key: 2b98980aa95ab53a0f39f0291903d2fdf04b00c167f081416
9922df873002409 9922df873002409
skipping to change at line 3669 skipping to change at line 3675
client_keyshare_seed: a270dc715dc2b4612bc7864312a05c3e9788ee1bad1f276 client_keyshare_seed: a270dc715dc2b4612bc7864312a05c3e9788ee1bad1f276
d1e15bdeb4c355e94 d1e15bdeb4c355e94
server_keyshare_seed: 360b0937f47d45f6123a4d8f0d0c0814b6120d840ebb8bc server_keyshare_seed: 360b0937f47d45f6123a4d8f0d0c0814b6120d840ebb8bc
5b4f6b62df07f78c2 5b4f6b62df07f78c2
masking_key: 39ebd51f0e39a07a1c2d2431995b0399bca9996c5d10014d6ebab445 masking_key: 39ebd51f0e39a07a1c2d2431995b0399bca9996c5d10014d6ebab445
3dc10ce5cef38ed3df6e56bfff40c2d8dd4671c2b4cf63c3d54860f31fe40220d690b 3dc10ce5cef38ed3df6e56bfff40c2d8dd4671c2b4cf63c3d54860f31fe40220d690b
b71 b71
KE1: b0a26dcaca2230b8f5e4b1bcab9c84b586140221bb8b2848486874b0be448905 KE1: b0a26dcaca2230b8f5e4b1bcab9c84b586140221bb8b2848486874b0be448905
42d4e61ed3f8d64cdd3b9d153343eca15b9b0d5e388232793c6376bd2d9cfd0ab641d 42d4e61ed3f8d64cdd3b9d153343eca15b9b0d5e388232793c6376bd2d9cfd0ab641d
7f20a245a09f1d4dbb6e301661af7f352beb0791d055e48d3645232f77f 7f20a245a09f1d4dbb6e301661af7f352beb0791d055e48d3645232f77f
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="output-values-6"> <section anchor="output-values-6">
<name>Output Values</name> <name>Output Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
KE2: 928f79ad8df21963e91411b9f55165ba833dea918f441db967cdc09521d22925 KE2: 928f79ad8df21963e91411b9f55165ba833dea918f441db967cdc09521d22925
9c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c619e27b6e5a632b5a 9c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c619e27b6e5a632b5a
b1bff96636144faa4f9f9afaac75dd88ea99cf5175902ae3f3b2195693f165f11929b b1bff96636144faa4f9f9afaac75dd88ea99cf5175902ae3f3b2195693f165f11929b
a510a5978e64dcdabecbd7ee1e4380ce270e58fea58e6462d92964a1aaef72698bca1 a510a5978e64dcdabecbd7ee1e4380ce270e58fea58e6462d92964a1aaef72698bca1
c673baeb04cc2bf7de5f3c2f5553464552d3a0f7698a9ca7f9c5e70c6cb1f706b2f17 c673baeb04cc2bf7de5f3c2f5553464552d3a0f7698a9ca7f9c5e70c6cb1f706b2f17
5ab9d04bbd13926e816b6811a50b4aafa9799d5ed7971e10f6eeab2a7a420bf09da9b 5ab9d04bbd13926e816b6811a50b4aafa9799d5ed7971e10f6eeab2a7a420bf09da9b
27a4639645622c46358de9cf7ae813055ae2d1298251c5ba55f6b0b2d58d9ff0c88fe 27a4639645622c46358de9cf7ae813055ae2d1298251c5ba55f6b0b2d58d9ff0c88fe
4176484be62a96db6e2a8c4d431bd1bf27fe6c1d0537603835217d42ebf7b25819827 4176484be62a96db6e2a8c4d431bd1bf27fe6c1d0537603835217d42ebf7b25819827
32e74892fd28211b31ed33863f0beaf75ba6f59474c0aaf9d78a60a9b2f4cd24d7ab5 32e74892fd28211b31ed33863f0beaf75ba6f59474c0aaf9d78a60a9b2f4cd24d7ab5
4131b3c8efa192df6b72db4c 4131b3c8efa192df6b72db4c
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="opaque-3dh-fake-test-vector-2"> <section anchor="opaque-3dh-fake-test-vector-2">
<name>OPAQUE-3DH Fake Test Vector 2</name> <name>OPAQUE-3DH Fake Test Vector 2</name>
<section anchor="configuration-7"> <section anchor="configuration-7">
<name>Configuration</name> <name>Configuration</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
OPRF: ristretto255-SHA512 OPRF: ristretto255-SHA512
Hash: SHA512 Hash: SHA512
KSF: Identity KSF: Identity
KDF: HKDF-SHA512 KDF: HKDF-SHA512
MAC: HMAC-SHA512 MAC: HMAC-SHA512
Group: curve25519 Group: curve25519
Context: 4f50415155452d504f43 Context: 4f50415155452d504f43
Nh: 64 Nh: 64
Npk: 32 Npk: 32
Nsk: 32 Nsk: 32
Nm: 64 Nm: 64
Nx: 64 Nx: 64
Nok: 32 Nok: 32
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="input-values-7"> <section anchor="input-values-7">
<name>Input Values</name> <name>Input Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_identity: 616c696365 client_identity: 616c696365
server_identity: 626f62 server_identity: 626f62
oprf_seed: 66e650652a8266b2205f31fdd68adeb739a05b5e650b19e7edc75e734a oprf_seed: 66e650652a8266b2205f31fdd68adeb739a05b5e650b19e7edc75e734a
1296d6088188ca46c31ae8ccbd42a52ed338c06e53645387a7efbc94b6a0449526155 1296d6088188ca46c31ae8ccbd42a52ed338c06e53645387a7efbc94b6a0449526155
e e
credential_identifier: 31323334 credential_identifier: 31323334
masking_nonce: 9c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c61 masking_nonce: 9c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c61
9e27b6e5a6 9e27b6e5a6
client_private_key: 288bf63470199221847bb035d99f96531adf8badd14cb1571 client_private_key: 288bf63470199221847bb035d99f96531adf8badd14cb1571
b48f7a506649660 b48f7a506649660
skipping to change at line 3738 skipping to change at line 3744
client_keyshare_seed: a270dc715dc2b4612bc7864312a05c3e9788ee1bad1f276 client_keyshare_seed: a270dc715dc2b4612bc7864312a05c3e9788ee1bad1f276
d1e15bdeb4c355e94 d1e15bdeb4c355e94
server_keyshare_seed: 360b0937f47d45f6123a4d8f0d0c0814b6120d840ebb8bc server_keyshare_seed: 360b0937f47d45f6123a4d8f0d0c0814b6120d840ebb8bc
5b4f6b62df07f78c2 5b4f6b62df07f78c2
masking_key: 79ad2621b0757a447dff7108a8ae20a068ce67872095620f415ea611 masking_key: 79ad2621b0757a447dff7108a8ae20a068ce67872095620f415ea611
c9dcc04972fa359538cd2fd6528775ca775487b2b56db642049b8a90526b975a38484 c9dcc04972fa359538cd2fd6528775ca775487b2b56db642049b8a90526b975a38484
c6a c6a
KE1: b0a26dcaca2230b8f5e4b1bcab9c84b586140221bb8b2848486874b0be448905 KE1: b0a26dcaca2230b8f5e4b1bcab9c84b586140221bb8b2848486874b0be448905
42d4e61ed3f8d64cdd3b9d153343eca15b9b0d5e388232793c6376bd2d9cfd0ac059b 42d4e61ed3f8d64cdd3b9d153343eca15b9b0d5e388232793c6376bd2d9cfd0ac059b
7ba2aec863933ae48816360c7a9022e83d822704f3b0b86c0502a66e574 7ba2aec863933ae48816360c7a9022e83d822704f3b0b86c0502a66e574
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="output-values-7"> <section anchor="output-values-7">
<name>Output Values</name> <name>Output Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
KE2: 6606b6fedbb33f19a81a1feb5149c600fe77252f58acd3080d7504d3dad4922f KE2: 6606b6fedbb33f19a81a1feb5149c600fe77252f58acd3080d7504d3dad4922f
9c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c619e27b6e5a67db39 9c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c619e27b6e5a67db39
8c0f65d8c298eac430abdae4c80e82b552fb940c00f0cbcea853c0f96c1c15099f3d4 8c0f65d8c298eac430abdae4c80e82b552fb940c00f0cbcea853c0f96c1c15099f3d4
b0e83ecc249613116d605b8d77bb68bdf76994c2bc507e2dcae4176f00afed68ad25c b0e83ecc249613116d605b8d77bb68bdf76994c2bc507e2dcae4176f00afed68ad25c
f3040a0e991acece31ca532117f5c12816997372ff031ad04ebcdce06c501da24e7b4 f3040a0e991acece31ca532117f5c12816997372ff031ad04ebcdce06c501da24e7b4
db95343456e2ed260895ec362694230a1fa20e24a9c71e10f6eeab2a7a420bf09da9b db95343456e2ed260895ec362694230a1fa20e24a9c71e10f6eeab2a7a420bf09da9b
27a4639645622c46358de9cf7ae813055ae2d122d9055eb8f83e1b497370adad5cc2a 27a4639645622c46358de9cf7ae813055ae2d122d9055eb8f83e1b497370adad5cc2a
417bf9be436a792def0c7b7ccb92b9e275d7c663104ea4655bd70570d975c05351655 417bf9be436a792def0c7b7ccb92b9e275d7c663104ea4655bd70570d975c05351655
d55fbfb392286edb55600a23b55ce18f8c60e0d1960c960412dd08eabc81ba7ca8ae2 d55fbfb392286edb55600a23b55ce18f8c60e0d1960c960412dd08eabc81ba7ca8ae2
b04aad65462321f51c298010 b04aad65462321f51c298010
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="opaque-3dh-fake-test-vector-3"> <section anchor="opaque-3dh-fake-test-vector-3">
<name>OPAQUE-3DH Fake Test Vector 3</name> <name>OPAQUE-3DH Fake Test Vector 3</name>
<section anchor="configuration-8"> <section anchor="configuration-8">
<name>Configuration</name> <name>Configuration</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
OPRF: P256-SHA256 OPRF: P256-SHA256
Hash: SHA256 Hash: SHA256
KSF: Identity KSF: Identity
KDF: HKDF-SHA256 KDF: HKDF-SHA256
MAC: HMAC-SHA256 MAC: HMAC-SHA256
Group: P256_XMD:SHA-256_SSWU_RO_ Group: P256_XMD:SHA-256_SSWU_RO_
Context: 4f50415155452d504f43 Context: 4f50415155452d504f43
Nh: 32 Nh: 32
Npk: 33 Npk: 33
Nsk: 32 Nsk: 32
Nm: 32 Nm: 32
Nx: 32 Nx: 32
Nok: 32 Nok: 32
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="input-values-8"> <section anchor="input-values-8">
<name>Input Values</name> <name>Input Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
client_identity: 616c696365 client_identity: 616c696365
server_identity: 626f62 server_identity: 626f62
oprf_seed: bb1cd59e16ac09bc0cb6d528541695d7eba2239b1613a3db3ade77b362 oprf_seed: bb1cd59e16ac09bc0cb6d528541695d7eba2239b1613a3db3ade77b362
80f725 80f725
credential_identifier: 31323334 credential_identifier: 31323334
masking_nonce: 9c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c61 masking_nonce: 9c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c61
9e27b6e5a6 9e27b6e5a6
client_private_key: d423b87899fc61d014fc8330a4e26190fcfa470a3afe59243 client_private_key: d423b87899fc61d014fc8330a4e26190fcfa470a3afe59243
24294af7dbbc1dd 24294af7dbbc1dd
client_public_key: 03b81708eae026a9370616c22e1e8542fe9dbebd36ce8a2661 client_public_key: 03b81708eae026a9370616c22e1e8542fe9dbebd36ce8a2661
skipping to change at line 3805 skipping to change at line 3811
055ae2d12 055ae2d12
client_keyshare_seed: a270dc715dc2b4612bc7864312a05c3e9788ee1bad1f276 client_keyshare_seed: a270dc715dc2b4612bc7864312a05c3e9788ee1bad1f276
d1e15bdeb4c355e94 d1e15bdeb4c355e94
server_keyshare_seed: 360b0937f47d45f6123a4d8f0d0c0814b6120d840ebb8bc server_keyshare_seed: 360b0937f47d45f6123a4d8f0d0c0814b6120d840ebb8bc
5b4f6b62df07f78c2 5b4f6b62df07f78c2
masking_key: caecc6ccb4cae27cb54d8f3a1af1bac52a3d53107ce08497cdd362b1 masking_key: caecc6ccb4cae27cb54d8f3a1af1bac52a3d53107ce08497cdd362b1
992e4e5e 992e4e5e
KE1: 0396875da2b4f7749bba411513aea02dc514a48d169d8a9531bd61d3af3fa9ba KE1: 0396875da2b4f7749bba411513aea02dc514a48d169d8a9531bd61d3af3fa9ba
ae42d4e61ed3f8d64cdd3b9d153343eca15b9b0d5e388232793c6376bd2d9cfd0a021 ae42d4e61ed3f8d64cdd3b9d153343eca15b9b0d5e388232793c6376bd2d9cfd0a021
47a6583983cc9973b5082db5f5070890cb373d70f7ac1b41ed2305361009784 47a6583983cc9973b5082db5f5070890cb373d70f7ac1b41ed2305361009784
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="output-values-8"> <section anchor="output-values-8">
<name>Output Values</name> <name>Output Values</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
KE2: 0201198dcd13f9792eb75dcfa815f61b049abfe2e3e9456d4bbbceec5f442efd KE2: 0201198dcd13f9792eb75dcfa815f61b049abfe2e3e9456d4bbbceec5f442efd
049c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c619e27b6e5a6fac 049c035896a043e70f897d87180c543e7a063b83c1bb728fbd189c619e27b6e5a6fac
da65ce0a97b9085e7af07f61fd3fdd046d257cbf2183ce8766090b8041a8bf28d79dd da65ce0a97b9085e7af07f61fd3fdd046d257cbf2183ce8766090b8041a8bf28d79dd
4c9031ddc75bb6ddb4c291e639937840e3d39fc0d5a3d6e7723c09f7945df485bcf9a 4c9031ddc75bb6ddb4c291e639937840e3d39fc0d5a3d6e7723c09f7945df485bcf9a
efe3fe82d149e84049e259bb5b33d6a2ff3b25e4bfb7eff0962821e10f6eeab2a7a42 efe3fe82d149e84049e259bb5b33d6a2ff3b25e4bfb7eff0962821e10f6eeab2a7a42
0bf09da9b27a4639645622c46358de9cf7ae813055ae2d12023f82bbb24e75b8683fd 0bf09da9b27a4639645622c46358de9cf7ae813055ae2d12023f82bbb24e75b8683fd
13b843cd566efae996cd0016cffdcc24ee2bc937d026f80144878749a69565b433c10 13b843cd566efae996cd0016cffdcc24ee2bc937d026f80144878749a69565b433c10
40aff67e94f79345de888a877422b9bbe21ec329 40aff67e94f79345de888a877422b9bbe21ec329
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>We are indebted to the OPAQUE reviewers during CFRG's aPAKE selection
process, particularly <contact fullname="Julia Hesse"/> and <contact
fullname="Bjorn Tackmann"/>. This document has benefited from comments b
y
multiple people. Special thanks to <contact fullname="Richard Barnes"/>,
<contact fullname="Dan Brown"/>, <contact fullname="Matt Campagna"/>,
<contact fullname="Eric Crockett"/>, <contact fullname="Paul Grubbs"/>,
<contact fullname="Fredrik Kuivinen"/>, <contact fullname="Stefan
Marsiske"/>, <contact fullname="Payman Mohassel"/>, <contact
fullname="Marta Mularczyk"/>, <contact fullname="Jason Resch"/>,
<contact fullname="Greg Rubin"/>, and <contact fullname="Nick
Sullivan"/>. <contact fullname="Hugo Krawczyk"/> wishes to thank his
OPAQUE co-authors <contact fullname="Stas Jarecki"/> and <contact
fullname="Jiayu Xu"/>, without whom this work would have not been
possible.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+y962LbVpIu+n89BUb+EXIPyViykzhO9/SWZTt2fNNYziRz
+kybIAmKGJEAGyAls7Xdz3Ke5TzZqeu6AaBk59Kz95n8iG0SXFiXWnX9qmo4
HJpNvllmD5N3iyx5c3r8rz8+SY6356us2GSz5PT4xZPktCo35bRcmnQyqbLL
h/KYmZXTIl3BT2dVOt8M82ozH07n1fmwXKd/3WbDwwdmlm6yh2YK/z8vq93D
JC/mpTH5unqYbKptvTm6e/fbu0fmIttdldXsYfIc3loV2Wb4GIc0pt6kxex9
uiwLeM0uq806f5j8GWYzSOqy2lTZvIa/7Vb4l/8wJt1uFmX10CRDk8B/eVE/
TB6PkkfltppV2d/oQ57y47TIs2X4TbZK8yWs5n9Odhv4+6jKgoGejZIXVXo1
/dvuwhvo2fa8DD8vq3MY/G/pJi+Lh8nxT2f+4At4/AKe/p/n+O/RtFwF73gx
Sl5mV7k3/ovsMi/ch+Hgr7JN6o++hMdGF/iL0UXHG05GyfEo+aksZ95LThZV
Xm/K9SKrgm/Dt50sy+1svkyrbAAHNR35b57CkhZZus6L80m+qUdwhnDOcNrV
Cn59CUSQJM+Hj0cXslMBodz9+iGN1UKJcLarbFPl04gU6fG0Os82sKebzbp+
+OWXQGzppkqnF1k1yrPNfATT/xKI9MvFZrX8kom04/0GBnxU7rLi7rfBVA6e
4WsfJqdpXSOFwtXYLOBq5FPak+Qsm26rLEnPU9jcTXJSlXU9PMs3WfJjDXv5
fLXOqros6OEDGtiSKP03lD/lcH4e8Szsp3w8P6eXOYzGX9F3MHie1bi/cCzV
br0pl+X5LoHLkrzONjDTC55avtklvZPj12d9+hldxwQvHS34+7v3GxsPNw5W
lzzO5/M8Gz7LlstVWiTrqpwss9XNK8DbVpVX8Qrkur0F8g4fiH4OD3yfLtNi
E/3+bTnJqk1yar9u7AISAdBAtq7yYjPK02lFxw9rvf/lPTjgYPn38fcnKRDp
Jr97GJ74jwWQa1Wny+UugcuzLusUlg7v4u2EG50U2VWyTqt0lp+vEiDxZEpH
cF6l60U+NWsh0voWJw4LlnnEK4Zd128ai33+5MmT5GyHk8u3qwQI8Wm5LWZE
ZnVSzpMTmPgWWGlyNs2zYpolvadvTmIiOKRdWGRlEV1ASzppkS53dU5Dbog4
qrI4/2zi+GGETJTeGK32hy0M+yzL5MvGgp9sq5I2OVwB3dvHL49CMj7ondE8
+0lKTOMtMMQa7iTIl5N0vYGlwctebZebfEi31FvuLDlL4fPi/BZHB6T+ON0B
YV8s48N7nBUF7Fr8dTTAMTL7BexgvBvHxX+m9qtWSq9bSf3o/pfffBWS+hGR
+tMXd+9GJ1wBkQ+BqwHfBzl/nhVZxSwNjjrVgwair7JNMq/KFXy4FiZ489b8
NAKClAfdsn5Kq6t8euF/Ff3u0Sg5AymbLvP6Ih8kP1TRCI+21Qa5bvhMY4d+
evLu+cmTkFTu0j48Pz2DPQmp5ezZ8fBecoaaRoo6yGlWrbYb2ozho7SG3XmW
1gsijicfNhk8BdQ+fLPdwA1Lnm6LKd26g1aRVFwu19sJiEPY5tF5efkl/gU/
+RKn8uXr52fvRvi3EcxqtJ7NvTmDEjaAiR9+tXe74eAfJq9psukSpHINq4KL
j6eoK6pp6u+y6aJgKdHD1/ZxP5798OKno3vhdqioG3qiDvbg3cuz5DJPVTDj
kKdlvRk+g7/Vi/Qii0TjLS4QsoOsrrMGL1jCe/xvot/B8f8ASsj0Ir52uOK8
XqZX0ffR72NFzg3QVOYaPz7x1CP3Q1+Boq+bHOzHt29O3v776bvwet7DJ0H9
Tc+rLEOlG5jHm+ejw7ujr+8ePWACOTsdPbh7d/jV18cVPf7Di58PH4SHxqeC
nKNTZVJd5Vh0ldMqG7KY4Ht/vNmA6iR0fAfmnhHL/+u23GRAQpPyMvsTKBfZ
DIhhkk3TbZ2pWMhWk2yGn8NrymJ088n/Q08QyO7nbUxzebrb6sc3Cx6wbPQc
nm6Xy9/qLEBqw+jJv4E6Ap/2//tobikHDx98efj1vdYTgyP7OtLw8/PFcjfM
QKVBXWlDrM1T/FTqDVGty6bIC0UsAtsjVaIHm5ksyqtkUybyULIDwzIBS2ha
gvV2BcokPF8Wy7zI/vc4RtBNXsDG52kd6ybn59myrKNv/2FEQJowXtJ1Bppo
oBIHat1plV+m011IE6Q+vvz+7VGoHJ2mFfwNbhwe7hswKIEK5Ea2CvkWRezu
l4f3vz20Ev0mMfiyYfKxEHSfR79BQ6jaTibx6Zym22X4TfTDd6PkLap8Bdgv
sZH1blGu0jr8/tmrf/236L7gJ2AELeDeDMG8JRMfTYyaeVrTOCCWdwt94LZU
0yACkqtvQn3vK3zs7Pn3r46HzyN9Dz9kY/cL+HsxBPoYvjqefpEcr2G26XSB
FznUfqJFIUXlmxqNfJg63dDnHnu/jeH32YtVqru6unIkxwbobPJlWk0XYL+i
3XvvS94XJMWv6H+RhonP4Pjvqny9zB4/i7YpX62X+XxHl+Dd22SWFXk6yZdw
ow46J1Xn56CH0pQmoGvCv+0gw3JTDb1BGlcRPvhpkW5qOIUnR0/aDVJgh0/g
tDbl8Amq4wWtG87nEVzO7br9euJGXeHA6XqN7rAv1ZT/Ul/3Xsd/b0d8LyO+
/2kBluM6BUK/3W3WMWPbRz/G/X5zenp2Fu62fAaGO+jUq7zIV6DOW1X81Iqe
MxY9ZyJ6JmSfALN7t6iyelEuZ6Cgv33aPCB49TKHR29yFg2T45PXZ3gi34QH
9M3/f2UOfP726clXD74m3yD89cHh0VcPjRkOhyC1a3Q5box5twCLf1ZOt6jF
w22pp1U+Abm+cd5M5YWDBHmIdbKD/pCkVlPsG6txpAEPAishyT5MF2lxniU9
cm30YfQUFJHtel1WwI/Abt2mS5OGTkrgUGkyXaJyM6zJ8AfS2KCXI7nK4TzB
jK0yEDfIxOHx0xfPkTYMfmfdXtbFuQZVdeqpqqmoqts1/ENGx++rcpXX2cg8
h0dmMxKnA9oL3QT8y2UO+4QetCuwU1mtmjJh4pPCKIAbmwU8yL9WRyz5JMgn
Re8cJNllViQzdu7Yp6rsPMcDwtePoiOq19k0B67ORzQtq8Y50UzKAnk8BiI2
OY1j7KW79xiILhwU/p7i72dbUAJFeeM7h24PUEzeZnWGTNp8X5XbddI7efr2
+74VIm/fPR0xYa3y2WyZGXMHYyI8Hm739Z0c//nRGOuSjk8bzmKS/3Wbb8pt
jQODwII9xfvPT9Sj5DlRRLlawWqQQ5PlmfIZKan44+IelegW4vOd7OBvxQx3
GqUgP2+eP6b9snsPv3Dnk5T4v1SVhGlZFBmtSDZwlV5ktQlO+HK7RKcU6uAw
lAwDRAUXYAaK9PkAFjddbmka6XQKFAJrWC53BrjbOX4YjAZ3DAz0iueM27Je
AkFvsg8bvh8YPMCDHYlvzDgiBiqqt+QVpEen06yuZXXwpRtH31XjGRQlWhJm
W/A2u4sEk6apCsWmK3G00bdwtYp6muPJ+bGXemReAX2WROjNF8YkUPIV552G
7SqyZQ1MAhQbYJ7oyEEqXdZltMVTWH6dXC0y+Bk+tUp3yTzNl/5GA3MwcuUH
yTQDRXlOBBIezCarQIbJZLabWm+vLtOAOM2B3eFy0DdrLzq+d2h/TRuO/8pm
eYqybEAUtoKtgFtyHDBQZ2r3W6M18NgLYKBPIgbqnPUJiCZk26DBZDMx5ZA/
de4y8khmuMtdsodV38x+DbBf0rOE+/bgt9l6o9xM7qPPy/q0EfrzWV5PQT76
nK92dwZJKSk36JrCGW6Q4/E/QXgw35EbvALdFyzUEWj3Qj3sQAfFYguahW4I
/gIkG9BfWcPZecERCoakVoBZRoocZwaGLUZtV5mVGbjj8L7LfIMkOLAkyoZy
kvvRM/xRtloDuyG5dL5F/+BM98Ytm1j2fI4DwL4Qi0mrXSimmN/b680ebz4Z
/PkySy/Sc/oc2JsBoYT3NQeFbJ4vM+KeOMISZ1TRrWHJxu+Aj2CAqkBBsAK2
S+c6N0oCX9SOoLawKcgUQcQMr/CyiTOZZrHFy8g7YscBSXiZLnNUymDzNzIr
3guSowHPG4Hk2U5zok/YS9AQUpJQJn7QCTwgGvQ6AFlsC5D0uIHEHXSGMpGR
eYMEdJU3lj4lk09VhAwZa8b3GWg3nyZL+AM3FgfKZsadG+zZjJcIrGkFWrAK
3bTIkB16h+J+hKdpWpSOTmWMBTzrX0TapD/Bs3UQyDVdWk4P7ONZNs+RRcC9
vr4mH+DHj/2RpzsEWo1RrYbIFiTJGt1DyF5083VlVwugLubLoO40BBgqPObT
FB7rrF8uy6s60AEMzAC4epUB9dJ7ZmjhTkHMkZElNyhpuUEYBACTqEJGZxZp
vSACVw4DnG8I7882U/q8ni5At6jtTFTwZBhIId4x4NnBw4YvCHOudA4skSR2
RrehQtYOKwaeMclhfVWg0pD0TqwCWpttzewUxoBp5ZW7E8a4qehJktoC54bi
uLbcARiqBsQ2YF1l9nrCDUQm+tAAFZWTZX5J8npdZ9tZWcFYoJjam9xDc6yP
WhXKBCAElM1wjzIUDnm9Ghh8OZkD3bo+afoeL93QNZsgKWSFSZHTHOCMgX6q
A2YDMI8aPTOkHIH+V2+ZySZI9Pa6g3QtrVJm+Ea49/TOYNHX14FuAqTNxFV/
/EhvqjJQNStSIDVMbHDNtKn+ePWon3Qp4Khj67G0q9rX1+ql+PgRqIloLXiU
pYlKpAEeJIrFLUmJvDDX1+kSsUWwvUPUNT9+HCQTsHyYPIBJgaLDY6A9BAup
p+U6E57qzZosGg6XLpn3rUA5X6bqnuBlfFGLKsGKLaqccNNIw0GN5hxvDxtY
ahwBHw92C+736Hw0IEUM5oBet4EV+kBfG2RXsG8sIwzRbQl32e7YGj0Jf93C
BoHVscHoHxgFcBXtBaDjrOXUrkpEfpwDVQcshN7YTZq0GbgH87wCjk0jeBYE
j4QaCJoJlkfRCjzTAN9BN712iCF49bZmPUwuTax+ObGM9OONNwIbi34hLLTO
jP8sXh1iDHB/Zkh4NJ2LorxaZrNz63GPFAsr9eE2lKD4xUslaR2s0ps5n4w/
CVrydlLD5YGPwGah38P4KyTcvMDQMl7NIgmvJF0geneywHvviMdyFOSfKL8u
OZYB9grir5yEJsOZ1Gr8RpRQ/zjgvaRRINnBWuFoV5Y164nCyaAccEe/Xni2
E2/yliQL2nY6NeXs51sUjN5YOrw6Gehnm92aTiMr4OJVvhz+Dhkf3GhZJToX
Rb/2nhX+hMaCcgJyAhh0/KKHx5dJyaIEO2y3ohs8JD7IdtAb/BrHeaOMfpTo
AHiR8EG8e3DLC6t3INKMRMgSmZvd34BV4pgBv0UdZIMfw9PEr8TRhPwu5JtV
BguvWVSSrCrgH/W2bvM3GPU3JL6/gWSINVKT50/ePbVOC/Jty1dJLRgCWNqd
O3CvvAW8Llk34g1FrsA62cGrH8/eHQz4z+T1G/r72yf/+uPzt08e49/Pnh2/
fGn/YuSJs2dvfnz52P3N/fLkzatXT14/5h/Dp0nwkTl4dfzvB8waD96cvnv+
5vXxywN2qPibhpwdNmWSMe3DDiIzA2NDlUNS6B6dnP6//8/hfRA3/wTbf3R4
+C2QEf/jweE39+EfQBbFQBxDwET4n7DrO4MabVqRubdcwg1Yg8RFPg7kAQbU
VZEgQY3MH/5EmtXw6z/9i6Fd1Y1Mru8U8tePvKnzUlQjq0+whGLOuIADPSfv
XbBSdEwmz4/enJ3SLN+cHT0/Rb9ycYkIujRBcCvie1TZLmaK7ynKYlhk54TX
ZDGFXBfdrcEenbHjJrmP9HZ9/Sfcm7uH3yCdwlIyVqnZN+KmDbIUZV5CyC9v
CuShmuTnQ/QnoVKDXwEdARuHZQBpA7fvfbg7SEYjEIYfXvdpKSiJUJIHIxHm
CERTig6tAbxmLD+/++Hu4SCB/x/dvUd/3r/71d2v+8kf8e+H+Cl/MsZXsgLX
K+BF3zMoCo2YAOBHBpUYDIHW528t7M0yK87hMo+LMX1T4/B/y6oyq+Ph3W/s
w0REcN9SMsruJj38ZR+H+FBWvXQw6bNTf5f8/OYtUXbnViRj/MndD0/vPr2L
6z88unefV//k6OT+GKPJzA5g/7OqKit2BsH7ibCsLsv6SnW+tcretuAZ8krp
xDbv6SOYYYJTfJuBolIk4021zcZJDgtMx/gqu7LxZMzXaQ6XJWMr4oqMuIQY
beieZBbnT2q1BXkxYS6I2uBwk69sUE5OoKTXwoD4Hnoh2FpoWKNxUdewnpnw
BhQ33ooGSV6JyYZ3QvgrmOAgH2VI2C0YEfjjE/bZwBLrNJ+5hQyEpJLposyn
WW1Zk6i/os5U2ZxkrwHpcWXF8rbIUSFCAQYnC/oqPirX9TxHgwWFRi8fZXA7
DvhFB2TPLkCQkKF/IGMApcj3wP7fhlMScwIEyzKdZqpjYkQJtWFQRmo2P1sv
AkMFg4sgcMISrNR0OoXrLMwmloKGbGjkrvfvPvgaVXKYcKshxRQ9RS5WEKIV
zjATAw4uTb4cI59NDcz/As+JzgidhMulM3fAEq1RxxWNswJxB3c4sOhDobEV
47jeAf194D1Q9nfPY3/378PkUUaK7JX9SR5na+BrMF3UA67vzLx/frR6OH9q
lVjH9IO99vQENlfzVY5EWRO/t9pJcurv3tPQDP0O5gtvq4flupp//Ai/Q5fo
4wyxEfSYe/7FY+9x61ql37ziXYyh8CflDEzVV8cnXb8Lt4Ywlfo++wv0J9iJ
nTk/gjexM29i8jirXbUcTBB6q7POjaPYCGmHZPyNkh+LJaq9eH2Nd32REcp+
goScKvlkGTqgaiUbfJN/vjaKVWXk8TItcUA2N52geA3Mn1jUaxxdBMEgcRxo
uRuwXmro2T/aJ/+Y3DtiHe0mSiAqFAqA61HcknRYSwYzcYjAkJ1bwiTbXKEX
QoNGtDVkRxAwnnxo5IRIYBiZPe0L+ghQa4SBF9lyhkElZ4QY3T1rCtHV0DnB
b8TPZn/H7x+x0JDJzEDUoiJryCGLfpANUVM6Ya2JJxH5wssJUANyA+Z8A3uQ
MjNx7sKw0VjWv8tzFh+rnTMPJ0HIkPdHHABJNBuSEkTRfJZtlUQA1WsyQ5t/
vIJbh8+Mk94YtJm74z6LB8ulRofMp4BNfXv/22+ITYW6Jb+Cd+z49LlTMYmz
PAJtddbLWAaj9lVlpLMUukHw4gk+A1KV/5LN3svj4/5AvQyi3oD6yY+A5LRm
jJXsvHFj/fUAMSclqumNgfFWliokU+b2bHGjlguDU4wCf0Te0arEmF083lgM
K1ZHgAcucQuE1mjd9vS6dOB7o7YNHiZPc/QS/i3TjRvwZNBpC1NFP8p7t6X6
sEAF4DTkKfaCcBgs3BncPr6nOen1WZXYU8Cj8QaQUxo33gyP7nK4eXQ08hCy
hff8jzFrYF37YydtCfwTNsiLZm6atCj8o4MWn8g6eheDJCIL2Ev9Vr/SnYsJ
iPfVJPI9MqLxRcuOyPNt29dBPUJ8wVw/Y5OUVcKs8BXCFy5xMJwsph9RABWp
jSR4BiLzNM2rXk2BNvSkdVzXGhc6Xl+0XU99B4nKLezalF43ozfM6Bp44RxS
AFkdLXSnWSCRF4E/wJmM3YTZNdu+DUdNSiE6Q7nXojOzb9WDyTpCQmwujM40
RKgEeT3rS2ewHiLfJ3yYHoN7la7j68bgh3n+IZsNRVaTtZVWVbrjA6jjASfb
OVpoHLTEAVZ2XPdboMvtfCyePqL9c/LSyIvtDbTkg4p6lWLQMg1eSlYbxTYx
YA9KLbnI7M4eNcgLRnbeMXZ+40Jel5oGiFdbA6P8klnLDJWoROaEe8ADXkQD
ykJ9YgaC8McJyJm1mi49FY92nz4q2o5TREHl2a/0sqJjN5ydGURnFLquy201
5dBwkaMvF3OXkeBWsBhcvovd5nTsfHMowqH73WlDwVB1q4JA46UJzM95Ex2t
A5G30fiTD4RM69XpEuRPfrFC9sif4UX3lT08BFgSUbjTRj+oK4LsHo9VBusd
w8h839GxvhZ3tO8KGeMMyLny5MMaHuytqwtmUIPkJU1qTT9vzmkMTwKvYhko
CYg0IvGUAc0JfQgvdaYYumRKiqZJtPiBSVGeUIrEcce6Wf2xp2UW6rdpOxOK
YwYcKBWZPKRQXzlBz8Qe4jRkLKHPHKNs1UU1XKXTwGstQalSzNI1otxB+WYP
dPPU8ZdkZrRM4/hEvB1CN0wi8HEPnhokq/qcPGsatBdLuRFzwTtFIQ3hkPC7
sQRQMkT0juEPODD2JbPaH7BN2Xp0yLxeeW6x16vuo8FJdhwLcIbAjqz1wpNh
2Hps0YmBCbPMMTAwBF00Jw8SRlYWkdcruHCm48LhVHq8k+yZi9wl0cAUC7S7
GGwacmd/22b5OVuRvDPj1wt/7xbde0dTuj1NR5uz1whXJxrxyxp2hmy27MMa
A/uX2d6ltzMxlsz8vmgfkZQ9WIG/h/KxZy0yVSI8K4H3ghlVIC/W2FI3tGEU
CVu64QXZ+aTW1bBJ9XznaCZRmplm5Pyx6V1v4Ipc5tkVkKMaysNSPvv4awZg
GRvw64dhEdUZwp7iGGsQDpWQZI92DEUaxScyc7Asz/PiACXfAYO6DvjR/sAP
skqclOcXsZwOuWok8wR51c0YPGYVZ9lmuzbmtMrZxT0pEeBMmx5Mx/NhUFom
Lj3lUOj5Vo4F9QIz35LwDnHEAdmny/Oygn1ehb6hIkN7FEkPbdYtbaVFIrLq
dn0dvFDhFlZXe+cObrooS1YQ1qAwITWhIoGKPn3/XlSt98ib2b+kX5CCT5/3
LSgMCIptSDcsqvQwHBmHpN73mYMvrIIgv0XNLpyaxIE/ZSpMmCtE3K6XmYae
Weh5wxKtlaxbE2aNIExgMiGyBCeMk8owm0fQjeQl9z9RtzdmwRPoE1YK3IXw
jNmsj2DFhLwMDArakQRdIfiWHEQmnWK5D3HyRVdWIIyEnhQKw48vMEQg9x5n
oHNU91kPJjDN2JryHnM4wsQHSRFrmhI2E0FkiYeeMLGRdWO0vK8xXrcSY/x/
qRlKcU++8HmhLk3Sk8W1X1s4ZZjBYASLzAdM5C0cRrP0GBtDVTaynNxy68Wu
RiV5gOJtWM6HkxTdKKcvng8J6TJIgPmLS0v2kIQA8xIPcmHFFUGZs5AVCm+p
DE8ILnMV+/38YZ3cbx3VWTYkEksBK9mzCafrVKKNA3ewUGViZOfWGCRrWW34
hmiI1QF3d3QHCH7rYHFDle5gyldrvMyKKiLMmEtORl6pcJuMU6CMhy3xUTlz
AdITFjMUCd4FVc8ryF/EnniQ+bw2/lJkLzRJoHMvUERUmP5K8biy8CNK6ng1
wS1kZOdGRJqgsCOZRk5EQqfzIcnlCgaqcbMKysqVyQavmYP+IgG3K+Qm8E9H
OuJ4ZKyhdxk99Z6xHv6QQ8LSfPwI6tDf//530Dt84ND+/xxhSi7T/7rhB+6/
/yW/uLz1Ly7pFydMxbf4T/Iq8K/DT/zPxGMFR4BsB9Tj8KHOsf7lpsGQvLyi
FPTfH24/NR1z6hdAuc2UPnNTfusjdpf1xsdl0Ui1eFGAIbmIa8WYKZD4vkx5
y0eH/sjwYz4E9mab6Dt8yTgMixHzySlAvGEkGSElK2KJwLkkuUPDvPGN02ly
EPdO8kakd2f6iGGNm6OOVgH2dG6OIgUSCHHxFGjDSLzFvplIDR84bdh3kVk1
2PlCVHrxHvlowqQdTSjanQcnPK4VKeFvhyEGFKjEXTLVJQb9OvLUPhRzaiGt
Pfx/lDSEak1mFcM1CPPvSx7Tgz1lc5JEBbkemzk2KaqoBB18z76NjUv9ADlF
4t84B/0KlXrcZAn3JQ3p1pTs/viG5kIzoyNMbRahrvLHNTliEBbDCXsWPGnN
FgJ0GAEv1BawEsuxPWZli1T7NHHU83UkPrz+/+EyCf7Dg1fX2eFny6NooKNf
Ior8ge797y+Oeu4Cg3nm7k2/+bD37U0S6cWTQ5RAL54cSfgU/nqvTcLs4GJV
FQEOjB1I72dZTLcVmZ/Zh2y6dXC1LMz9UKVQgBXC8cxNTh7LQEnM+WzQk3O0
LGMhAmz4pRdZKOHeOVhKBHgK09bVfNA11pkYsziuoGZAlIo1qSLq40dvGCyL
o9a2Y+m+QQEGgcDFyJor0MfMMo1V91loZmjGk8+pB5IiRBsMP+BHDDmfRkm7
dh0tlT1ngSbI1oecoE3dJ5Pu+prt+47BRCeIPFmt49H+xY6ecPvIT6yZLhZD
xHqAdXmY0O/UQCI5dswwNT6SE3ckZ2LT4cOo6bxVcr2+E5+vdWBG7mKLqFMX
4PhJAVenXGdjDoAW+IIGNYgzy31O+eaoF3i/J8088rHUBJrJrW7jcEdGLNQR
aHKYJwfLIGIY+M/xz4n+w4l6ek9d4vgoTTWXA+cVKGRoEG9dHRi4qgg79FLt
KI96DV8HP8NTndl83HxO+UKwJ6Pk+RwsZ/2S8FGE9CQHHbr4qg3wPpwGqw8E
swfVNt0uaSdIobKRe1ZAnJsdkypqykf1suc6bmbKifqU8yUIDN4W343HsQe5
tjZrxtNcPb+iR/VuKOv4ax/JYRC6Bmp4EMOB5LRvMZDMSHf+oa9Q6ocO9IEu
yDZXC50KhibF0wIEOMQayZisU0laDaXlTMstDIwiSM7cZcQhfmOjh4q2fOTp
8A/Y7UA4cVWzGxMHEpCwcwqMH/2ZNAl1DQlqHCvlEDJ838zCmxfOS+KajsjZ
g00xW4/GJjaBwc4UY/Rkzmyc3PFIVLVZTYSQizc+QWQe1kVwXK0ee0wpiH2i
RsBfJdcwpW1ebB40KenPr9cX//Fd/L1O9A+Ho9HRXw6/Hh7+i3smIqLgmY9J
2xy/s+qJCz0xbKftaQcGREPixkUz67j5so94S7rfixYvWC8P2y4cs9XPvnBd
A30yC9BN52EsFiGamKOzxpXv+GHMA0AAkin3kEaQvXofGMZp61G7g4Ex4BLt
Oedeyy4396vD++QpwdHGRAvuY0Ujioz50ij1LzIJp6Kk53yGt0x33mb6kFy8
4vP41ckf/5gU+dK0zCr5Y5OkeIxotv4Yja+au4OFm1qPBx5uPZ1rf3bxLsdb
2TYL+OyjIWgrZb20vpxvu2CaPC0LM+fVRmiHLrD/qu7MJWd3gfp+NDAuuC0j
vvXUBvQQnAQaxxQdRoJS8lGGIQKwdo4nM2aAFtfEk5J4Cj70sQZBoQRcHul2
FGwiN9udRNUujPoLw7q+k8mHQ3tZProcw5ZV67ZEGuPN7F5f9J5g/X9+XXis
HnX396Cw//n16j+Qceu4wqzDn2I5RMbcLHfDmsTnjHMFInT/wEZZtE5opH6O
uIcFvpkKyEYmBHysv1QvoPV4aqVQGQqhnZwDbcbhbCXw2io54nM5kRPzj8We
ojEn4nqaKso0OIDInnKgDyWQMRod8KQQiiE/k59FuIfSxjZbJwBHIvyR31Rk
58v8HIsBYGR9IsXESNWin5VTMNexe4i4zKTITZUNJSBvB4Zn8EwZmYO1/+MN
HVDCnHXJiSylxXlikykEgZTvPdet97FXpOLzhKxAj/8LSUdHjYH6aunLk4ed
6oD9Fa0rUHxXaX0Bx8LPoqbNsUskBhvSDPJKLBEinKfE6r4cGMXbA1QoRc0U
KiQrayagE+7Kd0WlhZ+LL7+jSZKYJ1LotRJAh7T5BPEdEiPINklhfV2gx9Xb
IvhKAJitMzl4xY/CBTsYJK8X+GtiRvRTmtW+n0uybTgbGBWDKDhkP1BWeHgv
tvT5L3hCg3S9gkTd5w9+ytKwZXTCiMAnvfctihmm1+6RkvzbbvWEvdj/aN1Q
zx+lDk8JoZhKEnbP5D3R1pngJc1pUYZ6D2Rjr3UPRtHs+oPkyB7ArX5x2xfF
q775RU2lL0n6dJy6B3jT9K+sVLbtjm5upDX2PBHe5IgBy3P3p69qpSe8PeXS
Cm9Pw1Th7aqUoGvZE+DiaSXPmZPeYxnWKXpGFT2W3yz95KnfVf4JY4/l3ycJ
oX+oKRk719rt4aZzrWXRn22X3lqwccI7ejhx8rqbSnSUkjIIVFJSzmrJtLfe
ehGR8rvbCkl3qAGbu5XA/HyhNvqthdrotxRqo08Qam202Cbl6Nf/J0g6BK5j
he2bpF28ma3r6vfZc/pPthyG/Zky/UHwRo6Nc2ZX603yxEP70bTe9oZ8ENQ2
1qwkCG/ru8ZwPynEhtOZcQK8w65oaceZ8Wqz7tQr2zDKKDyBpbayJVbcoehT
gCq9vtMSnmsB2mnYlP5E4Ksz8APoB+NKTJhdwLOjEIZeD9+97xXlJN4Je1gH
7v+QhzagtY0IaAhrFKhL55Q6Ihif4Ei103vvEDfoldhS0bfEfWiHsKBJH9Ax
SGwoNrSbOsMjVsBFgu12mzRMLKb8IRWdzWbWQyIuqXVWCVyZ8wY5R66VPKSE
6SIrEFNfu8JLIX7l9ugQ+k8hIp+Kh1BURE/giZKtjJYB87sWHFxPqbBvOnla
K9pxH5jDWExjx6v5SzvPm7hpxFU/gQ/rf63keutfW5LZu0ltKM592Bk6qCmJ
TY9rwo5povu+47r13IP/uCTAZ/1U1/d5v+6wlD7tv4YM3XMYTSzsPoIlSdWJ
0IyBG4J7Ub5GbZQsyoexkdFYtipZMJjNtpwHzj8LSYywhx5mkUo3YU2iGb8d
A5gb0XxnFmNjSy6WEQyB8elkWvFOjZNy8p/oHOa8k7gAdZzY4pfCoB2o63Ka
Ew8ft960MWFYxtEBjpMeohAUUNKPqrnZqlcuC4ixuW2ZPVFzhi+otuF2zVUi
uWQXpe9MiL9zD0pGgfjDM75BygFOJNpLKIilyptak6VuSG6x2U3/Ce92EZVJ
tsjpdPM6qijCdLH2QVyZ2jsozhj3mcYwD86ZooT+yzJnKKvFx5wvywkmTDeW
KIlEmn3AmTCwJ+mMPc+ZE30i0Ze7mApYB2o9DZiYwe1jXSD+nTGPMA+umftG
mpstN07WLCVJEAIliPXDPs5LDsePDIf95Xd5VIdTsteaINbGhTCBre7bDDja
EpUIel8SlhKRZbw6/ndbvIsDX0HWCY0x31a0nr0JM0pf/GNMqR5ukbMoUjxQ
ZV8pJDDSaS3ziipVYeyGUOLkQMmZjDR1txUmH0PhfZh8/BNmJRamqGjC2Z6S
TS3YulFH8EwLqsj4f35dZhQoa5m2xMyiX7DCt6e2RNebXSWW8N03oTjiufHe
aUAvHvQ209urtwPVquPGuynETq/y5dJnaETrccZg1/Ib5m8EUvEchH9+vaAv
rKdLrdDmZiCxyFZ0ALPsXWyuatDIyzJ+JJkqOTStVgw2epOleOftAzhB+MZ8
cvjGRnCjxXnuTx+rEd90v+BAh27xCXfd6Rq64MbVNK2wV5d+Me60KRDZ3K31
jxnQOt6j5WpQuPMNsFIU5ectqSSUSBBwZsZGZ7E17Oo8Bjn4JozpYoD5eUGy
hdzK4q7goqVR1DcJor7HXnYwmeOuSUnu52PLGrh6tqpuNH6AkGrdBevp9jNz
wFxJUez6BVGEFmwIv+mD8LzC1nxM23hr6LmVImNaY6eepsu0srUwQ4dtYx+p
4lShhc9QTvsYpb3WKnpVe/LyuCYXmFBcQ87ZtkksPeCZRkWmeBxjTV94um0n
ONASjUyxFec7i2xxFzTpviEIgKYvh0DYQzW8PhLRq08qOMW23MRAwdErYG51
BSJYQ6qgCPGw8hUwt7gCmrHGDWsC1RUBzqK6pgkhHNoNB9cOIVokGXgMwhf4
hLeCPTdHrHQvSPQJ1N4RImoDo3b5yOiueN4xRlCpiu0KrQuywo0R+K70vRlZ
e68XUhWhRXphbX3xsGEgouAxOJ7iX3mx7hu7ICTpi6bwVsdFweRSc1VBqdk1
s88Ij9bqX03C8n9+oXXggl91sojIq/QZ7qKOE3P+n4dBKEQiId6piMu+Y5yD
N/Akx0CwTBmFPfQ4Bsl7F8L3YxkD7e89DL47IPdHxLJogEZhONmQUcSoKAYR
1xhU3mlrHrr5tbDHhg7bxlabBSg59Gw9hO08kIPY8QsCZGQA3vQD2tYZZ7nt
Hm0D2O1cvh3KVjGvFYyZWNSVVgSwTgGXANvSqE1tTfq9+WUaCnOzPUv4VTWB
G4T6pzGLf2h4W92r8TTpGH95APoXcD7iYbfy8+ph3N7/ejsIV8vFb2Ud/NZR
4yLi9fdqt3pu6+bc2zmARQu/D8fRelzep6SKNePNNiDNlfQODiwD9n47aH8R
w2c+D/ki792DsbP79svAdszSiFxjNkkfXvuQ8Pgd/uwDRFCM/mmJQjDjZMda
lHjo1YTySlHbmr+ey4vcVhR+vbG6AfDg4DUcbiPFBfQpGJx+b5tdqWJ6Tx1d
cZMxqo2D/BSLaalD6qHpzLuVyrf4tX58NLY1doLUWKrzasvaPH5ms/1RbTNB
bXDPmo5rqtt3u/Z9sHVwfrn1IrQ0/8TyX37zYm6B2dOeyjkQe9zaGHHHWD4J
G22CjTmzvoosvczqWVWu0R8+MLa0Hny5xcZ8NAfqQ8Rbrq/rj/ZVv1en0p7c
YntMJAc1q5kZOvVyxb1ZZMs1xo7VTxE0okKTgtrlsfqbepnQrhNc8M45wbwV
0t+cSl5HM3a5B02fpe8aBl6dwrWrFzYJODBU1Jnblg9sa+hlxSxQB6gxIGcX
NJqEBSU4uJ6cm6A2prQ15HqH/e5ydVKwuOb+7rgvOGTvqE/t+1TQBplcfh6d
3URZNs4O+/HCsBd46225Eq5T4q3vJnDCbfASt0ic/A1hE3EyqjMAb5GGepMP
99Ozz1rTL2+5fNWSeIxWh77EBvdWwoo8+N0AkVsZv/tMX13sJwE3XNnHjBpx
YJUWKY7ykLKTqHKD3gUpLcyyzOU087+x/LLjqpcgB7WbdcT4MToXxBCtUmlu
qJjG1amXLpWpLRakYFptehZFn0JRzOEyv+KDremTEd1zHPdmpq3RNtfaMsgi
a6kl7PJtjdeIJyhTY4/F1qnhNbQcjVdBR1nzF3rIlpv/F8LiwC4egu6mnbdA
wbgN4gZ/9SlwG3j+KHjLUa+hWzZ5V7sp0eLjEgWx9fGbXCYDXMv+pUblZvZj
ZuC/3kV2T/0AtuKKqLgBkMbtx71ebE1+MoIT5rl/Gfc+6cQ6XmrXw54UmMJT
7HywwDWLVt4RPNeKjNi+jNRIgn+gCQsSGFvcERcnMPRFlq1dBMIEhSWQD/jd
dAc2kEbDhDVU+aOobE3AcfndY751ZzwCzpSqNEbuDmyEcWsNgExL/l574Wnz
FdughA0cdomOOSTQH3vqAygqvAQRfjzL44tMJhqkk9qyyvdmi1hvkFXygd16
lbKJ8Sx4lNvOgqjBL5azkUoF2RobYVdSx1hyDUEewUcokdL5JpOe7Mo21WPl
0I5ewZ6uXld7ZIbaXdpaiZpiWwxT3Asrrhpks2w3C8+jpA2fLcgAacIhDFru
hco2QmkRKEjf5aGyzC1RWZ2ILJRp8JQDZIGyBZxxKF3EuUaRdIeu3dWM4rDc
3pp+Qb46WozfS5jV/pgMvJGpfE/UCdM18CzV1WhuLe4xEI3qp4c0Cc4pqEvI
MWLXJo9gJe02d6IlJaT83AXMcW1U2bXH69fbcFUE2VBvmIFjh+PXSDLHmtHx
4ILTnoG/dwSJV/tDyEc3ICVasrsbPhqyvixOxJtgiImw2d7cG1Fzvj3UdFvW
96gFU0EvjDAm6n+2rMKzPWx3DmkAsL5oWXZjw319oNIFJf76OBnGfvcxgbPU
NTd+i/NtOdUgHOWPRwZGcNzBo/tqsLQcWkMV8g8temiVTjVz3ycVWZn/js85
zfaZyGlShPeWR2hdXfgPE7WBi7gbNoXjzriMQ3LzgMV2FQvQXI1EM/ycUyAB
87BgkKOxj7GjZfxidUTd15ppfR3UJqGGgGR0y5PgCJTg9FukuKM2iuMHGiQn
d76N5uwviohB3Ex1cj89sgGuGN79X77LMQGsxoPkdjsvXN9HHYUi80a+T2We
IvnGZShm22mWxJzeNJi8Dwb2FJAqW2LFGK324XBN9XYCVLohnUHrO8CgDNyU
X7PiJeikJl8ZtH1lEY+ah+qXrzBJqJ/FQh/fhpRhFeCK3oIfsZ7H48/0Q35O
QykqrNzj9pv4xXg6TDegD7CSgB/xhcWOpRgF9cxQVvHG3ideHRWCVtUN15O0
M6UDjCAoJJG14ovaEZrJQ1QdvJtUW6rshH/hJFFrIQSX57eBOIFNii+Fudha
pXGhpFaT/aHDBEl0y2a4NKgpgB/ROkcucGWnZb/T0ehP6ziIaEdj+X0XvkFX
gQ1zex6AxgEfeQeMm5UX26zljCe2XmhjK1ntUpyTIwbbK0tdmKxdaf/R6PiP
2o7fM53aj/+zwsiuYxDhNjbcwyISpVxtyis4N2r19MZQH+fp/XRkkEbcgt29
KUb9O8CJqIMGdSdohxbtARPddKc+M57fdoIN1bblBIO7fsTzOtpzx2/nMLsF
pEiP9lZ+scav20L1LTpKmMXckFU9GHrUVKZv8Hl9ouPPzfkm0NSvmYt9k9uO
ZzxqkMivV5skOoOGJG8v+nF7/+ueNbSSTPMUdIZ95xlG4hewQPM5rzaIl8Xo
QwTQR9siY+41ZMy9QMaIO6kpY8KUYApddqoV98ZJq1pBYZKrbLmUpLWoqj3p
TX4IRGvh20wxrpsbyqZ7n6Wa/K6c7XcXhR7/bNOVfEZ7jx+81y4AfG+9HCR9
gMl6fiz6E0td7fPyt7vxH3bXm7ipqIHc+qYl0As1vIGv1XUyH5jMqPNCfiaT
ouhIElSqd5wqNC+6WFXb1lD4w2GG4pd0VAbyQxjCLPyPPo1b6L23HbMbt35k
zqibmQ1iUCenzVVpcUK2qrqwlgW2qChdc+G5/S2bXjkD6SuKnw7AnrwsL9wc
kUO12Ga2yqWkSLY9YvNNuNUvz8b2TqEuw5QNmVX5PMQUdXQrzDc248dIdmRj
fyT7U7rQoUonuBp6jUV5RO0Cs6KGG2xiZJECiVIK/EiiE5d7p2KEwdF/hsbv
sZN2ftPkJ8pFgpBxPtf+eMTfYFhcIaWiaLG8OND20FF68+y8UNy7ZuERjMTL
T7u2P593n6cLxhEUi2Y5sHACzdGVF3BB8Ao0LarTzxkZlvVugduntdGoVvAa
zuHAdC6k5xkLxTY6ZVeQV7X/rfo2OEvFd3bsxYXV28nQD9ArbCh2bpUaAKF6
sLYIvrdhQR1/TaVpTk8DFntn1eZb5lqlLQ7AZmKr6Q47oatLGoZ62fR2sz41
ybUxz985xVXBpC1ecvwKfqfCC93jyT8nrwv836ox+V+eAxtMBX/APnMbQGNP
dtjqUaKG42iuYw7HyqDeF35qKA+7UtnQhtOyBRtuTOrsIFbrZ72RWj/db2kk
U7vhu2yLPnbQ6h2XsdYM+dh0NfdjP5Fi38SRy/lJS3KPqAFJzt1HQreFsbNS
L5XKaeeYbA0EugbjhdAVK2jmZX6R7U9m3Vfztz0/9DbJcc/Kq0yKCOS2FjAq
31QmOKG2rGHeSO8yT/fNtM9p3jw5zETQ8uhMt+kq81JQC+ea6zic3yG9tElL
v1dy6R5v7e+eWtpyo35BYmnbPY3zSoOL6tJL22+qZZW2o3tXomFbcqq56S76
eVKt7MdddOttNu2ResatYOMNVH6xv/k0K9IqLwn1hBEyqWUjIoKJLeeCKx3B
f4ZN2e7Am4V2BoydGNkH6qzea8BkU5w36ALLnXFNGOVX/QE2ZwHmdUWt8gRd
TpHgloGKZFt4fRwbDoV1CbrmZLmTWdbYnwdXVrRUJMA/stV60x81avQR9BVe
wmD2adC5PZyU8/eZjvzdIA3Zt56aaW7UY12ig+2H8bCLX+1L6r2Bx3Q47sMo
uh/M8tLKCmmTxRH7Fv+9TarwFQdMnBKHVtwA8r++m78jZ7iF2fwmGcMdHPzm
zN9fyZUd5v/+dwLwL0gADtT4uIZ8i1Ps/TqdefXk2UfeyHG74T85nuDdt/rh
QZPcTtNZVMy267/AItIS+Z61Acv6UFa9jkV3v0JW00ntI83468cp123Kwb6E
65YNi9awNwM7FjAqVoiN2c7tJHRYm59bqeoJLq24xiqIdK8bGE/AkAdG5JPN
yPBVChYA8M2ckDKU1IHiVFi4k+4jH94rBeFYfHVZYg01SXIU6U0u/4TKVlTn
3PySO8bXifZjROdVSZ8yTqUrEkR2kzjx0zYYWSi+LJYMMV9uWO/ytA0YaPj+
KAt/kMwaum4E3KHIPKhFnyAvHAz2t6wq6xDnRrdjDMRCW/L2ycmbV6+evH78
5DFvU9tO0t6JvkRspIdZmRoQ4g6bXuq+kSP20m9sN9RCe39SUT4SjkuQzJsc
HXLhW+uBDZ54TbDdM0RkmrGYUr1goaQ68G95umReoJ8a8XaoDqcVphSZDZMC
35iuyYBMDKsm6s2rVcsANV2UV1WHST9GsDydyTavF5rCRKEWnCjmBSh1bgv9
+nyr6r2nyVqbMlKIG/prh4qo7oWmh4JKXdGHnsVSq6Wyz6PR7VfwbRSrke1z
9/mgp8i6dRAQVTnk4hmJW7Hl7Ychw14F3tz/cSUc9utuLeHGd7cIN7YCPvCH
v11bAtPei+j3bkvwS7XbltDipxeD+L1qQPyyIhCfWAPityoC8UsaFu3TVX0T
oUtRlanaPQ4VrdupnZF6afYphlYjlOnt0zuTYFaerselM36NAPpv3XzDL3Px
efO1zRPvPX6WnGoA6/pOkIGz12t/q1IIrs4CwbINvG3QKHDB7oQaeEY9z101
6jAqi920T56LzwmbaxrNDhKksBZyGGqnZe0CHmbuSVnQTUtenEt2ogGjAiEL
KSLdmvOmuYQUmqUoS4uA89XC+mIs4EIM9XAAFdW43VpSi8JMPG/WcR7dL5i1
bZwRIfNvmPtqHMFebvOjD7iiG/HcAtFh7SYvCqxTWlbIOkirbtaEsLGeRrbm
HSHuoB6LD/y/8BtpGvMTFfwGA6bDj1dznhnaclo6mxu1DKVTS3AHzCVopGmx
4Y2+qa/LQ3mCnKqNrqHhawj8tgOtKKeCNVm1wgD/RjpRWxgYAy7GVB2b8RpE
W1pvw+kYhLgP8mUw1ZZEmRRHpdQaMT6CQZw1hhYBum3CwyfLjD1wVBXPX3/v
YpA86lPSkHWUomIu0WV+W7TBePUZTpDYzEh/NbLmi7G/e/LhozE24SYdj6Wx
ZoD6unUqzscB55cMhXq9ZY1aDbmSUpSfLJdY6HyanGyBNuPJ24qPHRmJz4Nd
ryVpEuwm+Ay1Q4oX15KOIYa1srgANMgPGukKRaYCegcu4W6UlQyAnwzlE/o5
Zax6RTXCO6BpJmrT4L2qctI9NuXRV1/tFRQhOSnx7Lk73pWbUFIvpsd4bxuY
tA6zRP709vnZu7dP3r1788fnw8ejvNrMh9N5dT70fzacZdN0fv/+AxIJt7mU
72L6sEtBgxq90je7NdvGRz8p56sFv2cQY1o7nCKu7kw29d7oCPfu+vrt05Nv
73/7DayCyFnInEUIXf9gUBgxd6WmOTkqdmXyz/RFR6PD+EVdl/d5sB9qjq22
y03uqutE9VpMYt90X96jh4cigfK34aRKrsb8SHogYNUgXQTfaFYo2Dh6jM97
/XC9bbs/umfX494z8jkBBzJwYuE24cjNrdJ3eJg6wXJ0rLJtP901Oh0effX1
b39/XsPa+V0ttwe/JJ5V//Hxm+ejw7ujr+8ePfgSPx49fX56Njp88PXw/n9f
m3/wtbm+dgdFTPuz7gp64kBVQrp4A8rfZnhGgm24KYcqwIb0juFpmcMiV9lm
UcI8p+iWE5dXOJNIsMp1+tzLBIM1r9MtLxPNCFj94be//Y1y72q5Ue7LP8JE
v/nm1xI6k53YfbbOEas+ohSi6mMnSAG9XmB0UIgvuXckSlm/WUxL9/kr3mW3
DiA4vmV+boILxrfQuV7WRxopxpklayIq+IUb+lb3xFHRz/SjVmbfMusO4iQv
apVeDQTNVHrZgWI8oOFwhq6V7TLrRLLZbgQtoDN12+HJ1DKQUus7m80c2CQu
yTlqgJCJHT1EMr8IC0jTzGdbbH7EBSdqq6J7dJtRWcIKTEMuyCXo2Hcvz5LD
0T1Sop6ePLh//2uiVHQPsI9n+DKF3/bOyLQdJPSvQXIC684+4L+JuPqhW0gf
PtnWm3IlP5En2fPwE5GG9z3FWSwDR/1d+UfP6aGOqYvq4ObcB5p82IoCPfxa
b8AfZQ7fkX+PzNUlvvsPD0YjIJd/gQdUCh0k/8xL9Wpd8JL/cNc+LJtAWFC3
ku+M4Vs+5G2It84d/fBZWkdb177b0U8GyesPso9hkGRMz49dBRcCvZcYZXr9
48uXQ7YWuUyimjMeXU3JxmJfMKLKpU5oW1m3gaLSx7It46CKIlsQxpHzQIHb
SWC7+LVmyo4OQjgu1yU1B/DAz//+fw0vD0dHo3sHo9aboVctkbpsNVnVWbqa
LDOXLuQKBnjtL5l+TuVhY07t7Mh/rzRvowSyB/KFvwO/Yh4Vhh9Rdt82j+qm
hNVfmGflpnO7PKu2RKAWzBW5pdQDESW12jmL+/iGX/slK9gZvwcXRUf4C4b0
4juOyFgyax9Nx+pJ1siWoqeTEiAEfi9xEiW+Zs4XnWvTNXxjnlW4d+0bQIET
nT9wNvG0Cze8PBwedMRkvKbwfAm47bu9Kzf+KvJsy69vVdWuO23UjR/tl4wf
72L7KLdPYQu2eO8j8b47R77uvod4PWP2wsKAVUd2f8VsL6x5y3VDZ34F267y
wHHBmtDtE1UrFvZo7SQ/uJtfrAZibOC7NN1n9GtcC3fDXqwoZ/PV8UmcYCPJ
+i9W9/Y/cLvkKrmLbqU9Wp+uRG7LBYXVXHwOnsHztCVrJBwQ9PZWnQB+DSbv
M32UPz0YoHTv2ddwh3KvdmLnQGf8FAfwmoPAvlkMnv4wniaNgjQKmweDHBzw
D+/d5occSfF/qNEpOjE6FT9102VSktXGki8uyiNhAoFFxNVmboGJYAhNknJ9
9EbtomjEWNq/lmaKDORjDXLUnUetAZmOVOpm1YKbMLztZV3iUg9xIZXmi7jY
gld2rQFK5O+UJb0XK1GfiTvZ66G3V2K7RSf7tvdRRNOveCY1YsLMAX8VA/+T
aBIK2uNaM7htLUUCvNoR/ov1t5xGE6wZ5aL/b/sUv4eL28blayLibWbK3ky/
nEVrfOCOFkMO0jAdC48q1ni/1MxDVDgdgjBUXMPLoTP+bNL/fKBKF2CmDar0
uSn9N6Tyd0iHEBsjIdlmKioP4mqY+YCYX563/hDpdLZA2gvdJy202wWpwVT9
oERGs7WHVVRmi6Nf8qrW1TVfx2+613hTyy78CmsCme3UXdjLAa4S/3ePWJKn
EnuKeds6blmI2TKMz9qlm0b/xMILnRu1F0D+KdvbKv79dIBYszKJQyW4qozw
C1AuWJloajdgdf7TdPMe+He67HXODoYZtI0toKMqzeus+yY7OelP555MR+jH
abpt76G5Ypr+H4nxBCINvo/y4BrlLkKdiSfa0JkER+GJnbAc32dnu/kl0vzo
ersQiaWXk0GeeAlm9tnaVwiH+dVF0KcWTGupbhRKrKBg2g31+pzACiiaUJtB
KdA2rfBXrt7UUbaptUATpxM5ThJrnPLdjRpnc3birelgODfrnm1v7v8WfP63
4vCfwN1vw8u7OHeXYtFxIN2bMPJ162bGx37d4tbE+UkvaqoWn7isxuC3UCQ+
RxDeTv5ZK6QFzScX4gZhFcsoHi6cp/cvz1SziVcBN2LJ1iS/Dt+r/53KQScI
w/ptoUnVVXzo04XbvVC4iXnF2TboFY/KMUUybJ+JdBv59PuUBAptls7yOTfZ
LC1Vgx42lbB7I0eFg24CpZ+q8tU5JUcNDdIUrQhDcR4iDksChBA5Y44L32Ma
RqG4ntZ2DQKgx0WyXjyG/8G94TsD/z6Df3+PuAQb++wbCmnZ4Jvzm04xhMAT
QWAdaDWEAn2ncCHrA93WWgJlVc4y/G4czayce0HPGPpABn3iAAKCbsAuDPN0
mjEWgcGdWTHNCauRPPmQ4vO1De8FGLmzZ8dfHWLnGiSk06OvvsZP4I+RzN/t
Cz6Ae+PFmO1EwnnUrRMxSXMqz2B4XuBXD77+VtoubfS1z9Cte339T/D10eHd
+97XOCGZM0wXUU7277Aa+1g43VHyXIoCbLKipkommsCuRcwSG7WEoUBLO3oA
70dE1NHdI3i9shlCFGwcyMBLKeTczQlwm0VZE8YM09GW+Xnhig9s0uocbq9t
fLjMLrOlg8QQfD6gilHytMTu57R7A758bQO5MHBQQMgne1zSJN/UA14ETZnz
Qgljm6S4mrTeJPeOHJCXCOHsKaerckzZMVu/sR4lvXZTJ2GaYvo8pog1J50v
lznxN+D/uVQkoJbpFNedebSM64MZ4VYIKR1X52VxlCPA/E/Hb79/8/oIkTjf
Ht79GqFTNZVAwu/OTt7+++k7Qul8e3ifYFVI+Y+A4o5ofn/iv+MTD+4ePoBj
p4PjAvRuh+F8cyD1USKNxNbrRiICDGfbiPnGkmslJqNQhwMbdOH9Jt6TIJtw
BRN4Rxkt5XcU8fgcVgNlSJE9Veo1ZlMwFXYV0pRSlFYbbOERA8aTFTIzSSae
hPwE5MaJBsdrX3K5jdPSDLZwiYSJRCFnuHIbLObjiKE4biib0Cy4hWLXjiiI
boF3FCBrPEQCJ+jCaRVgJmidf0rWBj28rGtX+Q2bx5ZXxXmVzrRkIMrM40nN
+Qrt84Cfz3MNjAXiw5dlOAEPbU6ipO08iHsOhecxt3T/0r+QuNW70TsD1Q1T
lrO6d/h1H7RP+Pf9QfIO/ngNQg812qO/HIEui75v+OMS/rj74RC0lRfwtyJf
DpKf9S+oJWJsNcCFD30Z4s2Q/6UzpH/pX377GTLk9nOnxqyjMbHXBKz75usH
sAPw1wc8VTQDLl7CJcEv7atJg+XOTT7CPzp34ebAoYfAoS1XB7J6uqWeUdHz
WElR02dmYN9kFRFquZog5CeXdhLKboEql+clDLhYYZtclUUBFXrcC6juUJob
Ys8NGIgSUtmbwanE1g9SJ8Oh5H5QjTZMdgrTc/CB1RarIswQB2YkuT4Un8t8
lW/cxEUNEJyU448oxUlvEGkslcdWGbAMA5OAo6kvkj/A0X/1VfI/ktcfFJf4
+oPyJHmvrgw/2sIeVcsdRcF9rUEbRYYqijTXGpmjAFjuDxjoHh63xLT8JCvK
7fnC7yOS2vRfVHqoDUi+oXx18YU12DU+B+tRyiXCdTJ9Kn3SjJPjoDUfe7L6
JDhv9Cc2RZgxj7IdFqEAOVVStCmq1RmQpJSYJQZWYxEoLHrluCsBivyeoTUB
0KjfJ4mDTQWclWUZMT2vxGDQe7XRD7atLbGQhZfkI6H6uMnpF7Xv1JxklP9C
NRSA1AJGXgshuVXa9qHWXezDGlicTKkUAoqmgv6xLTxwXEp1HYqUOhQl2Qpr
3qWzWUV1wqjZaOLXS5KKt7Y+RVl7c5AOv0wptfZPxJxvfwnINeg0MwV1bboq
GuDX2GkPTTwufBD6wsYjn6Bwqo0mrlitL/AZu7WQasQQeD0KUjZPmuC6tjNv
SYmKlyl6ARoKMXJPcta0NESY25qSjmG1JdcNOgn1Dxi4RQPZp2wkt1I2kJhu
oW7wbFqwiAoCJV1Ey87CoFc5KaI0ywAgZLE3rppjB80wxXChSlthRMDojeEI
HsiLE3skJ/WPCuiMrE8i6HJob0/rmdPzXt9njZXWYgxqeRIqDKKk5sq+5ZXn
j6/RgJll8xRosGPhpDzbpbuL1rjj8Lo1Zq9qtZ7aT5asG+abTlN7naZwutRn
ihiBVkemeil+ddZa1uAuEVxA0jhx+XZ2cPQqQ70m2v55CtUSG6HJ+gsqUXmS
/axQdtflEv9A8K6XAOojCIahO0bQ3JzpnmzXM5gVnmdMUld5TTKQn0AiFwKi
ZZokdo1USYmst3mJQPcRM2JfFxq8Ccjz8hXc5LNyhcpYWmvqJb1a8BS1lF7k
NE9Pt0JNsIRbuF6gFuTpUwnhldGp555Gi5mRbiusYOobQTXVS3RL9yF0ypSI
C3jvI4g2WI6uJFRzjU6whDEre25+lMW5s4GMgCXQT+UEqAKr2N0koqTkz1AL
5gR4qwSu+VXLdGCbt2ssQeD2FfOJiTSFLFSkIfRwvuUKAtEV5DNG7pyvyaXq
5lmLBUyp0etluSNnFND1hrDuoPJrdQ1g/0DjYbfTh5TyIRU1qA4kcJyyoIPH
+Vjjz9bowBIEy5LKyCdqfPMjqLExC6N8q3KV19l3mJIDbAsTz+Utko1WZcyj
8eKlzN6ZERluagGj+bQCgh7VRbiN2WVaWLy13iVxhtTJOaaU146yqfxSomOT
dH3SWoisldl211j9SAqocDFy1lLjc6D+lipldKIY1x1KjTItMUXq4k6ZkZY7
43JjMOgB1sk6cNXePGNcSvW31FazsvFMC1UB8fguUzEWgNedp75mHiosnSK8
p+XoE0HRa0VFWyNABJKeve5xcS74xqE3XaSG54XSKw6qCibqJFzf1CZ0YBgH
OPwgkB5OKpPA59uWBHnuVDkcjx7Bp0u+AULOcokeJs8jUk7jZ/yotnihldzh
/mIdfE4P88o8kx7uYdSQRdhRU64fwP1DbfXRHrVokJxD+IoEJu2qlHJjDbfP
Rhcno3GiY/BmKUaGMyODqALWkErVKzyPvNzW9qGoupccrJUj5dKrDBbWOAV7
Kszhb5pUYeJh07oKcxbL6Zb9puFzflWVcEDVAUX9rE2U6Fin8+x8C5yPIdZc
zXuhZBC+hTskRAs6cwM0FuMGh4WcZBWmxQV3RSraDVyfgYEWIZtmWsdF14Xb
ANPBew0mt/I3EHkDOn+/RpYVlORtRvfyKpvlzgAasGZqtT6jLZNEnw+x8Uil
AzHmlgr4S+LiDK6uOVZuT5n11/pGagKercpqx0WygLHjDOB2sPo7Sl6BPVmy
fglvsXUtQHNASyOfbpdpJQWPIyWjkEoQMEXUNTKsN+H93nVEN+RQBfEwpAJ8
vDnO+yOLR98/F0feyWJjIsKvjI1ooUkMl4/lo5dgoIVUdNyA8VvYSi0bgA4f
4bl72bYxx1Fad7txL5Vkwto3AyUmiodqMpjxGJfPfjh3QTQpcntzAQ6Pj+BL
wqyCkbF2AgjAhj2sykygpVlW0sKjTC8vXEBRx2HtCxm6EKm378t8ntH5BmU+
+1Q+lDqpRCzAGahlBbKBKgo1pu1qReJ12btLYMtsK9TCMaoxQDOwWRvFe5kZ
RziX6GX7j4T4fJ0ZrVhXaysAtZfqDNUkWijp8Cx7fVOQ5LDxqkWlQNK7Oq8l
kdxJxTdETMn3W2kZesw0aYx8ca5fCLEmPds5CJ07p8cvnvSVAEiLxHRbMym1
4jiTIC1cKyqKCMXPSBFwvAAtiVWKDhyUVU7UGil3TnZ4vtpiV+BkAW+rN17F
TPgSMUdFBEWzdRV/WuRL0TKIaeSb7YYuPvDFRbqtSbviyyWrHYBCjBI6rQnq
CJz6kv4BMypbt8cVJvIWTvQiW6TsYMYsk54Eai+y5Z5uNLGrZiBmF2sZUhE8
dOa8e3k2wsK9bDUAo+DQZx0tkH0G5IKW8JRHSxTmDEblVxlgptly7rN31g91
KUqvAhucUs1YquTqCcqBsF5XiX6zM4EJLY494I62dCMKxsLmAqeOw1ViJ9Fo
EqXmhS7L85wQFeeZIQ7DNALbT1Y13B9SNMM0KhTM2ynKa7TOuAIFq/vCkUwI
92RZQs54x9iUzllUbVB0sKuMJ82ZpoQ7QQ2M/Etp4pWkjQA7RKnRPPHXiKIR
p5gYleTupfbZgf+DJqbeB8znuugYDn1EA2It1ntDNcNw7c57pBaqXVA0mN5Z
8kXLyMm2WCIwKU72oHA3WVMxmolUJ3g7dlnzO32NSdHBiDLpd8zVCEYT6aPG
kNPDg2+wxJcwssvH12lXCAZaLhEpEYUf8NxvUw8QTRTq4zLJpqmaWA2GhF0j
DAkNbDeXCHQh2sTpIkOuAoPhtbe985Bn0bK5KusHdnpz45raqyS9WVRoQ9vA
e7DUQGP0wDx0rnBLSH/JUiDSjBFTpC7aNHIKVminJKkIuaMTeCi1YuUey3cu
LMTLCeJAxU7gdt7afa33O9B7dMChJPfsuPZMJ5idpyHE6d4ZtCwJjjP26NoD
tXFDJsrvoo7to31AM56F1vH7VWbB79VZaFHBkQ1bMaNXquDTqwcdxhRxDT0H
DZ/Ib0YmDr85GldvN7nbu2XXjG10QmMY9lkpQI4Ch4MW7U04piMOJXYUOELd
KApMzhp9PCnHS6w4XmcsR21TPrAlFum69q+o5Ua22gn1CKEf+E7gHhbf5vsv
vAqDxM3auyYgeLi2fSr+4MYMqgo3R6Wvm8N2a71d+8aReGEOyvXU7hbsHjrY
KDJ3vkVdDZm/HR0pAal4x4EbFJeF8XSmJVaLROtquWSHCr+pOcFVfr4A2gJt
I+KsMF7ro+hiKbmKIVua5H84U+RXw/PQVR1V638wlotLGIm7GC9iWefWqrsq
Ax8SxWS0EDe6gDApwS9SnTzfuABlVvAmHuCocNWrA44BIbAHNR/m3TscwViq
7dHFxrKvFtJGof+wNqy61lpU+j6IESr9T99lrJX7M1SHQ+DP4vz52ivGiZ5y
MbpanT8SHOEC+HXiyjyijEDzDDRDMn1JF/eZmpo30obHYUQdiM9VvOWOpQLd
KtQ/IGLSeeioodKyBPHIHi63hitS9FULQ9cm+wYuy5yk57rciNFezuetVo5g
roTVCI1I8zed6s6pueek282X2YdcnkFKycgTjRuMVVIzbmSodMhOi1z9GcSo
sDoJVVM2Uh6U3INkWm6yczkDIhbb4albHbH0VdvoCBkFqCe9LhlkAcwFIZqP
JXiDGNbrOwV/OZzRl8OZ+1ISriJ9qU6u4ARhRxPy4vLzXqfussrPCV0eunh4
eHZ2/PDiZ4QcGrU6QvfkydO33zt2dX2NtS8vqvRq+rfdBde/5CpHQwY9ku0J
O8369VXGoZyZiU1tGpZuCh5vtskZZ9NdUM0Lik3RnrL2i8i1VbnRWlVkx4D8
TQu7SfDWq8WOnf/U8Km6VN9seUmnYe+CIxOqcga2ptsjYeYOwETMV71KGaGT
ywppy2Nj/rzFDMBtWaWzzERhf8uVwlO2GQWlAjUCBGxZxfy74WZVFan2IJBW
RaRwPn6nSj3GD9KlLf+ml56Pzrrhm4XdulAxfnFfjSTYeWAcU2ZSBwSpdhUr
YrDw2jEyd1b+to0ITCs/t5sgTRypg44F07jVX6XeZKz8d8EGdtFx0BbLQyOy
ZqOchviB9e//eOKmhiha3MIRzOjZDy9+OrpH4FySG3/L/E4gQewiLjEZaAu8
IxiklYhpWhMZkWdG4jDBmHNqoOIWre1FKIJTyzqdO4xCYfWCvTkXWbZOGBOI
eR+Wo9jDZ0SGVLnCLVky4EP0ZClOHRypkH9aW7603OmWzEaeRVOr6iraoNdQ
1k9oA+FKuIWBR0LyCwqWusCAIoBZ7ra1wbAufq+sHhf2c0QoUXUpTo9WOSW7
gPqxyIV72is8waZCG+4EmCOyAgn9r9v8spymKqU0xoTvr8oJaHQFXm6dgSya
TtJiA7nUIP9wGP3QCsegUuQsW9fDerdaofIw5ZwCFO0UQ/ehMoTvc6BHf+WW
1OjRq1KvBKiS2CoIvWwUEuM2shR7264m6OKZS3s86RFEZyln5RX8SjUaz4FT
3GWu3gmvWyJINfSmOCZN9LZCtc7rq0PoAdwqUFZL7KCR48VY2aPDZXve28hT
41r4haUva3WKBzE5R4N0V8UjqgwCPhGPEBKEKIIc8Ksy+IQxc/Nd2JHGy2AQ
lue3ZXGXhKwHajChLbPg+Ifk7JNuGIriSeEEiV+64LDDD3ZEs28RS7bJBhTy
Z4Aq041kvDhkWERqLfJWnGyoFWBiyFYUUL266odPkbozDM+rM7x1/hxfVpYL
qjrr3/6+qOUgTm0OESe9dZ1tZ2Xfu5y3Y7zpcgh8dDmzeDNlvbLNJSHRKhJ4
bsJE/HY3egjYY79tH2HuF4Qo0UMlrZ0okYupV87Otu5YG9GhDrGE6aPfssJP
Hg5apodH0H28gRxIut6WIHxyyOwZuNOmaWArhNpbFWLHLZaJIUDSb0tjihhl
42OhlD0+Kv5kxImuDvdDQ2Lj5xRbQp+Dkocv6uWjbDTQ+8JfWPQj7RT1WiGW
wIRHE/nCB6z5fUTw/KwkiAXG70koSVin0yveKi3cE7vTsivyL+ZNYwssYUi9
twEbAqsLnrkLuMuGo5j1MEUMpWtEdOVFg9cNYqYsMDw2fgc+ITuhiUkOlCph
dQob0W4KhD1knrbfFDflYyCusYXO6Ee0UcIBbDnd9hQaLmarnI0hbXQaPvlJ
me/gUrbFgXvpCv2+DCsUcInAW7CRCgK0ijl8Sn0Vi5BX2mvUc0Etx70sjElv
CDdq6hDkHkXSffUtCkuXkk6mDgwf6ScVgIV3U7yimGGF74zr6oq6NgH2sV3X
39Huo0T5Cfa9Pl6vnxw9YeftO/HhOXPPb97jHLBWi4U7V9nifQ5DwBvd9GSH
IEcvuuGl+eFuwEcgiIPdQuhi05Q+akyuH2yrCirrA+6aGeeYLJe+t4nzb2hT
WjYBqU7UZUYDimr9FEZxu2kfT2crwl5o4VWfvJfpLqva4p2WzSEzE5RWipBf
2+gzQO/GMC0bO6qarnUVNJsYFz1KHuXsb4i2aFP6fJeR8LiTwkzI1SYGNFNi
2IcmKvjI762zFUE7CcEdUv7QS11qB7O4vZW7uFc3EO2ubZtd5nKk4iE73LG6
6nBsTKKaeuW10/NX6KMcBMzsu3I0k6oR6KkVQqRaWhchdWU6NrIBXFdWQy27
h+V8OOEdtefmEi7Dfp9NnIUEOFDHtNpBxK7qkAI0C2eV4ank9cq36mhjVrAr
9pgxElGjOYgozykbOZ3TcJNA+omskkBX72S8tNLucQQE7lk4pVSKQEFPXogw
V8M6TocWhMoYf5l9FifBcElWgqBQGIQbDNLLJd8fiP4Dx/OFPNvgjmjTYaPj
BGFz6mdpUw+sXiRnrEgHjMV5+PsWBmXRCa46pC20a7cGZrudenAMugSCNFW8
xmRn8fZkFISZT6jDldPck6OEbLbpUxZkoPTUYEWhvuV02lgBpexzCv2KIHU/
5MEcjbtBRMX31FjUFdyTlEKN/lVmx6gZeyKDIxPMGV32Nwlz/hHlNa6VEXmH
gBTle9RWDBZF2dWwwsSdT7eUXZ/VziJdtmsqIRKh1VHTZSTREMy9IQo/hz2q
1deBDAtDWvX2/ByvqXV2KnvkghfqP0sx8J7VC4TR0jfX1+/enJ6enXF7iYwy
NzhFFK7CVDMMaaKcZJBONwpg4ZQJTRS0lQo2ogWSZlmrTkfKSbkBrlzYzhQ2
Kd1NynlG5OdFhu5d7BucMAqZE2ozVf7Q/6a0MHDlVygQifUTpMUwxuuwur6E
VdwpIL3T8pQ1Rr1JcDBOaPF9tGxASs4DyAaCY4aqNp5QiM2bR2uVOBPzJPwk
Ms84b1OYFKHXkjYkhjodN4ytJgQCHRyCFnUbrygAW28UyVhv5yCfJOewc3MU
PKa8JJ2qr93Ta4TfzdJNOqFEssRlb20ajEGCpvUU/cu2J5v14t4URJAYUBA3
4OAfOvX4Bja0UnNjgCe5RYDH3BDgieIXuEsrbgcf41uMTSamaDZqOwQhpnoL
EaLcBFyGjLGUfXBUwCBfZUPYfaBIRiUrDT5+NtTAcPLs1b/+W4BxTkSBE+PA
XrFgvHo74SEJ6SNqkIOaKU8Yyv1fkjoj+GtNcqQUR41cBWEbF2YUs7i5FDU8
YVispMGYwsZjXkegTPv/TakxUiMGY/b2BGubZbqs0S2+zM5pnq7XGKm0JCyI
49i9xUOPuqv9k/eKYw55DjpWnHIGvctlskeIG7A3/MHBRU7nT6xWYh0MNefI
eME6n6rcsEo22AwJEwRBv88/JI/6HOu1RyaMiGHafl6LTtypecfO4aHGiL4k
1ygLZvijdcy7YHdTXeBXKXtJvQlYZdkantbkCNlPtAuW4diX8IVV6F0bFdBx
RNTasnJLhq5eVLNilCyJfSSsq005mdu/tI0tDfgUN6IGuZch6HTLngj8uW4j
kX+AK5ROPd/ee3CXyBCEQPAwJtZSmzF52D5LMogQYRSvsgEsb1MDWxtXiEmz
S6qTJi4FqcaA0hjBMiLfW69ASJecVbCf6RLdE6sgNid6I1syygwdNYaCyV4e
dDTs7DWo6bp5ab84MurYkvcHuuYFJg/S+AswVsLLEXRc5lnlIbjz+nqx+uvl
kEf5+LFP0ZgcfQjUTCL1GzFjZo5L4IsImY3FZqhZYQvJbbaQ+CQwdjZTwl7O
DsojW2Z9P4oUkAoeVF1i2R19ppVROJnqcLHgozxxVxmBwQkp+85COahGd0Os
BXCVAMbik+RTsreTwyO9Ln5esNcIA0hW8j9s8C3qyhozhzhPQK5igJP0XhDl
0gTdvj+KF3sLrEmSTklftL/m6EQQvgzhALi/mjDr1TgL7PfaeSrJM8OpEWXV
Du0EaywHFcY1KfN6lA2T11lOnlp3Y4uyuvHG2ptA9Q/YL6IREaVrz0jzAqHu
LkR6E8UTWyX4HBRejkTAkOfpGk1dB++nnWibBqn3YSqi18NXEW9hF19GMFkI
4LH6oz3wn71OxvwAnHV6kScZFm4YeVsouekdccDeqpxtlww2ET3WV4WB1S4d
dewBTBE0D6kNdDfU5ghuRLgMpn+NWDj3uliycO+H7CEJgmBGfEW4j+JyFwn9
Y5GjgQOHdhKA1Xo/nvRBVQdhgR3GsWtgWiAm4O4hMC4q/8OSRiNa6RS0Y5qh
usQkRBbzHGpiaRGuqth7BYVaKd12YvuiVgNhss2XMzHo2eCdUzd0WFkeaiF1
tiI7Y52uWbg9VczIC7iHNRzz9fXTF3fvikzLPaUVf/4sgEUa+P3P6SW6ox6V
uwwPkv68+61np/QOB4f9IVruzptBdo/QlfHoCggLL2zyuiw8LzXNtfaRQPFZ
m46zpsIpyP65gSpOAEZFmC2tQ4cxPVTaMCJKUSdQtNILPsC+mHmILLWwDBtu
oGX4G8JcAZ12xM4kRkqlSAU0dlGUVyC8zjNNloYBw9rgwOcyydwm/6Ln1cBk
ApA2sBkl1eug6JMYuSmn8Ow8v2nhAdnsUu0q0ukCMagUNVyVeF/IsYxglCGf
ebAyH6vnlkvvxfUiGaYbuoilHxMI0C9gIUVZkQm3SCfrJXU7jFhlBIOowF3u
oqQRb1rsF0QROyC0geyckM9qlPyU8fg26cl0CBDXD5VL/jBYRBLkSdVhHC0Q
g/FUHM1w2/jobo9Yg1KLrsTET5mXhoX0lddeQR8B8GJdhO0U5Yi/N1LpiikW
fXLGd8bNPe8PGxbWKzZNCzJPPBry3COCDBS/kXpS5ogMQsdLoVkzDrXe8L+M
zHHBMdFWbXDfjQlSujel0fhbhOH2kie5loMuru5ToWRfmbJsIuf8T9HmkLm4
ygEMJIDPDCEGwmKqTrSnUmECt2SSctkPryIHvKhiYEOBeWhxpDe9BGFt/Sgt
L2hqb8bq/Cz+BIXGSCmtfiVnxbCLyk2M06E3yvmvr7tT8D8OvLRb6g4dZ/ka
Qm02Iin4O0+htHJX/YQcmpcyE4IiNxa70FrEizTnlizjlgxfwzxjSg4DKYLn
hUdYNZYEd49jU0kRKwaQ3J2Lne8pTYogebLl3/nnZU80tHVZwBvx7Ev8gqsd
MZ3B2jAFE7e3kdfsp5LTOpX226JofrYyLbLKggokLadHYSbPjLCxSx8/L1Uc
XBzy+o4LSmJR7ODSWmgdUR7NQ6ObE0WZLNlMooB8DrTv1SBCwZdXJgjtKtaL
Ib6Wy1ENm7DQlFN3vVanAWAq2mJMRdjWmnMe6uZk+6WVVrBKz6uMEBscV/Hi
404Xx2RqfGyGNRGwRghrGD5KJ5ywrWYwitvwSst0/BEaT8DAaxkkXhZxTseo
HfgBGBKVUiMKIF81TYFZnse8ePEcHwrLzHL8ju4p+QgW1uMD+oKtEoHexZz7
gfXYqGHKHkR5+Swv5LoI9IGKVmm6mOwdxZIm2Rxhh20McZKdwyuQqTfKfy3S
S7+41rpEJQH3mcojL0hpkuxw/xQqNES0CDX6+0hjYUBFVaZsueFlzLPG9ssd
df92ARYy1OH7ecbVkj1Ues8rer0vK6jP2jK/OiJeLXkatdnt6ASnCr8fJdFX
miD4S4KQ89i783EFajWKJ8VmZ7RHCGVCrmwmWZAPYbcDJRQmEjk8mty8L0IU
CToqYLOmOadM2iM0XLiIMwmaXI2mSrfNC8yyeE6ZSBgvZnCiYBADT8JMbol2
2WXg41NsgEDyWpLbdb4Zpl5Z39wV63DG3me/SCBipssg6dXFbvi8uLDt8irF
koKZMDrxmhgZUUt2dJUSeuch5nQFzRB7Exm0Sxodb+mGWJRRW8HJZTa3WxEx
ELZEifJQn88JD4kav7deNwuqxRuPwlABa/4grg2EhgRqhFfXmQnrm3EFCKl8
ApsISvBmEyD3onozSo3Gq40SXAyqcxBVKwlegfUFuPIFq4Qmvgi2+6PX8LpF
LFGzlLgxNs/KRNHTxr3ccIcsCqzPsLRbei5wANw0klKgk2Kn+dsISMyctT5k
cnPuqIIjzoScCpjNjxjA9t7i3ohebUCOmqR+eUVXWctPUMTM9RUQAlYyi9Kg
WxmO9+Ze22Lap2Oo1iZIl8xLEGpUb1CqUSohlbQYxGtglKFdXoMC2qYlKS2s
kSMOy/JFrbPfEDumbRw64jyu8gDE4FcY2gh6v0rlWsHBsibmynOASWfjqaoK
efdRbheTg1lmKUVTb7PSbeG8x3RCHGBoJRzTvAJCi/2QE0t5CsYLY/nFHwlU
eX2HIcTkt9jiR5Ji6SGLfXxwT3EKy5077Uj36Hv4T0MgOMFC6YI5mVT0ArZ3
EVQg/l+XcCsFbGyhLcV4SCogZ3A7RUokkRY3sUlclHSjRbcUIMz4WfL5WD5I
Z9667IaiIH4Z4ak6dl1amibwIhofi3w2ywoFL6EcIrN7Rr7SSi6B5dqom5kQ
fWGriQoIRq1VN6GgxhD5plGbnkrzraF030rekGu1NlKGCO34KWPIM9sMgmIH
aTO+E4Qrk56E/gxHI6sZJV5JYuDWQpLs82r5o/vO65TeF4OHTUfD4cFgFKz7
iQFQrKHDddho6XW5pNsULnCQPKrKK/IEm++B46aUq/voe+pgg3R3ssgokZX+
pBBFvfBdhHwW9RIT/5c7m+iGPFyBGDYVBElvs1vTZikMwTmLbBU0LrYwz1Lq
e2Mc6gmjcHVgu1KKJVZWJOsYyBoUAmI4hd+yBrS27wxGJTT6/M3oaHQv7lfU
1v6E5+yl4deZc+pXWRIUxMO1Ky2wJrhjG4sKX3Gyv78yh+cyUmGkvRYPqpwV
i5CUIIs5cAkscy7Zaki9bzmtD5nUW0rrw5Q8tKiri2q4SqfCoW7I/mNfBSbz
sQOZtMyBABopec9mNtXJxSERyMWRWrneytA2yakykiLRV15DKmz5dnE4SFZ9
6R2HY6z6fiJKXmgaP5WOQr8j3Hs/zdBwRsWQ19EoSfY9Pttj7sjhDTTIvj95
1ffUPfawGjdMQbXsNe2YejoJqNP2+xlqv59N2HyBhjXqtA2HHFGHL1/xRCbi
6qEy5hbLzrrfJfpyD/lM5YlJrzR+ADmOcIeRU/ZRwxFRwXt+VfgaY8F5keI6
pgZ3oOiNvUY29Apb1Ud/oiE+6huX/BtWSuGhru9c2n9gjwa0T5qodpqbPMhG
vS2fzdEKa+X06j4DgWyy6we46GGEO64SKbyzVje708NNM5WaQv5XwB45r3DX
8UsxZcmzT/4FcpzSCOxUdMtm4TtD7ZNqStTS6ARH4iiX0bwDyhkMiqz4BVUD
95lhFYewA0ijp9wP5nR478F98n6cDr86OrRZNy7Ed86d4tz8DAUMw/i7ssqv
Rl8jsxwJYAvmZxdrQ+u2pCuh4WyvAqKoEiQUtnjJNCNPPua6IJXW61VjtgQ2
aSjNmJ9DKTEQI9Z/RpND3QfENObojNiNotpz3kkQnVlLIIvFvW1dyC0La7Pn
HUjtJISQ6Z65wtzXd/wa2uxLEvPoIizhbVlH2GLGVx+oRsmSwvLIkjRNrpTS
PdbjYkSGkouLH4nDM17V0znrMr4uH3bHsEX3l1y9xdrltufd2VM+kUm6pKAG
TYmRAUi3H0hvJYeJ8WrSi9cgqmWFP3Ml0etIDnjS13RtIGmhyAZivZMuc7nG
NLxZErm1CgP33ubDrF319ZoGr6dZAbe1rC2E39YJDBtOIBfV4JtJUeTPMjgW
a1eyF8eVhokTgsrCutd7tVdNGBSXK0yKM7PsEsEpfa1IvJG7GQHoXXVIqnyY
NmHzTLTSycKvrn59Z396rjEnzRTfKptLLFhf7FLtHCq+yv0in1LA0WiWBNeX
9PxgXjK+ZtryKoDwtPpj6or781SMa8fg+60Q8iMbbxPIOXgM9G57F24L8ThR
9VZZyURj7i45pFaEP81rW3gzbbbTwQCawcx57dqCahsV/9mCjcVhOTEFc3RR
gg2Tl1VUJqjxhho7PPFcZiUbX1wKAFElzGKwEL3XjMj2vY34u9lfM59DpEVc
GYE5MYXBNMhenJuWt7FoSv2keQm2EBJrN6BkZs5jbJ+wsaXqJJG7bffQHEs5
+jsycRlscXWifYmvmEqXDKonRRVeh1r4FEjzAnXUHgf2sZwTLEtIoc+vwioT
bF0JM8tFUUEG6yDOYrLCxlGAUkqv6saGqda5dv7ZSOk34FKsPqcTVNMEPIXJ
OxzrN9asVQEgQTHe7JZzgFcsuaWwYvckBOnaSd00EveslvSwmHWbsK4/RlbO
Jf9BK+OIYpZ6+cYt9bdtFb85F9trvV4a5+ouN0Blh4OCvVJLU9TJ1jxEZuwl
Z57Sc1coNrF+ujzvRdFz/D8VDmO4la1RZ60KbfxAB6x6nYjnLgcw1ttxd1t9
ZDn5RJHlWKpb7vaOYTMevd0jb1hzO+sweTLKZLIBXqE4S8JtpUykAIfA0OYB
p2Y2H4cL8tqbYah7qO/KlmB3ub/N/UQ2jZB7qoVM6nTlnSDMGQvXbPZsuXma
i5LYLLorOBztLNMUvGY/IXoXQ6oH+WnBXo4eJo3alM4AmOAc7XQmnFfp1bQY
atUAN5rvAhf2QyyvpsJMuhV+0QauP9CIbslELMR0TnwS5TKej4//2fhwzKi3
CDr1CR4Pe+O9lOvtlxYs8vjl0X01IU9lo2Wqfque5JUIlBfY6h13iBSIrLVR
jIa6myhli3OhBODU2BpHPnaMcuZEgHFzc1ehly1XC2DSjQ5dnq1Ff94tXPWA
mjulWF/vLYqKt4wZ1hVHNHKARJaol8o6KeEURXp6rv9ggJ2ijF8y1YwiXbR2
nCixHE3tDzqWoh5hG/sEw12SlSz2z9t0XQvpQc9OXzzR5IxDTs4IklcEj2wU
fOBS6YiR35RLh5SmmuJZuuRtPuPEZOqpYa0hE5XitIgixQLJBUCbscaR+EYF
WGGK94qDjDC+hmsqtWFIUU2QSIo3nAXrYY5KXdp2cvAp0p60e9KEaFWCI5f4
gBF8raT52i/RDqe+xTocis3T1jlR3f3OrEisi6HuHKrT6QKq1gNvuzd8lyj9
wWCXkv4nzf96jHCSgsn9ZplUW9CE2Bxrt5sGqIc1+lr7eyEgiGFXsr4o8zTU
cwaGydIlBMetJXwEpFUFjDQFwq+0ihKTNmeY5izQFznoJxlqgesdOW5gtNx6
OC6y9SYMiBTGRkIkDIP7pNngmHUS1ZDxy5ejwkZKMUWVawx1qccW+yPsO09J
n2VXhaaWeUEUqtje6MWo4pPsv7BamT8vig9hWrUPHtkuEaT1uCQjrNQKzAJt
zusWsHELaFVQ5QZbfXrNPwZa1d5ttdW/48ZulK6KHZGlnRvmfCpIRhKavduj
jRkkNzSsHUNRA30Pg6uXguklGiO80FTMv3XG0GN7l8m9Exm/DH8OW2AxLtV6
0N0ADlvFvp0mQSolOltJ2sw6YjGOGHZWwW7m7mtRV4H8YC4okxczX7zGpwJC
ZxcasV5j2k0N70BFMSP4Xxj3q9IrwfpacLvUwPb77DDUQVItpKr7dpOF3r+m
S1Sa48GxzoAwg2bvCaP9gmaA1PKawqje8UeTY6Dts7SaXSFh2PyYV5jIAgbp
s7NXWH7cgO2Ugz05Sn5cU5EU37cX19+ySqktlshWt1QZl650hbHqPnEL7X2G
MhLjykTxW3zSdsRYl+XcZTcH/RJjs1CRmeoWYyuDfSmSs0/JeYWwW9eeEnfE
r2yGewe7gBcYMcNaMNRlW4a/DzxcYV3/5EdaorNtQbBT92H18+GrWdf1lDgs
l+FoTI+OwmOJXwkM4e1oz8zU69kowU0tTRqwjgl7bVkp5/Aa1pJ+r1d2zPVQ
ccm9tDZCqkKPc2TB8PhQ+hd+/Ni38XRiFWky53bs3E9FAorxJEx30W+hi/aZ
eQieDpngNzjxsz88zBD27pjksFGYYt/SYMmMT8hR1fBJjDWYwGvT2A3j3Yq9
E6d6EfhTLjKGA42l34VHHmPEKF2WF1Lm7nvR/rEFCtZ4JAOXHCsu9p5v3Nie
ZHwn2FhGWOOSHYBKJaq6jGJ4EFr1VMwUV2m0BRd29Go/k9pjD9TEzsNNSDIG
G/fwpOippXFtcziOHeRqqIYUFLYQDZJmxbbqDJjvRLpA8hwpgsLWhvOjEJKY
e0jKFW9fiFDNhhvzMeLeOY4MX1QtZcclYrlcDdUk4dY/HUXwBQnMc6fWiMev
jxsNaN4FliJWq6Aie/Ss3DeqQDEcEhlRy/qpJltRIMNgxo3WoZxsXARC5BiW
f86uyJvLu4klNUAt1lSxpbgbBLszCOEGP2zBsE6eoWpNq3v0n2VVJO9gKis4
Zrl7cChzZmITIN95bnGKtiQP5mJpUsQ6K9fYP4d6GnLhu4I1nbew25gS8wiU
OBQpj2HjCTkyAJN8s0lOQNNNz4t0kDxBM/oEZnwBpzwAE2u7TL6vtpNJPTBP
4ZSq/CJ5scU6GQhyO9tk8xTNeuSeFxk+v8NA3Ktyge2Dljg8aHjJK1w0pswO
zA9YPzh5C0b9YgAjZ+fJ2+0EOStuwuscCPAMyBj4NNDls+15mbyQbFsP3kQL
M7hBNgww1GpBZxvYLc1AxTF/yNPdNvl5ayE5VwtSr0moVheGJSshxPF2TdBy
VxWPyOvYtrsmfIZqTq/UXkWchm2JzRAA7ZVjAy9dtQnDGxBReR14rKn0kNXb
rLVcc0dlwoQ0vlQjlgx0Vg2M9hJWLKHDFRSRW8HzpqDatBKxzfc9gl1QYVL8
CCkzJwbRx8qslzl7pa1NE/7MT4sjewNmFJbZ8AJU6l64vn75/dsj9CiYlrRo
sUPExrAGxWRnwxoIzbCM26J7tRz+iO49QtkqgUcxQu69JiFFZ0kVMO1G2V6Q
hZTtc5l4uW/a7R2Ed7s2HjDdm0POpVS0fhMFCzvIK/dbqi0t+aBk4Sw2/jlO
CDclL5KmHNVOYD4YNLoXyO+eB+iG4Eog74WrwJmbgfXUrCxBFMbefhjVy+in
kgjX1/iHLZ9x9vz7V8fD50gIWotCVG0cHaEViJ0R0IZgaCkGLUYAsEoegT2J
M1CAsIqXS001vp5QC8TwmfP7xsmpZwElusyecG9ArCouXvQ7248Xk0ykAgf8
mpNrWkbgRj1and5V4NDLXWBhRupqN7U5YLDxSBWEfdBkG8+bEFSg4dgtdnmC
Hw3/uoUvtqukd/qv/SAXk6/HQlxoEgMypPOkEzS42fXZ6DaT9DB9VZFYUmko
Stvs24R/E9btiLoMffRtdyaWItwu9Q/IMiiVUbwHxpog8Iz/veerTItWAI9n
4OCWRL8fmImUbtTRYQaDoFSZB2PZjxjGeImHPSP7zhbalXICksvCEHeCAVJq
gF+UON/0NSYf7ERrt4HAU0uMhuvncSxwUmG+uw90Ae5qjRUlF2uhalZlYLir
29cPW5GHUnocSmfh9uRhxct4hWWpfTaGE3y3lK2ZJznDFSqt6GV1fSOwRpIB
5egyq7lDaM7OS5SIvbwtwZAbZJE3iPz16iu3TaDVVyuj2moc7qU2grDBHgds
dnq5yZTEhg1jkakFjDU5Y+Zwfccvs0P4xJaaMbzxVNdB+OKSPCa8jiEwyIHo
F1p/jKOWsmxUOJRVWtZrOz/IE5aZJuM1kMUKWLvGpPj1DFn0AlPSOxqdGfP8
A2jgyQEOfeAbpAcwt4MEvkrJ6XWFWhJH/P7+978bfRHmzZQF3Isej4AlauL/
nh+9OTvtLbOikeM0SI76gzg9oW2IF08O948c50XxyNGn7SMfjbzCqbaddcej
hOe0aAQZvygxFeBTfuEyJ8hl1qc9NdozA8/1+YtXfmFTPkjxTSbH2pbU1X9q
iI5kuoONnRopezbnclgJ493XUrsnx7KaxTn89aULh8i7xKc3hpmMw/6XONnt
F3D0vay++DH552Sb/N//A4Tmj32M6Sdrg5PHb9cXZ/gN/PGXuv+X7Re8zJf5
RYbh5YHFBd3qjbW+8QzeWPMbz5pv/JHf+ONftv2/1PLG5wV7UqUj8Hg7dnnm
1iHUeCHi2BiNa4ncERy+SagM/9p2+h55IiJensa/3vD0AZ/EgfzC/tNsYSbP
YFY9OzVe/8t4Y8f1r7LCM7fCs193hXzydoX6T1PvXyF+pWVdKXU+RJCTUq41
AVJXncIVsZFSVO5mjUAprhU4KncBhQ5cjbrPEKhJ5srPvhwJAlvzz7X5JKPk
fKRsL5WKAx58+2OfSkli3jJp2BjC89JPObU6SmhhPc5BSCXbRtTmNtkEwshX
zSORpJ3quFdIBasStCTpKE4wCWwqVLBNh5ruS44QEtxILKCbCJyRKxg9uSfm
/zStMPLRHHvgCFh97GGh3EZHqdp40fL2iD8yZC1GHOLV0QwbeKolWWWe35hP
1dsmSQ4gLZ4sN4lVK1THFndBNVHyPwOpzevn3wuDP/NQrLeW8+YGOY/C/ECo
okPUS64zc2AvsG6cImEz5bI1msiYi++TsKa7zrqb45Lp+g4rnv2bAPSu7wTF
zsR1qKaT7UsbQh79mmlRiRYm36CSnnmCl45G8H6YSO+8dPn/tXduvZklVxm+
r1/REjcgDajOh75DnIVIEAHB3aSOIKEhiCRSfj7Puz/bbbfdk562mBkynkTd
bfvz3nVY6z2sXVX7w0lrj05qfHAG//7b+1fBPHqT++NjSG4HgF+Hxn2z12Wn
7zZBPwTOi+u+/uvjPUtfmfs1yo9fu6KHw/fy8asbfnw8BncPNPRq5Be6Yr69
K++edeVxK8z9y18+7stLZZRzW32oOu5VVHm2CPaxW/zlo+VBv/zK3B+EcpfL
t+9eTXn4yYNw+uVVGL4dWfzrJ+9luB2s/vHxvN++XvfPXrzDfZ3nzl5fQ347
kPrJjpqrieZJXx4C8unvPH4H1gOia3MT4HMXL+oVhvBXd6d5/sf+XV9M4jeC
xN9o1O9Wtn1yMs2TXTt/LHP41cWpX2nTAX/8JX9cIPc3t30sf3F7jcSfvPvN
b68NMx+w7/qAubY6P7xB8/64xMdc+/PrdP1/vtvW8PBOn9sLch+H6O1M3g8H
pDzs7eQ711q2v/sg4G93+p8NB9xOiLgj6dtCIP3rvtzxsLv67unAsy2gqqOg
Ih69Av5We/vm1/+O3rjbevLHfHXn+v5JMPERQj0BCX3qjx6Dzce/8c5dH/kj
De6HabqpLo3We71QQvf9za98Sn/6i7/98+T8JW/ev7v7gqF8/zAehll7/+5v
+fP+s8zg+2uD3f03rsl6el1zN7Xv38WTbHTJpRSTX/z7xGB+xs1yND/77/98
/y5487Nf3/39ze3bv7v99avbdy/9dXXpYYfab7WvV99/eID+/h3XDct6X4Yd
ba0UT5kxej+ytbvkuGM5I9lw3GndHttjmTnbPKxJsZezZk6Bz7hu6/GlbO9D
qmP0sX0+1Ycze/Wz1Fh36yXl7E7cM600Xattm2NefA8GfXDBhxDiw6IpRiXk
U3zxOeVQYqzXVyGn6LMrscSc+LolfsbXNtM0c19BuJm+9+/6dMEVN/xxZUwa
Flsrx5653XYnpLFnHs2d7bfzayzasLwJo5ce6jp7mnvYuLtgqGen1o9dh6u1
k8qopVpf6kmd0QspHa5cualrzGlLblZrTnb+rDPzh935H0CUnpaYXK90xZ86
An9vH9sqI0VXq6WBw9W91uZWLQ6CY/vRox9pj9pozPM9/+/f0eld+mkn1jmT
9cu6XHxbfNunuRahQB/imLSTOR6+m8DctVHaYoJLNY8N9Pt3xc3VWrZ77sM1
7LKH4YyNeelh1eHHsK7lq/V8iiaHVt02LtQdVuzu/kyHu+utXrYtoeTF/44N
cZ7exuDXl3OjMjHRhzqJCeJiOYJxjxGqsbPv3POc99e79+l3MV59TbbnVvj9
nmw6aeR65urMOpfThQ4jV/lHDvMYx/i2EBjqFnKwcdz3+6Pr2tTJ0+ht3vu4
0T2Tmsa0vXPDObw/PtPyFEYa0Xbjdk3nVLs6c9+qP4a5+a/19WOJwajmeQYT
leoatcahPpJS5AK3aMelVjw9Jshi990WazoJsdr0K5N11t1d9XraCyTsOR1z
7Zn6Mk9spEbvRNLYRFJKuTTPXMyVbSfiel3kflrRDFuaDbY+QZJHeukxoDzj
YnWj15hijjPXnoixssEVMngMx99k6XBlBfLM1zbn6MxeB2pKn2mGXNK1SON2
rTyVhy4fV1fxvfXmS6/BtXY6Tcw5kJxz2+nIi76Bnd6btaGUYCwReWZKacbF
XW32NMtlcsfxzwle5DQKP+9xM+zLA2C6MOjBjzIpVr03LzyxB0v6JJN86sOG
vIMtydbQVnAr7xIsoRzjHARAootnFEMvGvPZggcL1969hCUk9MwjANQSyd5H
J/pB30IwTRrZqqanJkLsTKbf0DG3XAzM+QO8fSGw3XDNXMCWQxyW1CBAbBM4
d6HY6snVFKcusJtdXAwwd9XmZQsDOshWks/XwVXabiPPFkYDtHKk8Yv/2kyD
iT27wwG7HsVCss53gM3WbAU9dfRk9P5X8us/lV9akUbmOk9GjpoYn0PWxAQF
nVDr2nE375vbM84yC+xTuCUfMHzkMOCwRAgMhm+kOtjALPYY/KzEQISx+B0/
5yoMZu7AUc/dpW1DazuvYQI86AY0fZf63/S7uLaLEPbk6Ab5E8AON9sOUDhG
5TCzDNDmVjulUrNy3xdnyNVjyegw/KoEyvQtn1Xj8jGX0hxwNnpn4H2zc1XX
Xdgr1HAaWERw27ghM/oCZdxn20OTmmM8+yKFoOS06+aucQIY9JrWtrNrGHZt
N3IPXJ2WpW02jA8+0+9mGT7mcJ4k3DnnkGOhtBksiEMCJWd7EIpZcjfGXqEg
IitsruJ9hm0uRXE1BuiYpP5ggMF5Ryoe6Ckm8FooDYDVDlkzHmPOQGgdEaUf
kJiBDW16hDc/vynIx0jzGCu/vluVwk1tarQ6tj3INsfNN+FP2IeQvU2DcIFu
wGvLBJVoyvJuEEde3QUX3cfXvfkMUCzaCrxWEpvY6GMWS1ZNLpkIOLoVms0M
eT7DzmIGSeTJUgLJ7ST2++6cSzo+4dwnLUPx/6qv746uOi7mCbo6/lFjJMRm
KZaQLIv8dHNsGkaqoaTQnAxoAmdWQRlmv03OdA16aqkiDTFxWJ22NBbcsjWb
HHftC7JDtkbnXI2ttOahVq4bJvnSq0EbpZleAVjCK/NqwBJemVcB1t//lXv/
Dl7Zi8zocAqQDHfm4wGhAQLEuSJKgBk6c9J/EjHv2PcupXblYozLfKHseVA9
ecMqZu+EFnBSX0Snn7YmSJ5JmEwmLZjBa3QU+OhExH6ciLLVg8/0wxNSMFh1
xHuzYy6+mGNujROh3J1mnQFEQZzs1eVTN+RbUicpxoik0Jcp4Q9CGNac2ejm
4OuaMRF4J+wCrCJggCH4Ha1SuP4k3K3EpCNNCF6GxcWMGmuA6NzL4FvQppX0
SGUPoIvegqex0t0D5kPxKazmhvUEeCfSFzC5aA+iaHZAOYZpgO6ayXukWksd
4GRUT0Y2Ljcl0vgusnuBpAyxy0iGoZGFxSEaenQYOmsG2Fr2Wc1PdTgiAWkV
KQHIopv5jRjzrIFcyJ+U1ObbNfWDpJ6R+VEuNGKpwwx2Rj9JcndcK4Z0E0YS
qHasEgLDWB0Z4A4kRJtjB4RQNavT7Q1cEKWw2oJ+gbXpSS1gYMyKoAXSQVZG
igYSYY7ugCcdWTUyqZ9bYwb4klBGYQ0Siw4hxbKlG2EhWyM6Sc0gfKApfgNw
apZwDDggzf+BHeAeNHrnPrWig9GsOZIcGZomr1pj6sjUtoOCEmQC0TfTAla5
TXAtD7tDqwNULqDZAjQdfBsyaIlbIsk6kZp9K7Yw83QdZwWYmg8LiN6/41J0
NjKibYMzAjeJkT5KhebQ08GSWQeTQRQ0kha9R6jhoLgsHtmjOlYE7vfKPqH9
aRA0hfpEnBKOyWm0DtRCOncZO6Jl2liL3TlgSbJ5tGCB0YFWgTESa17SCDeN
JeaTo6+UUJ9g+Rogh2OuyMOtHnoXTQfRaE/B9fRLWZVFMPbRBr8e8Y7wykZW
kdQRmCaoDxHnyZ4zxzqre8bBIF4eaPpbyyr+p1RW+ejBOL9HahERxJn56NE2
PwOIsn8rxbyVYt5KMW+lmLdSzFsp5kMpBnPWiBOGClhuPQEiO+W+MrdmKisK
jxyOePGGhVhIEE9iNYfBUsiQhiR8QNUSjrPkhHhTd89gEEl4mr6yElpxGOiy
R3QINOg1uLHKfKEUg6igjRs/hSrGQmFxAlm5SYTVkVroDkQFRizilHDMdMq0
ilBHYKL/iG9lEoCGaYbAVq2FkXbrEvWXEEWaxDJgMKJq4qvLaYh8b3qU6Yjn
WSkGp5mJ4eaTuyxA6S5gS1Ky9hAFGFLADSuTlKR8AhVEDqH2M3jfUOAe+QcT
YtFaRBAz45m5476YK9iYC3HrHKGKvRFTqNZCIC5m1MAizMyzUgzfzsxrcyJv
bFhDKgYUq8OMzXLQsZPR6RAU81sms9cKnicvgGCsWFuwigaGxQ88RtsykFl+
Kx9MAoxqiR4IB/OBoXDIhIrsq24kIxI++60U81aK+d5LMa8FLOGVeRVgvZVi
/rBKMYhDnKYduRCsuZhGC6pg1ckINZpOnNRKABLSSHMXIlYeQE12W36MfKBT
YB9B3bhXGmFGc2hLjQUuS1CFtwiAco5NZG5oTOIOR/7cgannhy/FeIixuMtX
oKHI0Bh2i3h8BpHsd2s3Y5lKYE4uBNVUmErrm6YztEJWASCW+xM86DWP1tlx
W/5DbY6Ro3eEfnbG0sJpDxMZek60NFjgMLpbKQaiJgo2Oeh8BlnweTOcDP9E
5J7lwrZVOgBQ0ousgVK1BJhWgMJvUaWJCaUNMqiuoMJRDmQmQ94UhLv5bBFV
B5RtaLeDkQWUcLKOXEw/6lJM37Cycx5KAigPMnaDz3wyeUREwQp4xguUoDUZ
5kHjkN/ImZpz79CN+DuAliAbiNs8aHvQrnwDoO2uYtMd8W1Rv/AJKJxnRyYB
Akr1nsrnlWLCD1WKuc605Zqu/QDrW7qkge+jRsIu2EO0pk7SIhHgl+BIFLdX
OUB0kynhm7F50K+YbveeSMKyMIEwFzRc0YF8aldxBrQedtrxHGYQ71nrgZuV
omLAMhVDOMDvt6gSSWWBpoQCJhO4auAd5IDqjlC3h5l6tMWhnBcWHITBrHd1
O4L6dnw/RZVpM2iJKF0nhyH8wlZZcXeD3fYsnRyqGUKxUjCum16Kx0JYsg0B
FF8qqvA5NBYQNeJuXCFH5Zu1CJxUCjMDZ20n+4KTa2itbGAQPeGsyAkA9q2o
8j0UVWYqcopYFSQuXUMREQIwY8yozkx4jSYwH1BycNza0EL07fCMWCd6fxxF
FcvY7d6iKg5ESMDNeLgR7oF2kKW7OVXZuwXfbELyFLNxlVIe2IIR66OiStm1
QmCxRj1o3BWiOSpfQIX9wCGZpEUiJosclqKGty6TmMStRR+EHsrpcAt00WlT
C4mQSVhOfhNJeAhzPgneXXCAJvV6QlXg3xjtfLmoghbgk/Blb1OSnx7LKxH+
zuJKCwSKsh8+rYFGPR35jI9B3GykLmLCAlkeWYb3IO0WxoIJcIk5lL6bFVM7
A9GUndqwsJ0D/2YgPz3IQLy4R0WVLwK2G66ZC9g8mnVf7sdXWHaDAKqHVz0U
7klXYpyQTcA41gcDAvCX1sMO6JTZp5EcjT0wIZVPMq51V7RoKINk31mBhRnD
ROIoKi6QSUCFEHJnMGkYv+dFFVfqrFPrTphRVQrsDDgYh21fFVvoyRQQAFbJ
FrnjT81Gy0qwfoEPwQtScnbaidFBEtNnmBbhg7uAKpC1UBwpvlG6QdPWckeb
RG/c9OjzHJ4VVU5QzWBbPYyLAByqGy8ZIDMfJk3wJ82c8Xq2ouHxueBsMlHr
a2i+lc8m9YMCFM7lbiczzm4S9AWeZLrnlll2Lgz0G7iVwKhGsqJl6iBanhVV
hsOlzZ1kPaXztLgH7XkO2NOQVmCwnnIcoA6HSK5D+gTjTrELsddS8B1cs0O0
ghNkJm5Dxt6qLsL8YxCyrOOACPDitAmB5UkPE1B91j0qqsBL8HpZql92nA70
ghZjSHs/sEhlALTYCNmAaUKmctkk4cBnTQYq+pcUVXBKYY2zCvJ5J8TKYGiz
VBOqoyEUIxIWEm0npwRj6HHpIqhmamclZMWniip0YuPpRm0TDU+gNrBcbh3c
OmjxOvtZHfvgEeKkI6GIPjmaMHsaauq7c241Tzn3xaLKd0VXs8pTdGWiCeS9
KiSgx/d6djkPOFnbwU3bUcjkflDbsl95bOh6m1ICyqaMLC9QIGQ8eUGPkHL9
OOJdnpOeF8KZWGVoQbWD3plgSunQl9aU4F4m7PrlgCW8Mq8GLOGVeRVg/TiK
KgRjDWY0FbRCISQxzolZoVEehGOYlRtNtWByXrHHzc+RdvTy0+5WVGno+dTx
HLLlmGB4lJAXwE0gCtoNAFEkPrgrkEGUddUQLMTm2rL21UUVMW4wOMWiYQCK
QQiIc4blFyaxFqQ9EAYnAxbAU1TJnBR3JDheEYXEv0hWLmu2mBKxtFwRuuBq
J1YZqxplzxtTW6WVafZyg75tLaRQ1Zt0XmizfupcJlUrcI5hIAzDwFeuRWqt
VjFEDd96Nk6ZcQmkT25OBYykp9ENjTfIr4FbNoEU63gTTAmwc8BidAhz2Kut
gsrtpx6jHNW9Xl1Uwf8yzBajzXBjFYgmogy5u4D9ZUqqORF+m6xp6cRJp9An
RD/8BX6A6Yx97mFoQVj3QF2QDzy9ZC2/VDFumU4EjRkGrFrxXQs2SB30iJss
29NvEEFLyYgcB3Tk6Dz6gpBQHeN6UE9yXHGf5Tix7+AVQJiTP6XdiiokMJ8O
1ZPLEXeJsoOqgQmGlrzEnaINgCPgQ1HSXTkgBC3WIlaA3kB5EHTuNqKZoXNM
q1bjtDhmOqhqG7VUA1Q7rUSmSp3rnShKA4aO50lRpa09k1uq3eTJ8OkxwSUX
nGUmoGqrhzuTrscE+yr2hwrnyYBihDdwkEYpE92BO4CsVNtGNvjF/BLSOGwV
bAki24XhZCLs7N2yevgyya2nRRWtuSMWtQYXNgW3nFbjInn5RXIFMMeRgOLV
23aU+0WVakQaQbFRq0StfuUwKxYATKGXRgiAxHMympgewHY6uQ16qAqUIyYJ
eXLPk+q9f15RJf50iiqvXN3yVoh5K8S8FWLeCjFvhZifeiFmxGl3H9wsAPN4
bXAB1Rh8l5zyA9beDZESmL4ZT2sL/kbWTUlRUtQgIrIDkZL3CzCaaNZDz9sF
flwJsOa6KW8trcbVwPgMLk7eHwYhtZcKMQFFNzF5PZH1g1uSFh5thz7vgA3K
L8oVlKynhKpfLDQ4RIZCCwPNhnvoktwNK8TYF4eGxI6BAU5TpZ1IqbjrIVq3
1q1AcNWG7i1Iu+jXfFaI6eDEJTuHlpg3EXqeJ0lIFkSjlqX0hSQFDviTGfOk
rxn9YGPAyHA82ulAC3pcjnicHiTG62L5kK8n425IkmmRRvUgWglBPXPDS+rZ
JLH2fHULKolO4qEyiT2xloxosVrB0cJsWAJ09hAPRT0/5OqLODBzEzKzJIgG
glaGIja1FAxKH5crT27jQIArfrbFregKYiNKTyPWGONpgCLb/Vsh5q0Q870X
Yl4LWMIr8yrAeivE/GEVYhBYQ24FvaWlWGalpl9ZxO5OlYZjpKGJNEJT+QKf
h69tvqHUEoOEF65a9YLOzWUiUPBAKRvMPXdHrBTEhc9Y3u4y+i8j5WsCS2xC
mnpUYrc/gkLMnDS3Il6Giir8Fqw6gqou0IW8SDIQA66LiY705jCK26Kx6FNH
lsRauZ3yboaNRK5CGWar5KMrpxogzARnNMcoE1AABqRStWIV5RPuCjHL5QC/
F5xPAFoS0+D96OCjqiTaDDTdbmNrsaknG0/OwOzRQqHS4HUzl3Yho5ugdW2h
RTMx+WkDZei+QhwlLZG+lqag4xIsrk2J3gpVtmLox1yIyc7lRdut1icRUKWp
FX3F1So4NId2VQFWgIQ2G2+RlbYHwYq6e97APFkVgAM9rYHn15gO3wIseOds
SLDUjnqMBaSecsEriFi1CdNgSD+vEJN+XyHmHxl41VD460MBRl98SwFGP35S
gNE37gowut7X//YPf/meb+tF1F//4hf/+i9f/9PPv/6MeozqL1c9Jjypx+iv
393++m6LXHADWq8qrsWeIHUIoFhtGwCv0yppEQYwSrrNgwxEY1WPGunWYMPm
9t/zxp/m3fHdOgg4jFURIaC2Kg2tIGURBqScX85jeBfeBJYYy4B7WB2ow53v
qTQSXlUa2eml0gjxDjqcI0iGmQFRUJPWnxVWbzhKrH7zoackgcxUNnO8Rf1n
m4u2bpX4f1wc6bI1TMtG24WNZvCBBgmAO6IMWedoSRwD3eJGOacP/EQ8oKwE
6h7uE8URPWGoJa0SFxlBqHbmpwXbsDMXKhCqiBeSpi8Q0JTNJ0sNo0zd44ND
+l6KIxFFdFDvhCFkf7DVREH1iJ+usxCQcQChZ+r80iI+UmSiHAtEjiHCW4en
xRFUpwQoaaqeI9UhAe1D6XpkH5jn2DBORfIeK6SN7BOZOpqByMUY7kuLI2Fo
zy4erYGoyLNUkHMNPd9PwAkk5tSppMP/EaZkiDl0LEKhAZxI15bRh/JIGvib
7URi/NG04JvOnorCVdIxgdPB7kQwBgY9t2/bUksnfZF4Zbxc3gD4t2pCzHrC
NmEI+tJ2EjnbmRLMh9adhPJ1t450a6DqIDUZG7ySfbz35kuw5QYt5sIWrR8d
GGecMPzWxVE4uT7QWAQSbEzLoEFsxrVX/Cihd9RyBHAW3HnpFJPQEQoRl1QR
7HCnjR7dqVXbRD7uBulwuh7tphOClsZmg23RDo2GXEvPd764gDOuKiTuwX29
6ms74OptQPSs7HBSyNaWq8rwThsHIhOJXEQc6CyQZ9YedzlT0CM+LX/mI5Xx
tZsIkYUivhkpZG7AV63tN/NC6w0aWKuGK2rrkTNHawwyTwvAVTJriNwSZ9eS
Yu3EgKe8XC3+hRTCVQEJqKOJWMhE3wnuS5y5RR2r4E/InG6HnCFKXkbGI07p
XM0TjO56BkccGTnYnoLDiRBX3rdTP+XNmWKd+tKwgZY0Yuo6Trcwa1UiPaLS
0N86MWL64aEVNN8EFvLUFgftVDjfGfZNewb7L/vz75jgBsP5UYIX+RNCBI0Y
uk6PwZHNWZguv/yoLg5UGwrNAV3IO4ddM9rhBLVUizI8X5pz5p7PX5VzRkl3
GWQbivb82IGNgA07Dh/pjrsrzERWrWO6tQMkhPi3uibhgpon/87eeSOhv5D8
HriPQDJ7hYMvCA5khI+EhD0wQlvLtuHqkeUrXW8p57xOV5URA8dHGM9xtwXE
+piJDLq5IrCI6W9HEZUsA6Gvj1aBIL8I4Ii9WCAzeRhw6eRcZJ7dq23ysWYS
3YdQwKjAb9q5U7nBJI/Sdv06BGJjQMF4XIEenjabJgk3nEfvqvg1B+PKnBcc
UskDfywTE3uoqKXm8+bexQMzWryFWtwYS8yxjm3QLsKCb9y5YqINXUG00qq4
92xER+4iAcCP4Jpal0a6Vb8xmUduzR3bnu3iMJ8pjx7UkQ1wmnVKD9cGUTnB
aGLu5Jgyto7rYjsPaljFeOYv4U1P0KMNrCyTxS9ZgmeQHTqLQfu5NuamTmuI
1u0t+LG9TqmgrySwK5Bh9T1YqaE9Txk3o7q1/mdEYWUPCEz8F1ZXleusXf7Z
TQQK9le51RpWM6Rd4dKwr41U+4nPnEFtI6+FvDWuVcOyg5b1ozUEm1bAwxPP
es61ZRbcZ/5aNxVGyNejqsfnUdRIEsdUHHZuavQmgLbj7oEZzzAKk0HA8p8j
NOTvcdto8FqykNR9nsvLPzmX98qn7m/O8M0ZvjnDN2f45gxf7wyjphY6zd0j
/GvOwbo1hnzY9YQT2EOeFuZaz7f6PhLU9VqqtPEN7iVnaLmFnkgd75cU7aZR
uzrriHccjEWIJGm7NlU4n74GU6/zKnE7C3B/fjzl0Zp8r4cySc+lu1BdR0h2
7oPLachOvj3g/qLy9aS7xQxV3pXxqTxzhgVKaTos0g2tC2lyrEInNIBcqI7p
OLYk9Cnk4pjltFowO15nTOH83JszfHOGX+oMX5VzRkn35gz/MJ3hKvitbGF3
bWYi3CyhNfNJNV3Ht4R2ZnKdO+GNIk6HS6mcppsBCOnZUYs/hDOspDYzsNOy
JVY6roPb6IDxMwXGG+RoWpuBMOkL3T5pvLM1M100hM7cnZWIUUYj1LlpHQOu
1Qkbx+WIsKITDftMhEmET7oW+O8CT3O5hGHptPX/0hlq1xcDSvJzpXpO0IIB
RpOpaaQg6ezsopPYGiCyzjgWNz/DaAUJ9wn3kP/ur/Vqjo/e8vDk/SnP/OPH
v/HTesvDK60j1HsQaXUBBBAiFF0CqjxoBb7O7+xZh8/oYFTmK+ugu96vFS5Y
R53FLTqRjtEhB3kFnA/JI8AgILRMZQGUhCthRuzgOreUPJkDVIIhYRj7e73n
R2avTci0Nm2J4HYooVZ01Axpk/SNbjFrpKUb2kJIFLraZnambV+GHoRn8/x9
NgTwQG9X2kRPleVaOXDQFKCTFMQ6Fny12ktwdGiLy6aR1OtUnTsG3LSX1Ld0
fThNis81NBhwI7cQtS0BcNEWUAg7Srtp6caMyBIw0fE/zCci+2VfWirECIQj
iK9lgR7JFoQysOEEK2HLCIy2ggaqy2/E5LmWjC6tkrf5JV9afdJ5tsLpqmX7
2jnJfAMctoIQ8QKUHdxApMYNWFnDHwctEFfyLeePXKm2WhwR3fBwp86/OZar
Ac18lUMTenotQmYu10YWIUaqCwa0AvjRCp9wkZhGLTO81reOCFcNhiPH4CQp
J1KVwQEfRyegfclGJ0PrOKqhs6ITCvETLjJkO1Cq5cSyYhIJhg7dEe8M6aWB
nMfRRLsHlD+NziYRmxEYRcsYvHn0oiEuh5bGxaKsQuvICjfRUlHn3CGAQ2tD
Gq1B5+AiumnlPVT0Swal6uzEOCFyKkoCywiLjXOQj1xDPC9Oo+8IKC1mAuG1
BoOpiIgPq2Vow4x7SaTVlHlp2Y33wQ54al9rF/tooP5AFDv9mlOnPIqKiyE1
sQE7Rm0JNmjAuLOTpsHmxblgtYaB1/KxfZ10hFVYCVWF+NBSmakTasfyiznV
Pt4c5eURs93H1G07ToE/dHyfy9l1Cf7kx9b6cLe0oiZqhQlQiYbCDn27F7gt
NSPPS+sMzvGi8o04xb6jeLCppEjVWlTsUT1R5+W2jDqftqF9cTXNJ/NlkPIB
UYIfqRvGFYGPeNUCa8QaslBLmKDlomONKk1gTBI6tlkVgo+kOyKwoRxyOto6
1obpOoY/EcY7R0xv10FwqxDSO2qRHvdEMlet6NYnCEB+K6NTOrIYN9UITpV0
8GWjM6hxEiunLKxGUPU8JdRslCQQxkHoqPXZy9GjPpyD9lkD6Pk6JMwAhW0B
fPQ4SKphSkeuEPa1R17CvzRVupaWC30q4c23Z/xDwjcgyE2dnCVhY3EsfK6d
YyeCYpvoJGvj2JjHlhcD73vVEZNgElqCZNeROYog4s/qrB3vSGUI55ThU3Vc
v5jrNLraAHRfPTGi3UghVMQbIU8sSmgfPBh+FS44bZXasxVsHWLfY1S6zuBz
3DRMPdrVAVk0t+Cv4nyxvP1MnvxgpyX/v9tNlvO1CyMx0zDTAN6SkG6tXDuQ
XoStaSR9aOhQgK0F6BsT2A3xlDHPtd6d9K7DxXed5JI27fhr1qclewU1WEKd
3Y5cv221jGADxiqZ/SMRJ3oylkNEaUl1uBoLrkXnkYIwOdE1hIg27Tgdf5oA
/xGBxK4dLBFEsi+JE6n4HkByvUdBumBCeXKojqDGdOHrxEnoG60HcLcluSgk
3Cf4ZG16UZwErVTGRkA2eMuN/HAV1VGii3CEx8pZHKF21SJZcsQuN+6SZH10
6nt8UZwUvZLh2uCCGdEDhl6AX7Rn1ptNnLiMgWx6FYSWXMwzjQzqXloaAe2n
N3HyWJyIK7UnGspNdJiLniPD2Su9s1oTO3cutXg4Mnt7wIfNMMMqeEAEZise
75zw7HVKG2e9iKckaKSgRkDbkQTQUUcIDlWDyKahzVWq2ejQ0f4jESfTJvhJ
deZOtDPxmGHkBzTHiE9UOXcnlFf1TGyEr2lknlrX3LWmtsTPECfX2e356NiR
ANG3rtf+nD2SQ0lna8/WQyOYufa5gq12FVBYZcGlssF5tTgpa4RmALuDISMW
GkJkxoA0W10HJerEuaHjBUcjN2nQ7RxK2XwLukynIyYAmnBt4mM4NpJC+/6C
1gzr7Mu6CniUMTcSFC0S/HowQKZM7uC0F9/2sy/U9mmao2TuGIrm+txTh9x0
lVfwkklVW71UouggdhVFtI5qDwTb1jpv6xY6cpcRDUIOLROiNlTspTNyWtqy
TRlHRPfc6d5uH9E3rxcnRMy12LtikrZMEO2z11MKBqNLnIwD/sSg9fh+bQax
DFzeaBhLpkIHA6MMHX3RIQokfbGpaBV/Ip6CdKr2B6QzDrPlvVa5MynER9dK
fuyAqonEy7YL5MOcgaTOr2WZzTFVZ9SxITTWqLjWlw5q8Ko6oqmYcotf+yxx
8nvPD3x79v5UowyZ+NS2y8AJvo7syThiSJUwZtq1c8+HNhwJ0wO52FUbGcSp
wWiT+j8OiYEs0uNZWPTw6YUnParr2h43UqjZM09Hf/TQVVTGyhoffYtIZoAN
2b0+8fSxuqIQ3dZnvW3ManABVdU6oz+7LZwfdm9unfpMM4c+3jItjz2VM18W
GfFVImOWF5/M69mrtksBGpamVYAfJYGEsNIbPuotKXvhu7U+B/+GqjpJJxhD
w25ei5feZMYjmQH4T72Tj9vSnTKHnh+cgFXVY3pt+AoL7WoL0K5jq0Xf2men
ytqOO+37pzpMAQCqI8tPKcyqKv3AAVzdr+OoXdQLfUg3PXpK8oNEMIEatPGt
GzjolTrBemei9qzU0EitKXoayVZMX9LDRB3hPEcoQTuOSif3IjeDhHAX7npm
+DlKwXrrcKmYfhcOzlrn1utIM23iPjrLLLY+dDq3zrxAYeHLIeo904nY3LP0
5oVXagWdrbLoJzOCtx/N1qTD1JnejO0KOqwlZjicyTzknHYgFgROQxeB0Noa
7REDDTSIU2cZLxkypMGSO9Z7HIl6AkwhFJae3TDqREGWBkJutFPo2TraijdP
60ZnmJOJ5IJOAYl0UAffjZHQUit3FELA26Maz8C/kV1Ztv6jtDOfmXcPaWc9
ceIZXSkN5E2u9Nw4lVgDWI/0O32reocnAs7OWVJEe3u996Asq/fwAKBIYR3T
3qGBTKoExt0ahM85uTCD9FWn9IMzCG/i2qMUxtg0f4IpV1j8LxqtBaDiHAIA
<!-- [rfced] FYI, we updated artwork to sourcecode throughout the document,
excluding the artwork in Sections 3.2, 3.3, 5, and 6. Please confirm that
this is correct.
In addition, please consider whether the "type" attribute of any sourcecode
element should be set and/or has been set correctly. Currently, the type value
is not set except for the sourcecode element in final appendix, where we set
type="test-vector".
The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.
-->
<!-- [rfced] In the HTML and PDF outputs, the text enclosed in <tt> is output in
fixed-width font. In the TXT output, there are no changes.
We've included a list of terms enclosed in <tt> in this document. Some of
these terms appear both with and without <tt> tags. Please review to ensure
the usage of <tt> is correct and consistent and let us know if the output is
acceptable or if any updates are needed.
<tt>0x00</tt>
<tt>a</tt>
<tt>AuthClientFinalize</tt>
<tt>AuthClientStart</tt>
<tt>AuthRequest</tt>
<tt>AuthResponse</tt>
<tt>AuthServerFinalize</tt>
<tt>AuthServerRespond</tt>
<tt>auth_tag</tt>
<tt>blinded_element</tt>
<tt>blind</tt>
<tt>Blind()</tt>
<tt>b</tt>
<tt>buf</tt>
<tt>CleartextCredentials</tt>
<tt>ClientAkeState</tt>
<tt>ClientAuthenticationError</tt>
<tt>client_identity</tt>
<tt>client_private_key</tt>
<tt>client_public_key</tt>
<tt>client_state</tt>
<tt>ClientState</tt>
<tt>concat(0x01, 0x0203, 0x040506) = 0x010203040506</tt>
<tt>context</tt>
<tt>CreateCredentialRequest</tt>
<tt>CreateCredentialResponse</tt>
<tt>CreateRegistrationRequest</tt>
<tt>CreateRegistrationResponse</tt>
<tt>credential_identifier</tt>
<tt>CredentialRequest</tt>
<tt>CredentialResponse</tt>
<tt>DeriveDiffieHellmanKeyPair()</tt>
<tt>DeriveDiffieHellmanKeyPair</tt>
<tt>DeriveKeyPairError</tt>
<tt>element</tt>
<tt>envelope_nonce</tt>
<tt>EnvelopeRecoveryError</tt>
<tt>Envelope</tt>
<tt>evaluated_element</tt>
<tt>export_key</tt>
<tt>Extract()</tt>
<tt>FinalizeRegistrationRequest</tt>
<tt>GenerateKE1</tt>
<tt>GenerateKE2</tt>
<tt>GenerateKE3</tt>
<tt>Hash()</tt>
<tt>ikm</tt>
<tt>info</tt>
<tt>InvalidInputError</tt>
<tt>KE1</tt>
<tt>KE2</tt>
<tt>KE3</tt>
<tt>key</tt>
<tt>Km2</tt>
<tt>k</tt>
<tt>Label</tt>
<tt>L</tt>
<tt>MAC()</tt>
<tt>masked_response</tt>
<tt>masking_key</tt>
<tt>modeOPRF</tt>
<tt>msg</tt>
<tt>Nh</tt>
<tt>nil</tt>
<tt>Nm</tt>
<tt>Nn + Nm</tt>
<tt>Nn</tt>
<tt>Npk</tt>
<tt>Nseed = 32</tt>
<tt>Nseed</tt>
<tt>Nsk</tt>
<tt>n</tt>
<tt>Nx</tt>
<tt>oprf_output</tt>
<tt>oprf_seed</tt>
<tt>pk</tt>
<tt>preamble</tt>
<tt>prk</tt>
<tt>randomized_password</tt>
<tt>record.client_public_key</tt>
<tt>record.envelope</tt>
<tt>record.masking_key</tt>
<tt>record</tt>
<tt>RecoverCredentials</tt>
<tt>Recover</tt>
<tt>RegistrationRecord</tt>
<tt>RegistrationRequest</tt>
<tt>RegistrationResponse</tt>
<tt>salt</tt>
<tt>seed</tt>
<tt>ServerAkeState</tt>
<tt>ServerFinish</tt>
<tt>server_identity</tt>
<tt>server_private_key</tt>
<tt>server_public_key</tt>
<tt>server_state</tt>
<tt>ServerState</tt>
<tt>session_key</tt>
<tt>sk</tt>
<tt>Store</tt>
<tt>s</tt>
<tt>true</tt>
<tt>u</tt>
-->
<!-- [rfced] Terminology
a) We note that the following terms are used as protocol names as well as
standalone terms. Is the differentiation intentional (such as the difference
between an exchange and a protocol)? For example, we see that both AKE and
AKE protocol are used throughout the document. Please review the following
terms and let us know if any updates are needed for consistency.
AKE vs. AKE protocol
aPAKE vs. aPAKE protocol
b) We note that the following terms appear inconsistently throughout the
document. Please review each term carefully and let us know how we may update
for consistency. Or, let us know if there are any particular patterns that
should be followed (e.g., capitalized element names) and provide us with a
list of terms that should adhere to that pattern.
Envelope (capital E) vs. envelope (lowercase e)
Group (capital G) vs. group (lowercase g)
-->
<!-- [rfced] We note that there is inconsistent use of symbolic vs. numeric
citation tags for RFCs (e.g., [PBKDF2] for RFC 8018 vs. [RFC5869] for RFC
5869). Should this remain as is or be made consistent throughout the document?
-->
<!-- [rfced] The following lines extend beyond the margin. How may we break
these lines so they fit within the 69-character limit?
Section 4 (3 characters beyond the margin):
- server_public_key, the encoded server public key for the AKE protocol.
- server_public_key, the encoded server public key for the AKE protocol.
Section 6.2.2 (2 characters beyond the margin):
def GenerateKE2(server_identity, server_private_key, server_public_key,
Section 6.2.3 (1 character beyond the margin):
AuthClientFinalize(cleartext_credentials, client_private_key, ke2)
Section 6.4.2.1 (3 characters beyond the margin):
def Preamble(client_identity, ke1, server_identity, credential_response,
Section 6.4.3 (2 characters beyond the margin):
def AuthClientFinalize(cleartext_credentials, client_private_key, ke2):
-->
<!-- [rfced] FYI - We have added expansions for abbreviations upon first
use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness. If there are
no objections, we will also eliminate instances where abbreviations are
expanded multiple times to limit repetition, e.g., authenticated key
exchange (AKE).
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
In particular, please consider whether "tradition" should be updated for
clarity. While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-l
ibrary/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
--> -->
</rfc> </rfc>
 End of changes. 329 change blocks. 
2001 lines changed or deleted 1238 lines changed or added

This html diff was produced by rfcdiff 1.48.