doc: Add RFC documents

1 files changed, 1283 insertions, 0 deletions

diff --git a/doc/rfc/rfc9383.txt b/doc/rfc/rfc9383.txt
new file mode 100644
index 0000000..cbe97d1
--- /dev/null
+++ b/doc/rfc/rfc9383.txt
@@ -0,0 +1,1283 @@
+
+
+
+
+Independent Submission                                        T. Taubert
+Request for Comments: 9383                                    Apple Inc.
+Category: Informational                                       C. A. Wood
+ISSN: 2070-1721                                           September 2023
+
+
+    SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE)
+                                Protocol
+
+Abstract
+
+   This document describes SPAKE2+, a Password-Authenticated Key
+   Exchange (PAKE) protocol run between two parties for deriving a
+   strong shared key with no risk of disclosing the password.  SPAKE2+
+   is an augmented PAKE protocol, as only one party has knowledge of the
+   password.  This method is simple to implement, compatible with any
+   prime-order group, and computationally efficient.
+
+   This document was produced outside of the IETF and IRTF and
+   represents the opinions of the authors.  Publication of this document
+   as an RFC in the Independent Submissions Stream does not imply
+   endorsement of SPAKE2+ by the IETF or IRTF.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not candidates for any level of Internet Standard;
+   see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9383.
+
+Copyright Notice
+
+   Copyright (c) 2023 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Requirements Notation
+   3.  Definition of SPAKE2+
+     3.1.  Protocol Overview
+     3.2.  Offline Registration
+     3.3.  Online Authentication
+     3.4.  Key Schedule and Key Confirmation
+   4.  Ciphersuites
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Appendix A.  Protocol Flow
+     A.1.  Prover
+     A.2.  Verifier
+     A.3.  Transcript Computation
+     A.4.  Key Schedule Computation
+     A.5.  Protocol Run
+   Appendix B.  Algorithm Used for Point Generation
+   Appendix C.  Test Vectors
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   This document describes SPAKE2+, a Password-Authenticated Key
+   Exchange (PAKE) protocol run between two parties for deriving a
+   strong shared key with no risk of disclosing the password.  SPAKE2+
+   is an augmented PAKE protocol, as only one party makes direct use of
+   the password during the execution of the protocol.  The other party
+   only needs a record corresponding to the first party's registration
+   at the time of the protocol execution instead of the password.  This
+   record can be computed once, during an offline registration phase.
+   The party using the password directly would typically be a client and
+   would act as a Prover, while the other party would be a server and
+   would act as a Verifier.
+
+   The protocol is augmented in the sense that it provides some
+   resilience against the compromise or extraction of the registration
+   record.  The design of the protocol forces the adversary to recover
+   the password from the record to successfully execute the protocol.
+   Hence, this protocol can be advantageously combined with a salted
+   Password Hashing Function to increase the cost of the recovery and
+   slow down attacks.  The record cannot be used directly to
+   successfully run the protocol as a Prover, making this protocol more
+   robust than balanced PAKEs, which don't benefit from Password Hashing
+   Functions to the same extent.
+
+   This augmented property is especially valuable in scenarios where the
+   execution of the protocol is constrained and the adversary cannot
+   query the salt of the Password Hashing Function ahead of the attack.
+   For example, a constraint may be when physical proximity through a
+   local network is required or when a first authentication factor is
+   required for initiation of the protocol.
+
+   This document has content split out from a related document,
+   [RFC9382], which specifies SPAKE2.  SPAKE2 is a symmetric PAKE
+   protocol, where both parties have knowledge of the password.  SPAKE2+
+   is the asymmetric or augmented version of SPAKE2, wherein only one
+   party has knowledge of the password.  SPAKE2+ is specified separately
+   in this document because the use cases for symmetric and augmented
+   PAKEs are different and therefore warrant different technical
+   specifications.  Neither SPAKE2 nor SPAKE2+ was selected as the
+   result of the Crypto Forum Research Group (CFRG) PAKE selection
+   competition.  However, this password-based key exchange protocol
+   appears in [TDH] and is proven secure in [SPAKE2P-Analysis].  It is
+   compatible with any prime-order group and relies only on group
+   operations, making it simple and computationally efficient.  Thus, it
+   was felt that publication was beneficial to make the protocol
+   available for wider consideration.
+
+   This document was produced outside of the IETF and IRTF and
+   represents the opinions of the authors.  Publication of this document
+   as an RFC in the Independent Submissions Stream does not imply
+   endorsement of SPAKE2+ by the IETF or IRTF.
+
+2.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Definition of SPAKE2+
+
+   Let G be a group in which the computational Diffie-Hellman (CDH)
+   problem is hard.  Suppose G has order p*h where p is a large prime; h
+   will be called the cofactor.  Let I be the unit element in G, e.g.,
+   the point at infinity if G is an elliptic curve group.  We denote the
+   operations in the group additively.  We assume that there is a
+   representation of elements of G as byte strings: common choices would
+   be SEC 1 uncompressed or compressed [SEC1] for elliptic curve groups
+   or big-endian integers of a fixed (per-group) length for prime field
+   DH.  We fix a generator P of the (large) prime-order subgroup of G.
+   P is specified in the document defining the group, and so we do not
+   repeat it here.
+
+   || denotes concatenation of strings.  We also let len(S) denote the
+   length of a string in bytes, represented as an eight-byte little-
+   endian number.  Finally, let nil represent an empty string, i.e.,
+   len(nil) = 0.
+
+   KDF is a key derivation function that takes as input a salt, input
+   keying material (IKM), info string, and derived key length L to
+   derive a cryptographic key of length L.  MAC is a Message
+   Authentication Code algorithm that takes a secret key and message as
+   input to produce an output.  Let Hash be a hash function from
+   arbitrary strings to bit strings of a fixed length.  Common choices
+   for Hash are SHA256 or SHA512 [RFC6234].  Section 4 specifies
+   variants of KDF, MAC, and Hash suitable for use with the protocols
+   contained herein.
+
+   Let there be two parties, a Prover and a Verifier.  Their identities,
+   denoted as idProver and idVerifier, may also have digital
+   representations such as Media Access Control addresses or other names
+   (hostnames, usernames, etc.).  The parties may share additional data
+   (the context) separate from their identities, which they may want to
+   include in the protocol transcript.  One example of additional data
+   is a list of supported protocol versions if SPAKE2+ were used in a
+   higher-level protocol that negotiates the use of a particular PAKE.
+   Another example is the inclusion of the application name.  Including
+   these data points would ensure that both parties agree upon the same
+   set of supported protocols and therefore prevents downgrade and
+   cross-protocol attacks.  Specification of precise context values is
+   out of scope for this document.
+
+3.1.  Protocol Overview
+
+   SPAKE2+ is a two-round protocol that establishes a shared secret with
+   an additional round for key confirmation.  Prior to invocation, both
+   parties are provisioned with information such as the input password
+   needed to run the protocol.  The registration phase may include
+   communicating identities, protocol version, and other parameters
+   related to the registration record; see Section 3.2 for details.
+
+   During the first round, the Prover sends a public share, shareP, to
+   the Verifier, which in turn responds with its own public share,
+   shareV.  Both parties then derive a shared secret used to produce
+   encryption and authentication keys.  The latter are used during the
+   second round for key confirmation.  (Section 3.4 details the key
+   derivation and confirmation steps.)  In particular, the Verifier
+   sends a key confirmation message, confirmV, to the Prover, which in
+   turn responds with its own key confirmation message, confirmP.  (Note
+   that shareV and confirmV MAY be sent in the same message.)  Both
+   parties MUST NOT consider the protocol complete prior to receipt and
+   validation of these key confirmation messages.
+
+   A sample trace is shown below.
+
+                    Prover                     Verifier
+
+                      |        (registration)     |
+                      |<- - - - - - - - - - - - ->|
+                      |                           |
+                      |   (set up the protocol)   |
+   (compute shareP)   |            shareP         |
+                      |-------------------------->|
+                      |            shareV         | (compute shareV)
+                      |<--------------------------|
+                      |                           |
+                      |       (derive secrets)    | (compute confirmV)
+                      |           confirmV        |
+                      |<--------------------------|
+   (compute confirmP) |           confirmP        |
+                      |-------------------------->|
+
+3.2.  Offline Registration
+
+   The registration phase computes the values w0 and w1, as well as the
+   registration record L=w1*P.  w0 and w1 are derived by hashing the
+   password pw with the identities of the two participants.  w0 and the
+   record L are then shared with the Verifier and stored as part of the
+   registration record associated with the Prover.  The Prover SHOULD
+   derive w0 and w1 from the password before the protocol begins.  Both
+   w0 and w1 are derived using a function with range [0, p-1], which is
+   modeled as a random oracle in [SPAKE2P-Analysis].
+
+   The registration phase also produces two random elements, M and N, in
+   the prime-order subgroup of G.  The algorithm for selecting M and N
+   is defined in Appendix B.  Importantly, this algorithm chooses M and
+   N such that their discrete logs are not known.  Precomputed values
+   for M and N are listed in Section 4 for each group.  Applications MAY
+   use different M and N values, provided they are computed, e.g., using
+   different input seeds to the algorithm in Appendix B, as random
+   elements for which the discrete log is unknown.
+
+   Applications using this specification MUST define the method used to
+   compute w0 and w1.  For example, it may be necessary to carry out
+   various forms of normalization of the password before hashing
+   [RFC8265].  This section contains requirements and default
+   recommendations for computing w0 and w1.
+
+   The RECOMMENDED method for generating w0 and w1 is via a Password-
+   Based Key Derivation Function (PBKDF), which is a function designed
+   to slow down brute-force attackers.  Brute-force resistance may be
+   obtained through various computation hardness parameters such as
+   memory or CPU cycles and are typically configurable.  The scrypt
+   [RFC7914] function and the Argon2id [RFC9106] function are common
+   examples of PBKDFs.  Absent an application-specific profile,
+   RECOMMENDED parameters (N, r, p) for scrypt are (32768,8,1), and
+   RECOMMENDED parameters for Argon2id are in Section 4 of [RFC9106].
+
+   Each half of the output of the PBKDF will be interpreted as an
+   integer and reduced modulo p.  To control bias, each half must be of
+   length at least ceil(log2(p)) + k bits, with k >= 64.  Reducing such
+   integers mod p gives bias at most 2^-k for any p; this bias is
+   negligible for any k >= 64.
+
+   The minimum total output length of the PBKDF then is 2 *
+   (ceil(log2(p)) + k) bits.  For example, given the prime order of the
+   P-256 curve, the output of the PBKDF SHOULD be at least 640 bits or
+   80 bytes.
+
+   Given a PBKDF, password pw, and identities idProver and idVerifier,
+   the RECOMMENDED method for computing w0 and w1 is as follows:
+
+   w0s || w1s = PBKDF(len(pw) || pw ||
+                      len(idProver) || idProver ||
+                      len(idVerifier) || idVerifier)
+   w0 = w0s mod p
+   w1 = w1s mod p
+
+   If an identity is unknown at the time of computing w0s or w1s, its
+   length is given as zero and the identity itself is represented as an
+   empty octet string.  If both idProver and idVerifier are unknown,
+   then their lengths are given as zero and both identities will be
+   represented as empty octet strings.  idProver and idVerifier are
+   included in the transcript TT as part of the protocol flow.
+
+3.3.  Online Authentication
+
+   The online SPAKE2+ protocol runs between the Prover and Verifier to
+   produce a single shared secret upon completion.  To begin, the Prover
+   selects x uniformly at random from the integers in [0, p-1], computes
+   the public share shareP=X, and transmits it to the Verifier.
+
+   x <- [0, p-1]
+   X = x*P + w0*M
+
+   Upon receipt of X, the Verifier checks the received element for group
+   membership and aborts if X is not in the large prime-order subgroup
+   of G; see Section 6 for details.  The Verifier then selects y
+   uniformly at random from the integers in [0, p-1], computes the
+   public share shareV=Y, and transmits it to the Prover.  Upon receipt
+   of Y, the Prover checks the received element for group membership and
+   aborts if Y is not in the large prime-order subgroup of G.
+
+   y <- [0, p-1]
+   Y = y*P + w0*N
+
+   Both participants compute Z and V; Z and V are then shared as common
+   values.  The Prover computes:
+
+   Z = h*x*(Y - w0*N)
+   V = h*w1*(Y - w0*N)
+
+   The Verifier computes:
+
+   Z = h*y*(X - w0*M)
+   V = h*y*L
+
+   The multiplication by the cofactor h prevents small subgroup
+   confinement attacks.  All proofs of security hold even if the
+   discrete log of the fixed group element N is known to the adversary.
+   In particular, one MAY set N=I, i.e., set N to the unit element in G.
+
+   It is essential that both Z and V be used in combination with the
+   transcript to derive the keying material.  The protocol transcript
+   encoding is shown below.
+
+   TT = len(Context) || Context
+     || len(idProver) || idProver
+     || len(idVerifier) || idVerifier
+     || len(M) || M
+     || len(N) || N
+     || len(shareP) || shareP
+     || len(shareV) || shareV
+     || len(Z) || Z
+     || len(V) || V
+     || len(w0) || w0
+
+   Context is an application-specific customization string shared
+   between both parties and MUST precede the remaining transcript.  It
+   might contain the name and version number of the higher-level
+   protocol, or simply the name and version number of the application.
+   The context MAY include additional data such as the chosen
+   ciphersuite and PBKDF parameters like the iteration count or salt.
+   The context and its length prefix MAY be omitted.
+
+   If an identity is absent, its length is given as zero and the
+   identity itself is represented as an empty octet string.  If both
+   identities are absent, then their lengths are given as zero and both
+   are represented as empty octet strings.  In applications where
+   identities are not implicit, idProver and idVerifier SHOULD always be
+   non-empty.  Otherwise, the protocol risks unknown key-share attacks
+   (discussion of unknown key-share attacks in a specific protocol is
+   given in [RFC8844]).
+
+   Upon completion of this protocol, both parties compute shared secrets
+   K_main, K_shared, K_confirmP, and K_confirmV as specified in
+   Section 3.4.  The Verifier MUST send a key confirmation message,
+   confirmV, to the Prover so both parties can confirm that they agree
+   upon these shared secrets.  After receipt and verification of the
+   Verifier's confirmation message, the Prover MUST respond with its
+   confirmation message.  The Verifier MUST NOT send application data to
+   the Prover until it has received and verified the confirmation
+   message.  Key confirmation verification requires recomputation of
+   confirmP or confirmV and checking for equality against the data that
+   was received.
+
+3.4.  Key Schedule and Key Confirmation
+
+   The protocol transcript TT, as defined in Section 3.3, is unique and
+   secret to the participants.  Both parties use TT to derive the shared
+   symmetric secret K_main from the protocol.  The length of K_main is
+   equal to the length of the digest output, e.g., 256 bits for Hash() =
+   SHA-256.  The confirmation keys K_confirmP and K_confirmV, as well as
+   the shared key K_shared, are derived from K_main.
+
+   K_main = Hash(TT)
+   K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys")
+   K_shared = KDF(nil, K_main, "SharedKey")
+
+   Neither K_main nor its derived confirmation keys are used for
+   anything except key derivation and confirmation and MUST be discarded
+   after the protocol execution.  Applications MAY derive additional
+   keys from K_shared as needed.
+
+   The length of each confirmation key is dependent on the MAC function
+   of the chosen ciphersuite.  For HMAC, the RECOMMENDED key length is
+   equal to the output length of the digest output, e.g., 256 bits for
+   Hash() = SHA-256.  For CMAC-AES, each confirmation key MUST be of
+   length k, where k is the chosen AES key size, e.g., 128 bits for
+   CMAC-AES-128.
+
+   Both endpoints MUST employ a MAC that produces pseudorandom tags for
+   key confirmation.  K_confirmP and K_confirmV are symmetric keys used
+   to compute tags confirmP and confirmV over the public key shares
+   received from the other peer earlier.
+
+   confirmP = MAC(K_confirmP, shareV)
+   confirmV = MAC(K_confirmV, shareP)
+
+   Once key confirmation is complete, applications MAY use K_shared as
+   an authenticated shared secret as needed.  For example, applications
+   MAY derive one or more keys and nonces from K_shared, for use with
+   Authenticated Encryption with Associated Data (AEAD) and subsequent
+   application data encryption.
+
+4.  Ciphersuites
+
+   This section documents SPAKE2+ ciphersuite configurations.  A
+   ciphersuite indicates a group, cryptographic hash algorithm, and pair
+   of KDF and MAC functions, e.g., P256-SHA256-HKDF-HMAC-SHA256.  This
+   ciphersuite indicates a SPAKE2+ protocol instance over P-256 that
+   uses SHA256 along with HKDF [RFC5869] and HMAC [RFC2104] for G, Hash,
+   KDF, and MAC functions, respectively.  Since the choice of PBKDF, its
+   parameters for computing w0 and w1, and the distribution of w0 and w1
+   do not affect interoperability, the PBKDF is not included as part of
+   the ciphersuite.
+
+   If no MAC algorithm is used in the key confirmation phase, its
+   respective column in Table 1 can be ignored and the ciphersuite name
+   will contain no MAC identifier.
+
+     +==============+==================+=============+==============+
+     | G            |       Hash       |     KDF     |     MAC      |
+     +==============+==================+=============+==============+
+     | P-256        | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256  |
+     |              |                  |  [RFC5869]  |  [RFC2104]   |
+     +--------------+------------------+-------------+--------------+
+     | P-256        | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512  |
+     |              |                  |  [RFC5869]  |  [RFC2104]   |
+     +--------------+------------------+-------------+--------------+
+     | P-384        | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256  |
+     |              |                  |  [RFC5869]  |  [RFC2104]   |
+     +--------------+------------------+-------------+--------------+
+     | P-384        | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512  |
+     |              |                  |  [RFC5869]  |  [RFC2104]   |
+     +--------------+------------------+-------------+--------------+
+     | P-521        | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512  |
+     |              |                  |  [RFC5869]  |  [RFC2104]   |
+     +--------------+------------------+-------------+--------------+
+     | edwards25519 | SHA256 [RFC6234] | HKDF-SHA256 | HMAC-SHA256  |
+     |              |                  |  [RFC5869]  |  [RFC2104]   |
+     +--------------+------------------+-------------+--------------+
+     | edwards448   | SHA512 [RFC6234] | HKDF-SHA512 | HMAC-SHA512  |
+     |              |                  |  [RFC5869]  |  [RFC2104]   |
+     +--------------+------------------+-------------+--------------+
+     | P-256        | SHA256 [RFC6234] | HKDF-SHA256 | CMAC-AES-128 |
+     |              |                  |  [RFC5869]  |  [RFC4493]   |
+     +--------------+------------------+-------------+--------------+
+     | P-256        | SHA512 [RFC6234] | HKDF-SHA512 | CMAC-AES-128 |
+     |              |                  |  [RFC5869]  |  [RFC4493]   |
+     +--------------+------------------+-------------+--------------+
+
+                                 Table 1
+
+   The following points represent permissible point generation seeds for
+   the groups listed in Table 1, using the algorithm presented in
+   Appendix B.  These byte strings are compressed points as in [SEC1]
+   for curves from [SEC1] and [RFC8032].  Note that these values are
+   identical to those used in the companion SPAKE2 specification
+   [RFC9382].
+
+   For P-256:
+
+   M =
+   02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f
+   seed: 1.2.840.10045.3.1.7 point generation seed (M)
+
+   N =
+   03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49
+   seed: 1.2.840.10045.3.1.7 point generation seed (N)
+
+   For P-384:
+
+   M =
+   030ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3dc
+   36f15314739074d2eb8613fceec2853
+   seed: 1.3.132.0.34 point generation seed (M)
+
+   N =
+   02c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518f9c543bb
+   252c5490214cf9aa3f0baab4b665c10
+   seed: 1.3.132.0.34 point generation seed (N)
+
+   For P-521:
+
+   M =
+   02003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d85608
+   cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7aa
+   seed: 1.3.132.0.35 point generation seed (M)
+
+   N =
+   0200c7924b9ec017f3094562894336a53c50167ba8c5963876880542bc669e494b25
+   32d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc349d95575cd25
+   seed: 1.3.132.0.35 point generation seed (N)
+
+   For edwards25519:
+
+   M =
+   d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf
+   seed: edwards25519 point generation seed (M)
+
+   N =
+   d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab
+   seed: edwards25519 point generation seed (N)
+
+   For edwards448:
+
+   M =
+   b6221038a775ecd007a4e4dde39fd76ae91d3cf0cc92be8f0c2fa6d6b66f9a12
+   942f5a92646109152292464f3e63d354701c7848d9fc3b8880
+   seed: edwards448 point generation seed (M)
+
+   N =
+   6034c65b66e4cd7a49b0edec3e3c9ccc4588afd8cf324e29f0a84a072531c4db
+   f97ff9af195ed714a689251f08f8e06e2d1f24a0ffc0146600
+   seed: edwards448 point generation seed (N)
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  Security Considerations
+
+   SPAKE2+ appears in [TDH] and is proven secure in [SPAKE2P-Analysis].
+
+   The ephemeral randomness used by the Prover and Verifier MUST be
+   generated using a cryptographically secure Pseudorandom Number
+   Generator (PRNG).
+
+   Elements received from a peer MUST be checked for group membership:
+   failure to properly deserialize and validate group elements can lead
+   to attacks.  An endpoint MUST abort the protocol if any received
+   public value is not a member of the large prime-order subgroup of G.
+   Multiplication of a public value V by the cofactor h will yield the
+   identity element I whenever V is an element of a small-order
+   subgroup.  Consequently, the Prover and Verifier MUST abort the
+   protocol upon receiving any value V such that V*h = I.  Failure to do
+   so may lead to subgroup confinement attacks.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              DOI 10.17487/RFC2104, February 1997,
+              <https://www.rfc-editor.org/info/rfc2104>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
+              AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
+              2006, <https://www.rfc-editor.org/info/rfc4493>.
+
+   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
+              "Elliptic Curve Cryptography Subject Public Key
+              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
+              <https://www.rfc-editor.org/info/rfc5480>.
+
+   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
+              Key Derivation Function (HKDF)", RFC 5869,
+              DOI 10.17487/RFC5869, May 2010,
+              <https://www.rfc-editor.org/info/rfc5869>.
+
+   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
+              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
+              DOI 10.17487/RFC6234, May 2011,
+              <https://www.rfc-editor.org/info/rfc6234>.
+
+   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
+              Signature Algorithm (EdDSA)", RFC 8032,
+              DOI 10.17487/RFC8032, January 2017,
+              <https://www.rfc-editor.org/info/rfc8032>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8265]  Saint-Andre, P. and A. Melnikov, "Preparation,
+              Enforcement, and Comparison of Internationalized Strings
+              Representing Usernames and Passwords", RFC 8265,
+              DOI 10.17487/RFC8265, October 2017,
+              <https://www.rfc-editor.org/info/rfc8265>.
+
+   [RFC9382]  Ladd, W., "SPAKE2, a Password-Authenticated Key Exchange",
+              RFC 9382, DOI 10.17487/RFC9382, September 2023,
+              <https://www.rfc-editor.org/info/rfc9382>.
+
+   [SEC1]     Standards for Efficient Cryptography Group, "SEC 1:
+              Elliptic Curve Cryptography", version 2.0, May 2009,
+              <https://secg.org/sec1-v2.pdf>.
+
+   [SPAKE2P-Analysis]
+              Shoup, V., "Security analysis of SPAKE2+", March 2020,
+              <https://eprint.iacr.org/2020/313.pdf>.
+
+   [TDH]      Cash, D., Kiltz, E., and V. Shoup, "The Twin-Diffie
+              Hellman Problem and Applications", EUROCRYPT 2008, Lecture
+              Notes in Computer Science, Volume 4965, pages 127-145,
+              Springer-Verlag, Berlin, Germany,
+              DOI 10.1007/978-3-540-78967-3_8, April 2008,
+              <https://doi.org/10.1007/978-3-540-78967-3_8>.
+
+7.2.  Informative References
+
+   [RFC7914]  Percival, C. and S. Josefsson, "The scrypt Password-Based
+              Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
+              August 2016, <https://www.rfc-editor.org/info/rfc7914>.
+
+   [RFC8844]  Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on
+              Uses of TLS with the Session Description Protocol (SDP)",
+              RFC 8844, DOI 10.17487/RFC8844, January 2021,
+              <https://www.rfc-editor.org/info/rfc8844>.
+
+   [RFC9106]  Biryukov, A., Dinu, D., Khovratovich, D., and S.
+              Josefsson, "Argon2 Memory-Hard Function for Password
+              Hashing and Proof-of-Work Applications", RFC 9106,
+              DOI 10.17487/RFC9106, September 2021,
+              <https://www.rfc-editor.org/info/rfc9106>.
+
+Appendix A.  Protocol Flow
+
+   This section describes the flow of the SPAKE2+ protocol, including
+   computations and mandatory checks performed by the Prover and
+   Verifier.  The constants M, N, P, p, and h are defined by the chosen
+   ciphersuite.
+
+A.1.  Prover
+
+   The Prover implements two functions, ProverInit and ProverFinish,
+   which are described below.
+
+   def ProverInit(w0):
+      // Compute Prover key share
+      x <- [0, p-1]
+      X = x*P + w0*M
+      return (x, X)
+
+   def ProverFinish(w0, w1, x, Y):
+      if not_in_subgroup(Y):
+         raise "invalid input"
+
+      // Compute shared values
+      Z = h*x*(Y - w0*N)
+      V = h*w1*(Y - w0*N)
+
+      return (Y, Z, V)
+
+A.2.  Verifier
+
+   The Verifier implements a single function, VerifierFinish, which is
+   described below.
+
+   def VerifierFinish(w0, L, X):
+      if not_in_subgroup(X):
+         raise "invalid input"
+
+      // Compute Verifier key share
+      y <- [0, p-1]
+      Y = y*P + w0*N
+
+      // Compute shared values
+      Z = h*y*(X - w0*M)
+      V = h*y*L
+
+      return (Z, V)
+
+A.3.  Transcript Computation
+
+   Both the Prover and the Verifier share the same function to compute
+   the protocol transcript, ComputeTranscript, which is described below.
+
+   def ComputeTranscript(Context, idProver, idVerifier,
+                         shareP, shareV, Z, V, w0):
+      TT = len(Context) || Context
+        || len(idProver) || idProver
+        || len(idVerifier) || idVerifier
+        || len(M) || M
+        || len(N) || N
+        || len(shareP) || shareP
+        || len(shareV) || shareV
+        || len(Z) || Z
+        || len(V) || V
+        || len(w0) || w0
+
+A.4.  Key Schedule Computation
+
+   Both the Prover and the Verifier share the same function to compute
+   the key schedule, ComputeKeySchedule, which is described below.
+
+   def ComputeKeySchedule(TT):
+      K_main = Hash(TT)
+      K_confirmP || K_confirmV = KDF(nil, K_main, "ConfirmationKeys")
+      K_shared = KDF(nil, K_main, "SharedKey")
+      return K_confirmP, K_confirmV, K_shared
+
+A.5.  Protocol Run
+
+   A full SPAKE2+ protocol run initiated by the Prover will look as
+   follows, where Transmit and Receive are shorthand for sending and
+   receiving a message to the peer:
+
+   Prover(Context, idProver, idVerifier, w0, w1):
+      (x, X) = ProverInit(w0)
+      Transmit(X)
+      Y = Receive()
+      (Z, V) = ProverFinish(w0, w1, x, Y)
+      TT = ComputeTranscript(Context, idProver, idVerifier, X, Y,
+                             Z, V, w0)
+      (K_confirmP, K_confirmV, K_shared) = ComputeKeySchedule(TT)
+      expected_confirmV = MAC(K_confirmV, X)
+      confirmV = Receive()
+      if not_equal_constant_time(expected_confirmV, confirmV):
+         raise "invalid confirmation message"
+
+      confirmP = MAC(K_confirmP, Y)
+      Transmit(confirmP)
+
+      return K_shared
+
+   Verifier(Context, idProver, idVerifier, w0, L):
+      X = Receive()
+      (Y, Z, V) = VerifierFinish(w0, L, X)
+      Transmit(Y)
+      TT = ComputeTranscript(Context, idProver, idVerifier, X, Y,
+                             Z, V, w0)
+      (K_confirmP, K_confirmV, K_shared) = ComputeKeySchedule(TT)
+      confirmV = MAC(K_confirmV, X)
+      Transmit(confirmV)
+
+      expected_confirmP = MAC(K_confirmP, Y)
+      confirmP = Receive()
+      if not_equal_constant_time(expected_confirmP, confirmP):
+         raise "invalid confirmation message"
+
+      return K_shared
+
+Appendix B.  Algorithm Used for Point Generation
+
+   This section describes the algorithm that was used to generate the
+   points M and N in Table 1 (Section 4).  This algorithm produces M and
+   N such that they are indistinguishable from two random points in the
+   prime-order subgroup of G, where the discrete log of these points is
+   unknown.  See [SPAKE2P-Analysis] for additional details on this
+   requirement.
+
+   For each curve in Table 1, we construct a string using the curve OID
+   from [RFC5480] (as an ASCII string) or its name, combined with the
+   needed constant -- for instance, "1.3.132.0.35 point generation seed
+   (M)" for P-521.  This string is turned into a series of blocks by
+   hashing with SHA256, and hashing that output again to generate the
+   next 32 bytes, and so on.  This pattern is repeated for each group
+   and value, with the string modified appropriately.
+
+   A byte string of length equal to that of an encoded group element is
+   constructed by concatenating as many blocks as are required, starting
+   from the first block, and truncating to the desired length.  The byte
+   string is then formatted as required for the group.  In the case of
+   Weierstrass curves, we take the desired length as the length for
+   representing a compressed point (Section 2.3.4 of [SEC1]) and use the
+   low-order bit of the first byte as the sign bit.  In order to obtain
+   the correct format, the value of the first byte is set to 0x02 or
+   0x03 (clearing the first six bits and setting the seventh bit),
+   leaving the sign bit as it was in the byte string constructed by
+   concatenating hash blocks.  For the curves described in [RFC8032], a
+   different procedure is used.  For edwards448, the 57-byte input has
+   the least-significant 7 bits of the last byte set to zero, and for
+   edwards25519, the 32-byte input is not modified.  For both of the
+   curves described in [RFC8032], the (modified) input is then
+   interpreted as the representation of the group element.  If this
+   interpretation yields a valid group element with the correct order
+   (p), the (modified) byte string is the output.  Otherwise, the
+   initial hash block is discarded and a new byte string constructed
+   from the remaining hash blocks.  The procedure for constructing a
+   byte string of the appropriate length, formatting it as required for
+   the curve, and checking to see if it is a valid point of the correct
+   order is repeated until a valid element is found.
+
+   The following Python snippet generates the above points, assuming an
+   elliptic curve implementation following the interface of
+   Edwards25519Point.stdbase() and Edwards448Point.stdbase() in
+   Appendix A of [RFC8032]:
+
+   def iterated_hash(seed, n):
+     h = seed
+     for i in range(n):
+       h = hashlib.sha256(h).digest()
+     return h
+
+   def bighash(seed, start, sz):
+     n = -(-sz // 32)
+     hashes = [iterated_hash(seed, i) for i in range(start, start + n)]
+     return b''.join(hashes)[:sz]
+
+   def canon_pointstr(ecname, s):
+     if ecname == 'edwards25519':
+       return s
+     elif ecname == 'edwards448':
+       return s[:-1] + bytes([s[-1] & 0x80])
+     else:
+       return bytes([(s[0] & 1) | 2]) + s[1:]
+
+   def gen_point(seed, ecname, ec):
+     for i in range(1, 1000):
+       hval = bighash(seed, i, len(ec.encode()))
+       pointstr = canon_pointstr(ecname, hval)
+       try:
+         p = ec.decode(pointstr)
+         if p != ec.zero_elem() and p * p.l() == ec.zero_elem():
+           return pointstr, i
+       except Exception:
+         pass
+
+Appendix C.  Test Vectors
+
+   This section contains various test vectors for SPAKE2+. (The choice
+   of PBKDF is omitted, and values for w0 and w1 are provided directly.)
+   All points are encoded using the uncompressed format, i.e., with a
+   0x04 octet prefix, specified in [SEC1].  idProver and idVerifier
+   identity strings are provided in the protocol invocation.
+
+   [Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors
+   ']
+   [idProver=b'client']
+   [idVerifier=b'server']
+   w0 = 0xbb8e1bbcf3c48f62c08db243652ae55d3e5586053fca77102994f23ad9549
+   1b3
+   w1 = 0x7e945f34d78785b8a3ef44d0df5a1a97d6b3b460409a345ca7830387a74b1
+   dba
+   L = 0x04eb7c9db3d9a9eb1f8adab81b5794c1f13ae3e225efbe91ea487425854c7f
+   c00f00bfedcbd09b2400142d40a14f2064ef31dfaa903b91d1faea7093d835966efd
+   x = 0xd1232c8e8693d02368976c174e2088851b8365d0d79a9eee709c6a05a2fad5
+   39
+   shareP = 0x04ef3bd051bf78a2234ec0df197f7828060fe9856503579bb17330090
+   42c15c0c1de127727f418b5966afadfdd95a6e4591d171056b333dab97a79c7193e3
+   41727
+   y = 0x717a72348a182085109c8d3917d6c43d59b224dc6a7fc4f0483232fa6516d8
+   b3
+   shareV = 0x04c0f65da0d11927bdf5d560c69e1d7d939a05b0e88291887d679fcad
+   ea75810fb5cc1ca7494db39e82ff2f50665255d76173e09986ab46742c798a9a6843
+   7b048
+   Z = 0x04bbfce7dd7f277819c8da21544afb7964705569bdf12fb92aa388059408d5
+   0091a0c5f1d3127f56813b5337f9e4e67e2ca633117a4fbd559946ab474356c41839
+   V = 0x0458bf27c6bca011c9ce1930e8984a797a3419797b936629a5a937cf2f11c8
+   b9514b82b993da8a46e664f23db7c01edc87faa530db01c2ee405230b18997f16b68
+   TT = 0x38000000000000005350414b45322b2d503235362d5348413235362d484b4
+   4462d5348413235362d484d41432d534841323536205465737420566563746f72730
+   600000000000000636c69656e7406000000000000007365727665724100000000000
+   00004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12
+   f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d20410
+   000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f9
+   8baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1e6
+   56edbe7410000000000000004ef3bd051bf78a2234ec0df197f7828060fe98565035
+   79bb1733009042c15c0c1de127727f418b5966afadfdd95a6e4591d171056b333dab
+   97a79c7193e341727410000000000000004c0f65da0d11927bdf5d560c69e1d7d939
+   a05b0e88291887d679fcadea75810fb5cc1ca7494db39e82ff2f50665255d76173e0
+   9986ab46742c798a9a68437b048410000000000000004bbfce7dd7f277819c8da215
+   44afb7964705569bdf12fb92aa388059408d50091a0c5f1d3127f56813b5337f9e4e
+   67e2ca633117a4fbd559946ab474356c4183941000000000000000458bf27c6bca01
+   1c9ce1930e8984a797a3419797b936629a5a937cf2f11c8b9514b82b993da8a46e66
+   4f23db7c01edc87faa530db01c2ee405230b18997f16b682000000000000000bb8e1
+   bbcf3c48f62c08db243652ae55d3e5586053fca77102994f23ad95491b3
+   K_main = 0x4c59e1ccf2cfb961aa31bd9434478a1089b56cd11542f53d3576fb6c2
+   a438a29
+   K_confirmP = 0x871ae3f7b78445e34438fb284504240239031c39d80ac23eb5ab9
+   be5ad6db58a
+   K_confirmV = 0xccd53c7c1fa37b64a462b40db8be101cedcf838950162902054e6
+   44b400f1680
+   HMAC(K_confirmP, shareV) = 0x926cc713504b9b4d76c9162ded04b5493e89109
+   f6d89462cd33adc46fda27527
+   HMAC(K_confirmV, shareP) = 0x9747bcc4f8fe9f63defee53ac9b07876d907d55
+   047e6ff2def2e7529089d3e68
+   K_shared = 0x0c5f8ccd1413423a54f6c1fb26ff01534a87f893779c6e68666d772
+   bfd91f3e7
+
+   [Context=b'SPAKE2+-P256-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors
+   ']
+   [idProver=b'client']
+   [idVerifier=b'server']
+   w0 = 0x1cc5207d6e34b8f7828206fb64b86aa9c712bc952abf251bb9f5856b24d8c
+   8cc
+   w1 = 0x4279649e62532b01dc27d2ed39100ba350518fb969672061a01edce752d0e
+   672
+   L = 0x043a348ad475d2200d46df876f1eb2e136056da31dafff52cc7762bf3be84d
+   e0097c4e69b0b9321326af1f0af4a14561a9c7b640cb5afd6822d14cb34830fc4511
+   x = 0xb586ab83f175c1a2b56b6a1b6a283523f88a9befcf11e22efb48e2ee1fe69a
+   23
+   shareP = 0x04a7928c4b47f6b8657a5b8ebcb6f1bd266192e152fb9745a4180c946
+   57a2f323b4d50d536c0325cdb0ec42c9bd8db8d7af3ff6dc85edb4b5365375c62e09
+   def4a
+   y = 0xac1fb828f041782d452ea9cc00c3fa34a55fa8f7f98c04be45a3d607b092d4
+   41
+   shareV = 0x04498c29e37dbd53ebf8db76679901d90c6be3af57f46ac3025b32420
+   839f0489c6c3b6bf5ddc8ecbc3d7c83d0891ad814a00ad23eba13197c9d96a5b1027
+   5e35d
+   Z = 0x04a81e31be54283cee81bf7bdc877764b6b2ac6a399f1176380aac8a82172c
+   18051aa17dfcf438896ad253f53b52cd45ec2c7399488a919bcfcfecc0261cbf5284
+   V = 0x04de0a53f96cbe4abcd31c1e0a23ea6f169c162dc5a007393c8fcddd2abd5d
+   518bb2d9734b1d2dfce3fd916e991ab9dc3a2760d439c083eb39b65408857d2bb4aa
+   TT = 0x38000000000000005350414b45322b2d503235362d5348413531322d484b4
+   4462d5348413531322d484d41432d534841353132205465737420566563746f72730
+   600000000000000636c69656e7406000000000000007365727665724100000000000
+   00004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12
+   f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d20410
+   000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f9
+   8baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1e6
+   56edbe7410000000000000004a7928c4b47f6b8657a5b8ebcb6f1bd266192e152fb9
+   745a4180c94657a2f323b4d50d536c0325cdb0ec42c9bd8db8d7af3ff6dc85edb4b5
+   365375c62e09def4a410000000000000004498c29e37dbd53ebf8db76679901d90c6
+   be3af57f46ac3025b32420839f0489c6c3b6bf5ddc8ecbc3d7c83d0891ad814a00ad
+   23eba13197c9d96a5b10275e35d410000000000000004a81e31be54283cee81bf7bd
+   c877764b6b2ac6a399f1176380aac8a82172c18051aa17dfcf438896ad253f53b52c
+   d45ec2c7399488a919bcfcfecc0261cbf5284410000000000000004de0a53f96cbe4
+   abcd31c1e0a23ea6f169c162dc5a007393c8fcddd2abd5d518bb2d9734b1d2dfce3f
+   d916e991ab9dc3a2760d439c083eb39b65408857d2bb4aa20000000000000001cc52
+   07d6e34b8f7828206fb64b86aa9c712bc952abf251bb9f5856b24d8c8cc
+   K_main = 0x527613439c279a375c116342a4216a8d92441d2fe1921dd1e60f140b2
+   855916ccac7db4dbf22bd56e344a8cd506d08949bde1e9d83c24d68ff4246458dc14
+   288
+   K_confirmP = 0x0aa129d7b82067c2a9607677c9c4fdedc1cd7cfed9ff72c54c0ae
+   bb2b1a8aa915b96834b2986725c6040852ceaafbb17d638a715198f795654eac89bf
+   0739878
+   K_confirmV = 0xa1f1038de30a8c12d43d06c27d362daa9699249e941faa2d5cbc5
+   9a9683bf42aed9537818245677fdb54b5274506542994f4a83455f6d7b3af5ec017f
+   aa58f61
+   HMAC(K_confirmP, shareV) = 0x6b2469b56cf8ac3f94a8d0b533380ea6b3d0f46
+   b3e12ee82550d49e129c2412728c9437a64ee5f80c8cdc5e8a30faa0a6deb8a52513
+   46ba81bb6fc955b2304fc
+   HMAC(K_confirmV, shareP) = 0x154174fc278a935e290b3352ba877e179fa9281
+   c0a76928faea703c72d383b267511a5cf084cb07147efece94e3cfd91944e7baab85
+   6858fbebc087167b0f409
+   K_shared = 0x11887659d9e002f34fa6cc270d33570f001b2a3fc0522b643c07327
+   d09a4a9f47aab85813d13c585b53adf5ac9de5707114848f3dc31a4045f69a2cc197
+   2b098
+
+   [Context=b'SPAKE2+-P384-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors
+   ']
+   [idProver=b'client']
+   [idVerifier=b'server']
+   w0 = 0x097a61cbb1cee72bb654be96d80f46e0e3531151003903b572fc193f23377
+   2c23c22228884a0d5447d0ab49a656ce1d2
+   w1 = 0x18772816140e6c3c3938a693c600b2191118a34c7956e1f1cd5b0d519b56e
+   a5858060966cfaf27679c9182129949e74f
+   L = 0x04f27dd5384d6b9beb4c5022c94b1978d632779e1d3abe458611e734a529d0
+   04e25053398e5dc9eeaa4ffa59743ca7ddbc0e7ce69155295cb2b846da83ee6a4449
+   0dd8e96bb0b0f6645281bfd978dd5f6836561ea0d8b2c045ff04cef2e5873d2c
+   x = 0x2f1bdbeda162ff2beba0293d3cd3ae95f663c53663378c7e18ee8f56a4a48b
+   00d31ce0ef43606548da485058f12e8e73
+   shareP = 0x049fb0404ca7ce71fb85d3aaa8fd05fa054affac996135bc245149be0
+   9571e43e2bf76e00d6d52ac452b8224f6b9da31420a4f5e214b377546daad4d61da5
+   ca0cfdea59a5a92ebdb6b42da5d14663b8d1f9eb97050139ab89788e0ada27b048fc
+   f
+   y = 0xbbcaf02404a16ed4fa73b183f703a8d969386f3d34f5e98b3a904e760512f1
+   1757f07dfcf87a2ada8fc6d028445bd53e
+   shareV = 0x0493b1c1f6a30eac4ac4a15711e44640bae3576787627ee2541104298
+   1e94b2e9604b9374f66bb247bc431759212ef3fa0a20c087863b89efb32219e1337c
+   e94be2175f8cb9fd50cf0b84772717fd063c52b69de1229a01ab840b55993287f32e
+   d
+   Z = 0x048cd880e5147e49b42b5754c1bc6d2091ad414789bc3b030f2d787ea480f3
+   e35d0fa0d02d0dd06fee7f242b702a2d984efd79c76d99ab35b99e359a205cea56bb
+   a8dd8f995c101a69a5157686d1cf6a7288d7cff2f2a9748db99b24f646ea7b37
+   V = 0x041c3c9cc38b03a06a49cf17cc5e7754cf1ccbbc6fffc0ddf1a6e23f57294a
+   25d96f7da5ce4ac0a617c78502f2f235a5fcf2f76a62385434ed2b6e95521b41eff3
+   c4ce93ecf8fb32005dd76335d0a7c78153257288d7fde1a22d404f5d73d068e2
+   TT = 0x38000000000000005350414b45322b2d503338342d5348413235362d484b4
+   4462d5348413235362d484d41432d534841323536205465737420566563746f72730
+   600000000000000636c69656e7406000000000000007365727665726100000000000
+   000040ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3
+   dc36f15314739074d2eb8613fceec285397592c55797cdd77c0715cb7df2150220a0
+   119866486af4234f390aad1f6addde5930909adc67a1fc0c99ba3d52dc5dd6100000
+   00000000004c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518
+   f9c543bb252c5490214cf9aa3f0baab4b665c10c38b7d7f4e7f320317cd717315a79
+   7c7e02933aef68b364cbf84ebc619bedbe21ff5c69ea0f1fed5d7e3200418073f406
+   100000000000000049fb0404ca7ce71fb85d3aaa8fd05fa054affac996135bc24514
+   9be09571e43e2bf76e00d6d52ac452b8224f6b9da31420a4f5e214b377546daad4d6
+   1da5ca0cfdea59a5a92ebdb6b42da5d14663b8d1f9eb97050139ab89788e0ada27b0
+   48fcf61000000000000000493b1c1f6a30eac4ac4a15711e44640bae3576787627ee
+   25411042981e94b2e9604b9374f66bb247bc431759212ef3fa0a20c087863b89efb3
+   2219e1337ce94be2175f8cb9fd50cf0b84772717fd063c52b69de1229a01ab840b55
+   993287f32ed6100000000000000048cd880e5147e49b42b5754c1bc6d2091ad41478
+   9bc3b030f2d787ea480f3e35d0fa0d02d0dd06fee7f242b702a2d984efd79c76d99a
+   b35b99e359a205cea56bba8dd8f995c101a69a5157686d1cf6a7288d7cff2f2a9748
+   db99b24f646ea7b376100000000000000041c3c9cc38b03a06a49cf17cc5e7754cf1
+   ccbbc6fffc0ddf1a6e23f57294a25d96f7da5ce4ac0a617c78502f2f235a5fcf2f76
+   a62385434ed2b6e95521b41eff3c4ce93ecf8fb32005dd76335d0a7c78153257288d
+   7fde1a22d404f5d73d068e23000000000000000097a61cbb1cee72bb654be96d80f4
+   6e0e3531151003903b572fc193f233772c23c22228884a0d5447d0ab49a656ce1d2
+   K_main = 0x61370f8bf65e0df7e9a7b2c2289be1ee4b5dd6c21f4b85165730700c4
+   4ce30af
+   K_confirmP = 0x2c8940419d94e53d5d240801e702c4658531aa7a9f14ec75f0d67
+   f12fa84196c
+   K_confirmV = 0x8e74afe16c53a44590ad6bf43aa89324978b8f20014336675f618
+   387f99f3fdc
+   HMAC(K_confirmP, shareV) = 0x7ae825e242a5a1f86ad7db172c2c12fcb458b6a
+   2b1ddfc96b2b7cfd2eed5f7ab
+   HMAC(K_confirmV, shareP) = 0x1581062167d6a3d14493447cd170d408f6fdc58
+   e31225438db86214167426a7a
+   K_shared = 0x99758e838ae1a856589689fb55b6befe4e2382e6ebbeca1a6232a68
+   f9dc04c1a
+
+   [Context=b'SPAKE2+-P384-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors
+   ']
+   [idProver=b'client']
+   [idVerifier=b'server']
+   w0 = 0xb8d44a0982b88abe19b724d4bdafba8c90dc93130e0bf4f8062810992326d
+   a126fd01db53e40250ca33a3ff302044cb0
+   w1 = 0x2373e2071c3bb2a6d53ece57830d56f8080189816803c22375d6a4a514f9d
+   161b64d0f05b97735b98b348f9b33cc2e30
+   L = 0x049ca7217ff6456bb2e2bcf71b31d9b1e5ed6e0c9700936ae617e990cee87e
+   e1ce3a03629dd5532948c39b89f38b39f13c7f513c5b1ada00f6533a4a8b02b9cd04
+   e1b2a5db1f24ec5fe959198a19666037e04b768cc02e75ac9da0048736db6e5b
+   x = 0x5a835d52714f30d2ef539268b89df9558628400063dfa0e41eb979066f4caf
+   409bbf7aab3ddddea13f1b070a1827d3d4
+   shareP = 0x042f382eef464a2c9aecfdf4b81d25c4de2de113ba67405ce336c762c
+   69217ae7e27bda875144140d7536c4cc08b9b4dace5f872a6a2ed57f34042688ad3c
+   5d446c187dc0caf9cea812df3a4dd6fdbc64b9d7d7d7ff4bf6965abb06eeb108d55e
+   e
+   y = 0xc883ee5b08cf7ba122038c279459ab1a730f85f2d624a02732d519faab56a4
+   98e773a8dec6c447ed02d5c00303a18bc4
+   shareV = 0x04d72e11eee332305062454c0a058b8103a3304785d445510cd8d101e
+   9cb44cfb159cb7b72123abaf719ab1c42e0558c84c14b0886e8b446e4c880bff2f4b
+   291fafafc748cb4115824e66732bdeba7fae176388e228ab9d7546255994ca3fb5a5
+   2
+   Z = 0x043cb63f5fcb573cf3e2ee40bca5fbc1f00ff2554caab3790329184c45ed69
+   c39b2e1323bc13c8f821b844feb5921b1470e7b3f70bd10508e5de6db157305badf8
+   20fa28d68742d8287fb201383a8deec70d5bcf2a61498a481290ed8cc94ab3a0
+   V = 0x0468604d188f4da560ddaaece126abe40f5de255f8af093c7c3aff71f95d90
+   92804426127d73d46a817085e9095de6bcf30733a5124a98f567148efe92a7134994
+   0c7244623247d33a8b78cbc9a53cd45bb22430f318a635084d1840c905f236c8
+   TT = 0x38000000000000005350414b45322b2d503338342d5348413531322d484b4
+   4462d5348413531322d484d41432d534841353132205465737420566563746f72730
+   600000000000000636c69656e7406000000000000007365727665726100000000000
+   000040ff0895ae5ebf6187080a82d82b42e2765e3b2f8749c7e05eba366434b363d3
+   dc36f15314739074d2eb8613fceec285397592c55797cdd77c0715cb7df2150220a0
+   119866486af4234f390aad1f6addde5930909adc67a1fc0c99ba3d52dc5dd6100000
+   00000000004c72cf2e390853a1c1c4ad816a62fd15824f56078918f43f922ca21518
+   f9c543bb252c5490214cf9aa3f0baab4b665c10c38b7d7f4e7f320317cd717315a79
+   7c7e02933aef68b364cbf84ebc619bedbe21ff5c69ea0f1fed5d7e3200418073f406
+   100000000000000042f382eef464a2c9aecfdf4b81d25c4de2de113ba67405ce336c
+   762c69217ae7e27bda875144140d7536c4cc08b9b4dace5f872a6a2ed57f34042688
+   ad3c5d446c187dc0caf9cea812df3a4dd6fdbc64b9d7d7d7ff4bf6965abb06eeb108
+   d55ee610000000000000004d72e11eee332305062454c0a058b8103a3304785d4455
+   10cd8d101e9cb44cfb159cb7b72123abaf719ab1c42e0558c84c14b0886e8b446e4c
+   880bff2f4b291fafafc748cb4115824e66732bdeba7fae176388e228ab9d75462559
+   94ca3fb5a526100000000000000043cb63f5fcb573cf3e2ee40bca5fbc1f00ff2554
+   caab3790329184c45ed69c39b2e1323bc13c8f821b844feb5921b1470e7b3f70bd10
+   508e5de6db157305badf820fa28d68742d8287fb201383a8deec70d5bcf2a61498a4
+   81290ed8cc94ab3a061000000000000000468604d188f4da560ddaaece126abe40f5
+   de255f8af093c7c3aff71f95d9092804426127d73d46a817085e9095de6bcf30733a
+   5124a98f567148efe92a71349940c7244623247d33a8b78cbc9a53cd45bb22430f31
+   8a635084d1840c905f236c83000000000000000b8d44a0982b88abe19b724d4bdafb
+   a8c90dc93130e0bf4f8062810992326da126fd01db53e40250ca33a3ff302044cb0
+   K_main = 0x571af2e9a0bf4b354cca18d713f8a84315a46c999ceb92ca6a88b8a6d
+   615795140862dbccd6fdc0abecc5956c43f8ab40343a22fc1b91752cb7c2737dab90
+   41e
+   K_confirmP = 0x6c8c7fc6becf3bc07f081b4f7f867bec76fd8eeddbd7968356723
+   bae701e04f35f800e647dfa013b2876958efe0ce68e7595ba46f1de0b17adfc02dfe
+   3f18a18
+   K_confirmV = 0x2d0c9702a0f5536bacddd596eb6ea365d17f176db30081b97b83e
+   05bb87e9a36c0565b7616251c93bc76c76fc5c3531a28db40779d986d4e7b71a24c4
+   3fbc731
+   HMAC(K_confirmP, shareV) = 0x7f806ae56ea3e49a8b16ffee528086489418913
+   641f529d50ff92aa456ad4648e522f9540b403bff6bd94ee1adc95c7d1b2666f7ba6
+   f9c10748bc7bfb4181d27
+   HMAC(K_confirmV, shareP) = 0x8daa262decb79cceda4421f4f8dacf22ec027c0
+   8e036f071beea563c8e00813a29807963ff9d7d6bbff48dd5bdcdd9ca9fd7ffc272b
+   162258d981913f7253dcb
+   K_shared = 0x31e0075a823b9269af5769d71ef3b2f5001cbfe044584fe8551124a
+   217dad078415630bf3eda16b5a38341d418a6d72b3960f818a0926f0de88784b59d6
+   a694b
+
+   [Context=b'SPAKE2+-P521-SHA512-HKDF-SHA512-HMAC-SHA512 Test Vectors
+   ']
+   [idProver=b'client']
+   [idVerifier=b'server']
+   w0 = 0x009c79bcd7656716314fca5a6e2c5cda7ef86131399438e012a043051e863
+   f60b5aeb3c101731e1505e721580f48535a9b0456b231b9266ae6fff49ee90d25f72
+   f5f
+   w1 = 0x01632c15f51fcd916cd79e19075f8a69b72b0099922ad62ff8d540b469569
+   f0aa027047aed2b3f242ea0ac4288b4e4db6a4e5946d8ad32b42192c5aa66d9ef8e1
+   b33
+   L = 0x040135072d0fa36f9e80031294cef5c3c35b882a0efa2c66570d64a49f8bec
+   6c66435bf65bb7c7b2a3e7dece491e02b4d567e7087dbc32fe0fae8af417dcb50be6
+   d704012a194588b690e6d3db492656f72ddea01fc1c7fcec0f5d34a5af0102939f6f
+   deae39c20cff74fcdb7f09855f0fc9520d20b0520b0b096b8d42c7c3d68b4a66f751
+   x = 0x00b69e3bb15df82c9fa0057461334e2c66ab92fc9b8d3662eec81216ef5ddc
+   4a43f19e90dedaa2d72502f69673a115984ffcf88e03a9364b07102114c5602cd93c
+   69
+   shareP = 0x0400a14431edf6852ff5fe868f8683e16e9e0a45d9e27f9a96442285a
+   c6b161fc0bf267362a5ffb06f9cbd14b7a37e492146d77cae4c77812df00a91dbae0
+   9e27e1fac00ae019317ef9768548325bca35ce258e6206fe03c6338b2eb889d09d9f
+   11400a36cf6328a7e1f81c6c7a2af7ff1d9b5210768318f27e57b75b39b9fbfc7b37
+   a60ab
+   y = 0x0056d01c5246fbde964c0493934b7ece89eafd943eb27d357880a2a2202249
+   9e249528c5707b1afe8794c8a1d60ceedaeed96dd0dd904ea075f096c9fec5da7de4
+   96
+   shareV = 0x0401aa5af0f3027f63b7170572db5ff06dd1f3d6ea8ea771b26b434fb
+   bc6c9de7d80975131c9c2e94d30c0ed2d62449c4c1b7e95037a85ed7598e415a2591
+   26365e89500d0f2156b551b70416d719944736990f346f6f9ba4fbaf2f63e0987369
+   0bcf730582e0a7b03ffede50f5787b631d5021a94287f0a29a081b62b9f5a3bf393b
+   001b3
+   Z = 0x0401e3015bf2811891a518d342c63541294dc80e0ee210e8220a5b9cab010d
+   77945724ef1185d739a62847fdada9da9b1bca6b9fa173fa551185c6084c3db26d3a
+   f0ac01f9356d01beebebd5ff026ca19f9df5d614355f3498816ac20b63bc936eed82
+   8a7039d1e17dba740471d9afc0e0b4427d65b2d27a57a87e42300004e2b4620c23c9
+   V = 0x0401058b21ca71e4439281579d6df3b86ae874d70742fe8eae2de60e77e07e
+   6e1c31b9c277de36b38531f5b769e9e4030ba09258f510c83c5c21957610355ce920
+   1fe600672db35efd1d0903bc285d4e27e9fb4472c30f17118dfa028f182bc9361c6a
+   749f560e31b9c404624d24e68010f064101d4a1154e77be8f2105dbeb8b0349adb0e
+   TT = 0x38000000000000005350414b45322b2d503532312d5348413531322d484b4
+   4462d5348413531322d484d41432d534841353132205465737420566563746f72730
+   600000000000000636c69656e7406000000000000007365727665728500000000000
+   00004003f06f38131b2ba2600791e82488e8d20ab889af753a41806c5db18d37d856
+   08cfae06b82e4a72cd744c719193562a653ea1f119eef9356907edc9b56979962d7a
+   a01bdd179a3d547610892e9b96dea1eab10bdd7ac5ae0cf75aa0f853bfd185cf782f
+   894301998b11d1898ede2701dca37a2bb50b4f519c3d89a7d054b51fb84912192850
+   00000000000000400c7924b9ec017f3094562894336a53c50167ba8c596387688054
+   2bc669e494b2532d76c5b53dfb349fdf69154b9e0048c58a42e8ed04cef052a3bc34
+   9d95575cd2501c62bee650c9287a651bb75c7f39a2006873347b769840d261d17760
+   b107e29f091d556a82a2e4cde0c40b84b95b878db2489ef760206424b3fe7968aa8e
+   0b1f33485000000000000000400a14431edf6852ff5fe868f8683e16e9e0a45d9e27
+   f9a96442285ac6b161fc0bf267362a5ffb06f9cbd14b7a37e492146d77cae4c77812
+   df00a91dbae09e27e1fac00ae019317ef9768548325bca35ce258e6206fe03c6338b
+   2eb889d09d9f11400a36cf6328a7e1f81c6c7a2af7ff1d9b5210768318f27e57b75b
+   39b9fbfc7b37a60ab85000000000000000401aa5af0f3027f63b7170572db5ff06dd
+   1f3d6ea8ea771b26b434fbbc6c9de7d80975131c9c2e94d30c0ed2d62449c4c1b7e9
+   5037a85ed7598e415a259126365e89500d0f2156b551b70416d719944736990f346f
+   6f9ba4fbaf2f63e09873690bcf730582e0a7b03ffede50f5787b631d5021a94287f0
+   a29a081b62b9f5a3bf393b001b385000000000000000401e3015bf2811891a518d34
+   2c63541294dc80e0ee210e8220a5b9cab010d77945724ef1185d739a62847fdada9d
+   a9b1bca6b9fa173fa551185c6084c3db26d3af0ac01f9356d01beebebd5ff026ca19
+   f9df5d614355f3498816ac20b63bc936eed828a7039d1e17dba740471d9afc0e0b44
+   27d65b2d27a57a87e42300004e2b4620c23c985000000000000000401058b21ca71e
+   4439281579d6df3b86ae874d70742fe8eae2de60e77e07e6e1c31b9c277de36b3853
+   1f5b769e9e4030ba09258f510c83c5c21957610355ce9201fe600672db35efd1d090
+   3bc285d4e27e9fb4472c30f17118dfa028f182bc9361c6a749f560e31b9c404624d2
+   4e68010f064101d4a1154e77be8f2105dbeb8b0349adb0e4200000000000000009c7
+   9bcd7656716314fca5a6e2c5cda7ef86131399438e012a043051e863f60b5aeb3c10
+   1731e1505e721580f48535a9b0456b231b9266ae6fff49ee90d25f72f5f
+   K_main = 0xf672a73216568d20cc3433247bc43a3b875a421cbdba76cf1db8bfe57
+   2b658bf3f7a4ef8cc9ff1f6a2827ff7b19860454b775a4097009040f3b36b7420407
+   16e
+   K_confirmP = 0xa211c60ea8d4b3b294bd6ca9515663b77f3caac28af3658b34fe1
+   512f25077f2f64b8de426caa662b4cbbdc9c2f8f12347993c8d57fdf68c177732d7d
+   da7277b
+   K_confirmV = 0x0e9bf6b9a37339144cb32a78a872f50b10839f81eda6c09a827dd
+   bb158c47162bec274af920cdf809f162b98fa701efebada26cdfbeac408b5a35b052
+   d18f0c6
+   HMAC(K_confirmP, shareV) = 0xf0f5c903dfa42fe367659656a26058cd984b76a
+   8e91ae4d0fa4c13db149008e2ae57713fb230a627761174fefd263b9c10e9a4b6a37
+   46cde59c5943040c17133
+   HMAC(K_confirmV, shareP) = 0xa8f7ab43f3a800171d3a3fb26d742e1ed236c2d
+   5804ecd328f220a7d245cd2e3bfb6c0526983bff9229c94f70fe64ba9bb5a4d0dc10
+   afcda64a4c96d4c3d81ad
+   K_shared = 0xd1c170e4e55efacb9db8abad286293ebd1dcf24f13973427b9632bb
+   c323e42e447afca2aa7f74f2af3fb5f51684ec543db854b7002cde6799c330b032ba
+   8820a
+
+   [Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-CMAC-AES-128 Test Vector
+   s']
+   [idProver=b'client']
+   [idVerifier=b'server']
+   w0 = 0x9aad90c603cf16cec4ee40d81acd7a865130b28cc6d0664ae2e0f406aa47e
+   d61
+   w1 = 0x872be859cec1e78d191882bd9c2f032af018a25016813788fe8954bfffc58
+   c8e
+   L = 0x04d79a53698c5dd79e14b426e73b4a7f1b42469815fe24e8f53ce01579e902
+   eb198d59f05bc451c41826b88e3db5476a69e197fdf474c75b387f6d40361c3fda35
+   x = 0x9d39a3511a007a7d3fe6af5555cf60301bcda503f2bf6634b2caf9e4fd0743
+   a1
+   shareP = 0x04788218027ba4b17f7279ef0aef47a8733cf88b5bf65d6127ecadc78
+   b8a0f65b9001f7e54719fb63c072ddd1e1a4adfb376dde37ba1aa2082362b6c2ca14
+   a8e53
+   y = 0x9c3219841626325c68d89c22fb6c55611e3136442daa8b9b784db7242afff3
+   ed
+   shareV = 0x04c05953ea9d1cd6248b8c61becd7d55e46237526d8b1e23495ea7566
+   b7f6bc24b3da1cfb2e88a975fcfb5dc4e72b5cbea509b1cfdd1ef8f8195fa8bf2bd5
+   ca1e5
+   Z = 0x049444a17ad5909548a084fa182275a89a496ec6669bd08892aa9c64a512d4
+   0212147e6005bf1d510e3bbcfee8efc38243acaf4c5f2decffa009341b1e330b0442
+   V = 0x0457a8919af393e2da1de209a01fdda275eab0a682d8931b0e6ee1b9339794
+   63a25ccbcda1956a6a555706f0b062aa880617bd219d09391ad8576d3a73e9233f57
+   TT = 0x39000000000000005350414b45322b2d503235362d5348413235362d484b4
+   4462d5348413235362d434d41432d4145532d313238205465737420566563746f727
+   30600000000000000636c69656e74060000000000000073657276657241000000000
+   0000004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa
+   12f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d204
+   10000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4
+   f98baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1
+   e656edbe7410000000000000004788218027ba4b17f7279ef0aef47a8733cf88b5bf
+   65d6127ecadc78b8a0f65b9001f7e54719fb63c072ddd1e1a4adfb376dde37ba1aa2
+   082362b6c2ca14a8e53410000000000000004c05953ea9d1cd6248b8c61becd7d55e
+   46237526d8b1e23495ea7566b7f6bc24b3da1cfb2e88a975fcfb5dc4e72b5cbea509
+   b1cfdd1ef8f8195fa8bf2bd5ca1e54100000000000000049444a17ad5909548a084f
+   a182275a89a496ec6669bd08892aa9c64a512d40212147e6005bf1d510e3bbcfee8e
+   fc38243acaf4c5f2decffa009341b1e330b044241000000000000000457a8919af39
+   3e2da1de209a01fdda275eab0a682d8931b0e6ee1b933979463a25ccbcda1956a6a5
+   55706f0b062aa880617bd219d09391ad8576d3a73e9233f5720000000000000009aa
+   d90c603cf16cec4ee40d81acd7a865130b28cc6d0664ae2e0f406aa47ed61
+   K_main = 0x6002da6b2740056f2836ac0316ae9e02e2b24c5c109883136e90ed868
+   b2fcf62
+   K_confirmP = 0x857d0db7f5e06385853bf4b8abd43b5a
+   K_confirmV = 0x268c75933332157118063550c6bfe846
+   CMAC(K_confirmP, shareV) = 0xd340bc94a03feafd14491e316514ca5f
+   CMAC(K_confirmV, shareP) = 0x2b42d0fe76bcf9ccc208d06d60082f96
+   K_shared = 0xe832094adfc028bf288e49ab902fc208b7eeff084f259da7613c047
+   9869d4fc9
+
+   [Context=b'SPAKE2+-P256-SHA512-HKDF-SHA512-CMAC-AES-128 Test Vector
+   s']
+   [idProver=b'client']
+   [idVerifier=b'server']
+   w0 = 0x56e0299ac95739b616a973276c1338e3651285345dde2f7faf74c25c0b50e
+   b90
+   w1 = 0x462fe5b522a17d3d35b27323113bdd252de9cbfdd6f264b35721bf59a9a74
+   f0b
+   L = 0x040540332ffec8a2faa8d17ae6da5973c11e078b8c10c89fd6af996726b802
+   3513eff2914c3ced64fbedd4e261438fb0ea6ef9fc1faef4ba1ead780636faac1bc1
+   x = 0x254dd22780eeb6af2464dd6a2bd026b46a34966d6933607f1be956314f74b0
+   ea
+   shareP = 0x049661cfdb0f7bd24b637f8d1d0f464c17f0b9c15129ea31156dcc581
+   da6c840240b275d72f28ea73a5c088c99d73896af24a5ae26e036eb2dedaf26e511a
+   24a48
+   y = 0x695beec24305fbd5660bc200228598e7c891fdf60a55df4bdd3a57debc3847
+   4a
+   shareV = 0x0461f580eb3eb4b2f412d5c07491f360ad6e4492d8f23e346f0ba999f
+   bbcb9715a3c2485c3b250a6672e6698da3c9a9725645f607ee90a9b1b34fd44b9df6
+   e551a
+   Z = 0x0406f77a4bca254219dc3eeca9989f377037407105540bfddc5bdeff3d27a8
+   7d68442e69d543a000077bd4c42e33930f890d29fb4be5e8dcc627f6811ace96c274
+   V = 0x0442952a531a2937e03808e74f6d65afbedb4cfb7fcf91991498f77db21b14
+   6f5c2249e727e374de03f32848465aba5c5ebfe6501d3537d09160c7f42e4b3f133d
+   TT = 0x39000000000000005350414b45322b2d503235362d5348413531322d484b4
+   4462d5348413531322d434d41432d4145532d313238205465737420566563746f727
+   30600000000000000636c69656e74060000000000000073657276657241000000000
+   0000004886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa
+   12f5ff355163e43ce224e0b0e65ff02ac8e5c7be09419c785e0ca547d55a12e2d204
+   10000000000000004d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4
+   f98baa1292b4907d60aa6bfade45008a636337f5168c64d9bd36034808cd564490b1
+   e656edbe74100000000000000049661cfdb0f7bd24b637f8d1d0f464c17f0b9c1512
+   9ea31156dcc581da6c840240b275d72f28ea73a5c088c99d73896af24a5ae26e036e
+   b2dedaf26e511a24a4841000000000000000461f580eb3eb4b2f412d5c07491f360a
+   d6e4492d8f23e346f0ba999fbbcb9715a3c2485c3b250a6672e6698da3c9a9725645
+   f607ee90a9b1b34fd44b9df6e551a41000000000000000406f77a4bca254219dc3ee
+   ca9989f377037407105540bfddc5bdeff3d27a87d68442e69d543a000077bd4c42e3
+   3930f890d29fb4be5e8dcc627f6811ace96c27441000000000000000442952a531a2
+   937e03808e74f6d65afbedb4cfb7fcf91991498f77db21b146f5c2249e727e374de0
+   3f32848465aba5c5ebfe6501d3537d09160c7f42e4b3f133d200000000000000056e
+   0299ac95739b616a973276c1338e3651285345dde2f7faf74c25c0b50eb90
+   K_main = 0x111790ae23de3fc5bb43bdc1f63106461dbd8d86360adf056bf117164
+   8bfb231503853db2625275b7136b5a823dd5a94482514fce7f791c4daca2b21c7bde
+   756
+   K_confirmP = 0xb234d2e152a03168b76c6474d5322070
+   K_confirmV = 0x683d62024626fe0c5126ef4df58b88ee
+   CMAC(K_confirmP, shareV) = 0x0dc514d262e37470eb43e058e0d615f4
+   CMAC(K_confirmV, shareP) = 0xde076589efcd5d96c2ea6061d96772d9
+   K_shared = 0x488a34663d6be5e02590bb8e9ad9ad3e0f580dec41e8b99ed4ae4b7
+   34da49287638cac4c9f17fe3c3ae18dda0d6d7f14c17e4640d5a2aaab959efa0cbea
+   4e546
+
+Acknowledgements
+
+   Thanks to Ben Kaduk and Watson Ladd, from whom this specification
+   originally emanated.
+
+Authors' Addresses
+
+   Tim Taubert
+   Apple Inc.
+   One Apple Park Way
+   Cupertino, California 95014
+   United States of America
+   Email: ttaubert@apple.com
+
+
+   Christopher A. Wood
+   Email: caw@heapingbits.net