< draft-bar-cfrg-spake2plus-07.txt   draft-bar-cfrg-spake2plus-08.txt >
Network Working Group T. Taubert Network Working Group T. Taubert
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Informational C.A. Wood Intended status: Informational C. A. Wood
Expires: 15 August 2022 11 February 2022 Expires: 6 November 2022 5 May 2022
SPAKE2+, an Augmented PAKE SPAKE2+, an Augmented PAKE
draft-bar-cfrg-spake2plus-07 draft-bar-cfrg-spake2plus-08
Abstract Abstract
This document describes SPAKE2+, a Password Authenticated Key This document describes SPAKE2+, a Password Authenticated Key
Exchange (PAKE) protocol run between two parties for deriving a Exchange (PAKE) protocol run between two parties for deriving a
strong shared key with no risk of disclosing the password. SPAKE2+ strong shared key with no risk of disclosing the password. SPAKE2+
is an augmented PAKE protocol, as only one party has knowledge of the is an augmented PAKE protocol, as only one party has knowledge of the
password. This method is simple to implement, compatible with any password. This method is simple to implement, compatible with any
prime order group and is computationally efficient. prime order group and is computationally efficient.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 15 August 2022. This Internet-Draft will expire on 6 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definition of SPAKE2+ . . . . . . . . . . . . . . . . . . . . 4 3. Definition of SPAKE2+ . . . . . . . . . . . . . . . . . . . . 4
3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5
3.2. Offline Registration . . . . . . . . . . . . . . . . . . 5 3.2. Offline Registration . . . . . . . . . . . . . . . . . . 6
3.3. Online Authentication . . . . . . . . . . . . . . . . . . 7 3.3. Online Authentication . . . . . . . . . . . . . . . . . . 7
3.4. Key Schedule and Key Confirmation . . . . . . . . . . . . 8 3.4. Key Schedule and Key Confirmation . . . . . . . . . . . . 9
4. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Algorithm used for Point Generation . . . . . . . . 14 Appendix A. Protocol Flow . . . . . . . . . . . . . . . . . . . 15
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 16 A.1. Prover . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 A.2. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 16
A.3. Transcript Computation . . . . . . . . . . . . . . . . . 16
A.4. Key Schedule Computation . . . . . . . . . . . . . . . . 17
A.5. Protocol Run . . . . . . . . . . . . . . . . . . . . . . 17
Appendix B. Algorithm used for Point Generation . . . . . . . . 18
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document describes SPAKE2+, a Password Authenticated Key This document describes SPAKE2+, a Password Authenticated Key
Exchange (PAKE) protocol run between two parties for deriving a Exchange (PAKE) protocol run between two parties for deriving a
strong shared key with no risk of disclosing the password. SPAKE2+ strong shared key with no risk of disclosing the password. SPAKE2+
is an augmented PAKE protocol, as only one party makes direct use of is an augmented PAKE protocol, as only one party makes direct use of
the password during the execution of the protocol. The other party the password during the execution of the protocol. The other party
only needs a record corresponding to the other party's registration only needs a record corresponding to the other party's registration
at the time of the protocol execution instead of the password. This at the time of the protocol execution instead of the password. This
skipping to change at page 3, line 17 skipping to change at page 3, line 22
record. The design of the protocol forces the adversary to recover record. The design of the protocol forces the adversary to recover
the password from the record to successfully execute the protocol. the password from the record to successfully execute the protocol.
Hence this protocol can be advantageously combined with a salted Hence this protocol can be advantageously combined with a salted
Password Hashing Function to increase the cost of the recovery and Password Hashing Function to increase the cost of the recovery and
slow down attacks. The record cannot be used directly to slow down attacks. The record cannot be used directly to
successfully run the protocol as a prover, making this protocol more successfully run the protocol as a prover, making this protocol more
robust than balanced PAKEs which don't benefit from Password Hashing robust than balanced PAKEs which don't benefit from Password Hashing
Functions to the same extent. Functions to the same extent.
This augmented property is especially valuable in scenarios where the This augmented property is especially valuable in scenarios where the
execution of the protocol is constrained and the adversary cannot not execution of the protocol is constrained and the adversary cannot
query the salt of the password hash function ahead of the attack. query the salt of the password hash function ahead of the attack.
Constraints may consist in being in physical proximity through a Constraints may consist in being in physical proximity through a
local network or when initiation of the protocol requires a first local network or when initiation of the protocol requires a first
authentication factor. authentication factor.
This document has content split out from a related document This document has content split out from a related document
specifying SPAKE2 [I-D.irtf-cfrg-spake2], which is a symmetric PAKE specifying SPAKE2 [I-D.irtf-cfrg-spake2], which is a symmetric PAKE
protocol, where both parties have knowledge of the password. SPAKE2+ protocol, where both parties have knowledge of the password. SPAKE2+
is the asymmetric or augmented version of SPAKE2, wherein only one is the asymmetric or augmented version of SPAKE2, wherein only one
party has knowledge of the password. SPAKE2+ is specified separately party has knowledge of the password. SPAKE2+ is specified separately
skipping to change at page 6, line 9 skipping to change at page 6, line 35
registration record L=w1*P. w0 and w1 are derived by hashing 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 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 record L are then shared with the verifier and stored as part of the
registration record associated with the prover. The prover SHOULD registration record associated with the prover. The prover SHOULD
derive w0 and w1 from the password before the protocol begins. Both 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 w0 and w1 are derived using a function with range [0, p-1], which is
modeled as a random oracle in [SPAKE2P-Analysis]. modeled as a random oracle in [SPAKE2P-Analysis].
The registration phase also produces two random elements M and N in 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 the prime-order subgroup of G. The algorithm for selecting M and N
is defined in Appendix A. Importantly, this algorithm chooses M and is defined in Appendix B. Importantly, this algorithm chooses M and
N such that their discrete logs are not known. Pre-computed values N such that their discrete logs are not known. Pre-computed values
for M and N are listed in Section 4 for each group. Applications MAY 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 use different M and N values provided they are computed, e.g., using
different input seeds to the algorithm in Appendix A, as random different input seeds to the algorithm in Appendix B, as random
elements for which the discrete log is unknown. elements for which the discrete log is unknown.
Applications using this specification MUST define the method used to Applications using this specification MUST define the method used to
compute w0 and w1. For example, it may be necessary to carry out compute w0 and w1. For example, it may be necessary to carry out
various forms of normalization of the password before hashing various forms of normalization of the password before hashing
[RFC8265]. This section contains requirements and default [RFC8265]. This section contains requirements and default
recommendations for computing w0 and w1. recommendations for computing w0 and w1.
The RECOMMENDED method for generating w0 and w1 is via a Password- The RECOMMENDED method for generating w0 and w1 is via a Password-
Based Key Derivation Function (PBKDF), which is a function designed Based Key Derivation Function (PBKDF), which is a function designed
skipping to change at page 8, line 34 skipping to change at page 9, line 23
If an identity is absent, its length is given as zero and the If an identity is absent, its length is given as zero and the
identity itself is represented as the empty octet string. If both identity itself is represented as the empty octet string. If both
identities are absent, then their lengths are given as zero and both identities are absent, then their lengths are given as zero and both
are represented as empty octet strings. In applications where are represented as empty octet strings. In applications where
identities are not implicit, idProver and idVerifier SHOULD always be identities are not implicit, idProver and idVerifier SHOULD always be
non-empty. Otherwise, the protocol risks Unknown Key Share attacks non-empty. Otherwise, the protocol risks Unknown Key Share attacks
(discussion of Unknown Key Share attacks in a specific protocol is (discussion of Unknown Key Share attacks in a specific protocol is
given in [RFC8844]). given in [RFC8844]).
Upon completion of this protocol, both parties compute shared secrets Upon completion of this protocol, both parties compute shared secrets
K_auth, K_enc, K_confirmP, and K_confirmV as specified in K_main, K_shared, K_confirmP, and K_confirmV as specified in
Section 3.4. The verifier MUST send a key confirmation message Section 3.4. The verifier MUST send a key confirmation message
confirmV to the prover so both parties can confirm that they agree confirmV to the prover so both parties can confirm that they agree
upon these shared secrets. After receipt and verification of the upon these shared secrets. After receipt and verification of the
verifier's confirmation message, the prover MUST respond with its verifier's confirmation message, the prover MUST respond with its
confirmation message. The verifier MUST NOT send application data to confirmation message. The verifier MUST NOT send application data to
the prover until it has received and verified the confirmation the prover until it has received and verified the confirmation
message. Key confirmation verification requires recomputation of message. Key confirmation verification requires recomputation of
confirmP or confirmV and checking for equality against that which was confirmP or confirmV and checking for equality against that which was
received. received.
skipping to change at page 9, line 29 skipping to change at page 10, line 20
CMAC-AES-128. CMAC-AES-128.
Both endpoints MUST employ a MAC that produces pseudorandom tags for Both endpoints MUST employ a MAC that produces pseudorandom tags for
key confirmation. K_confirmP and K_confirmV are symmetric keys used key confirmation. K_confirmP and K_confirmV are symmetric keys used
to compute tags confirmP and confirmV over the public key shares to compute tags confirmP and confirmV over the public key shares
received from the other peer earlier. received from the other peer earlier.
confirmP = MAC(K_confirmP, shareV) confirmP = MAC(K_confirmP, shareV)
confirmV = MAC(K_confirmV, shareP) confirmV = MAC(K_confirmV, shareP)
Once key confirmation is complete, applications MAY use K_enc as an Once key confirmation is complete, applications MAY use K_shared as
authenticated shared secret as needed. For example, applications MAY an authenticated shared secret as needed. For example, applications
derive one or more AEAD keys and nonces from K_enc for subsequent MAY derive one or more AEAD keys and nonces from K_shared for
application data encryption. subsequent application data encryption.
4. Ciphersuites 4. Ciphersuites
This section documents SPAKE2+ ciphersuite configurations. A This section documents SPAKE2+ ciphersuite configurations. A
ciphersuite indicates a group, cryptographic hash algorithm, and pair ciphersuite indicates a group, cryptographic hash algorithm, and pair
of KDF and MAC functions, e.g., P256-SHA256-HKDF-HMAC-SHA256. This of KDF and MAC functions, e.g., P256-SHA256-HKDF-HMAC-SHA256. This
ciphersuite indicates a SPAKE2+ protocol instance over P-256 that ciphersuite indicates a SPAKE2+ protocol instance over P-256 that
uses SHA256 along with HKDF [RFC5869] and HMAC [RFC2104] for G, Hash, uses SHA256 along with HKDF [RFC5869] and HMAC [RFC2104] for G, Hash,
KDF, and MAC functions, respectively. Since the choice of PBKDF and KDF, and MAC functions, respectively. Since the choice of PBKDF and
its parameters for computing w0 and w1 and distributing does not its parameters for computing w0 and w1 and distributing does not
skipping to change at page 10, line 40 skipping to change at page 11, line 40
| | | [RFC5869] | [RFC4493] | | | | [RFC5869] | [RFC4493] |
+--------------+------------------+-------------+--------------+ +--------------+------------------+-------------+--------------+
| P-256 | SHA512 [RFC6234] | HKDF-SHA512 | CMAC-AES-128 | | P-256 | SHA512 [RFC6234] | HKDF-SHA512 | CMAC-AES-128 |
| | | [RFC5869] | [RFC4493] | | | | [RFC5869] | [RFC4493] |
+--------------+------------------+-------------+--------------+ +--------------+------------------+-------------+--------------+
Table 1 Table 1
The following points represent permissible point generation seeds for The following points represent permissible point generation seeds for
the groups listed in Table 1, using the algorithm presented in the groups listed in Table 1, using the algorithm presented in
Appendix A. These bytestrings are compressed points as in [SEC1] for Appendix B. These bytestrings are compressed points as in [SEC1] for
curves from [SEC1] and [RFC8032]. Note that these values are curves from [SEC1] and [RFC8032]. Note that these values are
identical to those used in the companion SPAKE2 specification identical to those used in the companion SPAKE2 specification
[I-D.irtf-cfrg-spake2]. [I-D.irtf-cfrg-spake2].
For P256: For P256:
M = M =
02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f
seed: 1.2.840.10045.3.1.7 point generation seed (M) seed: 1.2.840.10045.3.1.7 point generation seed (M)
skipping to change at page 12, line 48 skipping to change at page 13, line 48
Thanks to Ben Kaduk and Watson Ladd, from which this specification Thanks to Ben Kaduk and Watson Ladd, from which this specification
originally emanated. originally emanated.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.irtf-cfrg-spake2] [I-D.irtf-cfrg-spake2]
Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", Work in Progress, Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", Work in Progress,
Internet-Draft, draft-irtf-cfrg-spake2-26, 8 February Internet-Draft, draft-irtf-cfrg-spake2-26, 8 February
2022, <https://www.ietf.org/archive/id/draft-irtf-cfrg- 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-
spake2-26.txt>. cfrg-spake2-26>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/rfc/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
2006, <https://www.rfc-editor.org/info/rfc4493>. 2006, <https://www.rfc-editor.org/rfc/rfc4493>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key "Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/info/rfc5480>. <https://www.rfc-editor.org/rfc/rfc5480>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/rfc/rfc5869>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/rfc/rfc6234>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 8265, Representing Usernames and Passwords", RFC 8265,
DOI 10.17487/RFC8265, October 2017, DOI 10.17487/RFC8265, October 2017,
<https://www.rfc-editor.org/info/rfc8265>. <https://www.rfc-editor.org/rfc/rfc8265>.
[SEC1] "Elliptic Curve Cryptography, Standards for Efficient [SEC1] "Elliptic Curve Cryptography, Standards for Efficient
Cryptography Group, ver. 2", 2009, Cryptography Group, ver. 2", 2009,
<https://secg.org/sec1-v2.pdf>. <https://secg.org/sec1-v2.pdf>.
[SPAKE2P-Analysis] [SPAKE2P-Analysis]
"Security analysis of SPAKE2+", 2020, "Security analysis of SPAKE2+", 2020,
<https://eprint.iacr.org/2020/313.pdf>. <https://eprint.iacr.org/2020/313.pdf>.
[TDH] "The Twin-Diffie Hellman Problem and Applications", [TDH] "The Twin-Diffie Hellman Problem and Applications",
EUROCRYPT 2008, Volume 4965 of Lecture notes in Computer EUROCRYPT 2008, Volume 4965 of Lecture notes in Computer
Science, pages 127-145, Springer-Verlag, Berlin, Germany , Science, pages 127-145, Springer-Verlag, Berlin, Germany ,
2008. 2008.
8.2. Informative References 8.2. Informative References
[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
August 2016, <https://www.rfc-editor.org/info/rfc7914>. August 2016, <https://www.rfc-editor.org/rfc/rfc7914>.
[RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on [RFC8844] Thomson, M. and E. Rescorla, "Unknown Key-Share Attacks on
Uses of TLS with the Session Description Protocol (SDP)", Uses of TLS with the Session Description Protocol (SDP)",
RFC 8844, DOI 10.17487/RFC8844, January 2021, RFC 8844, DOI 10.17487/RFC8844, January 2021,
<https://www.rfc-editor.org/info/rfc8844>. <https://www.rfc-editor.org/rfc/rfc8844>.
[RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S. [RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "Argon2 Memory-Hard Function for Password Josefsson, "Argon2 Memory-Hard Function for Password
Hashing and Proof-of-Work Applications", RFC 9106, Hashing and Proof-of-Work Applications", RFC 9106,
DOI 10.17487/RFC9106, September 2021, DOI 10.17487/RFC9106, September 2021,
<https://www.rfc-editor.org/info/rfc9106>. <https://www.rfc-editor.org/rfc/rfc9106>.
Appendix A. Algorithm used for Point Generation 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's behavior consists of 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's behavior consists of 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 Prover and 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 Prover and 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 This section describes the algorithm that was used to generate the
points M and N in the table in Section 4. This algorithm produces M points M and N in the table in Section 4. This algorithm produces M
and N such that they are indistinguishable from two random points in 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 the prime-order subgroup of G, where the discrete log of these points
is unknown. See [SPAKE2P-Analysis] for additional details on this is unknown. See [SPAKE2P-Analysis] for additional details on this
requirement. requirement.
For each curve in the table below, we construct a string using the For each curve in the table below, we construct a string using the
curve OID from [RFC5480] (as an ASCII string) or its name, combined curve OID from [RFC5480] (as an ASCII string) or its name, combined
skipping to change at page 16, line 35 skipping to change at page 20, line 35
for i in range(1, 1000): for i in range(1, 1000):
hval = bighash(seed, i, len(ec.encode())) hval = bighash(seed, i, len(ec.encode()))
pointstr = canon_pointstr(ecname, hval) pointstr = canon_pointstr(ecname, hval)
try: try:
p = ec.decode(pointstr) p = ec.decode(pointstr)
if p != ec.zero_elem() and p * p.l() == ec.zero_elem(): if p != ec.zero_elem() and p * p.l() == ec.zero_elem():
return pointstr, i return pointstr, i
except Exception: except Exception:
pass pass
Appendix B. Test Vectors Appendix C. Test Vectors
This section contains various test vectors for SPAKE2+. (Choice of This section contains various test vectors for SPAKE2+. (Choice of
PBKDF is omitted and values for w0 and w1 are provided directly.) PBKDF is omitted and values for w0 and w1 are provided directly.)
All points are encoded using the uncompressed format, i.e., with a All points are encoded using the uncompressed format, i.e., with a
0x04 octet prefix, specified in [SEC1]. idProver and idVerifier 0x04 octet prefix, specified in [SEC1]. idProver and idVerifier
identity strings are provided in the protocol invocation. identity strings are provided in the protocol invocation.
[Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors [Context=b'SPAKE2+-P256-SHA256-HKDF-SHA256-HMAC-SHA256 Test Vectors
'] ']
[idProver=b'client'] [idProver=b'client']
 End of changes. 27 change blocks. 
42 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/