Independent Submission F. Hao, Ed.
Request for Comments: 8236 Newcastle University (UK)
Category: Informational September 2017
ISSN: 2070-1721
Independent Submission F. Hao, Ed.
Request for Comments: 8236 Newcastle University (UK)
Category: Informational September 2017
ISSN: 2070-1721
J-PAKE: Password-Authenticated Key Exchange by Juggling
J-PAKE：通过变戏法进行密码认证的密钥交换
Abstract
摘要
This document specifies a Password-Authenticated Key Exchange by Juggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party.
本文档指定了一种通过变戏法（J-PAKE）协议进行密码验证的密钥交换。该协议允许仅基于共享密码在不安全网络上的两个远程方之间建立安全的端到端通信通道，而不需要公钥基础设施（PKI）或任何受信任的第三方。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8236.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8236.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. J-PAKE over Finite Field . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 4
2.2. Two-Round Key Exchange . . . . . . . . . . . . . . . . . 5
2.3. Computational Cost . . . . . . . . . . . . . . . . . . . 6
3. J-PAKE over Elliptic Curve . . . . . . . . . . . . . . . . . 7
3.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 7
3.2. Two-Round Key Exchange . . . . . . . . . . . . . . . . . 7
3.3. Computational Cost . . . . . . . . . . . . . . . . . . . 8
4. Three-Pass Variant . . . . . . . . . . . . . . . . . . . . . 8
5. Key Confirmation . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. J-PAKE over Finite Field . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 4
2.2. Two-Round Key Exchange . . . . . . . . . . . . . . . . . 5
2.3. Computational Cost . . . . . . . . . . . . . . . . . . . 6
3. J-PAKE over Elliptic Curve . . . . . . . . . . . . . . . . . 7
3.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 7
3.2. Two-Round Key Exchange . . . . . . . . . . . . . . . . . 7
3.3. Computational Cost . . . . . . . . . . . . . . . . . . . 8
4. Three-Pass Variant . . . . . . . . . . . . . . . . . . . . . 8
5. Key Confirmation . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Password-Authenticated Key Exchange (PAKE) is a technique that aims to establish secure communication between two remote parties solely based on their shared password, without relying on a Public Key Infrastructure or any trusted third party [BM92]. The first PAKE protocol, called Encrypted Key Exchange (EKE), was proposed by Steven Bellovin and Michael Merrit in 1992 [BM92]. Other well-known PAKE protocols include Simple Password Exponential Key Exchange (SPEKE) by David Jablon in 1996 [Jab96] and Secure Remote Password (SRP) by Tom Wu in 1998 [Wu98]. SRP has been revised several times to address reported security and efficiency issues. In particular, the version 6 of SRP, commonly known as SRP-6, is specified in [RFC5054].
密码认证密钥交换（PAKE）是一种旨在仅基于共享密码在两个远程方之间建立安全通信的技术，无需依赖公钥基础设施或任何受信任的第三方[BM92]。第一个PAKE协议称为加密密钥交换（EKE），由Steven Bellovin和Michael Merrit于1992年提出[BM92]。其他著名的PAKE协议包括David Jablon于1996年提出的简单密码指数密钥交换（SPEKE）[Jab96]和Tom Wu于1998年提出的安全远程密码（SRP）[Wu98]。SRP已多次修订，以解决报告的安全和效率问题。具体而言，[RFC5054]中规定了SRP的版本6，通常称为SRP-6。
This document specifies a PAKE protocol called Password-Authenticated Key Exchange by Juggling (J-PAKE), which was designed by Feng Hao and Peter Ryan in 2008 [HR08]. There are a few factors that may be considered in favor of J-PAKE. First, J-PAKE has security proofs, while equivalent proofs are lacking in EKE, SPEKE and SRP-6. Second, J-PAKE follows a completely different design approach from all other PAKE protocols, and is built upon a well-established Zero Knowledge Proof (ZKP) primitive: Schnorr NIZK proof [RFC8235]. Third, J-PAKE adopts novel engineering techniques to optimize the use of ZKP so that overall the protocol is sufficiently efficient for practical use. Fourth, J-PAKE is designed to work generically in both the
本文档指定了一个名为密码验证密钥交换（J-PAKE）的PAKE协议，该协议由冯浩和Peter Ryan于2008年设计[HR08]。有几个因素可能有利于J-PAKE。首先，J-PAKE有安全性证明，而EKE、SPEKE和SRP-6中缺少等价的证明。其次，J-PAKE采用了与所有其他PAKE协议完全不同的设计方法，并基于一个成熟的零知识证明（ZKP）原语：Schnorr-NIZK证明[RFC8235]。第三，J-PAKE采用了新的工程技术来优化ZKP的使用，从而使整个协议具有足够的实际使用效率。第四，J-PAKE被设计为在两种环境中通用
finite field and elliptic curve settings (i.e., DSA and ECDSA-like groups, respectively). Unlike SPEKE, it does not require any extra primitive to hash passwords onto a designated elliptic curve. Unlike SPAKE2 [AP05] and SESPAKE [SOAA15], it does not require a trusted setup (i.e., the so-called common reference model) to define a pair of generators whose discrete logarithm must be unknown. Finally, J-PAKE has been used in real-world applications at a relatively large scale, e.g., Firefox sync [MOZILLA], Pale moon sync [PALEMOON], and Google Nest products [ABM15]. It has been included into widely distributed open source libraries such as OpenSSL [BOINC], Network Security Services (NSS) [MOZILLA_NSS], and the Bouncy Castle [BOUNCY]. Since 2015, J-PAKE has been included in Thread [THREAD] as a standard key agreement mechanism for IoT (Internet of Things) applications, and also included in ISO/IEC 11770-4:2017 [ISO.11770-4].
有限域和椭圆曲线设置（即分别为DSA和ECDSA类组）。与SPEKE不同，它不需要任何额外的原语将密码散列到指定的椭圆曲线上。与SPAKE2[AP05]和SESPAKE[SOAA15]不同，它不需要可信设置（即所谓的公共参考模型）来定义离散对数必须未知的一对生成器。最后，J-PAKE已经在现实世界中得到了相对大规模的应用，例如Firefox sync[MOZILLA]、Pale moon sync[PALEMOON]和Google Nest产品[ABM15]。它已被包括在广泛分布的开源库中，如OpenSSL[BOINC]、网络安全服务（NSS）[MOZILLA_NSS]和Bouncy Castle[Bouncy]。自2015年以来，J-PAKE作为物联网应用的标准密钥协商机制被纳入了Thread[Thread]，也被纳入了ISO/IEC 11770-4:2017[ISO.11770-4]。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The following notation is used in this document:
本文件中使用了以下符号：
o Alice: the assumed identity of the prover in the protocol
o Alice：协议中验证人的假定身份
o Bob: the assumed identity of the verifier in the protocol
o 协议中验证器的假定身份
o s: a low-entropy secret shared between Alice and Bob
o s：爱丽丝和鲍勃之间共享的低熵秘密
o a | b: a divides b
o a | b:a除以b
o a || b: concatenation of a and b
o a | | b：a和b的串联
o [a, b]: the interval of integers between and including a and b
o [a，b]：介于a和b之间且包括a和b的整数的间隔
o H: a secure cryptographic hash function
o H：一个安全的加密散列函数
o p: a large prime
o 大素数
o q: a large prime divisor of p-1, i.e., q | p-1
o q:p-1的大素因子，即q | p-1
o Zp*: a multiplicative group of integers modulo p
o Zp*：模p的整数的乘法群
o Gq: a subgroup of Zp* with prime order q
o Gq：具有素数阶q的Zp*的子群
o g: a generator of Gq
o g:Gq的发生器
o g^d: g raised to the power of d
o g^d:g提升到d的幂
o a mod b: a modulo b
o a模b:a模b
o Fp: a finite field of p elements, where p is a prime
o Fp：p元素的有限域，其中p是素数
o E(Fp): an elliptic curve defined over Fp
o E（Fp）：定义在Fp上的椭圆曲线
o G: a generator of the subgroup over E(Fp) with prime order n
o G:E（Fp）上素数阶为n的子群的生成元
o n: the order of G
o n：G的阶
o h: the cofactor of the subgroup generated by G, which is equal to the order of the elliptic curve divided by n
o h：G生成的子群的余因子，等于椭圆曲线的阶数除以n
o P x [b]: multiplication of a point P with a scalar b over E(Fp)
o px[b]：点P与标量b乘以E（Fp）
o KDF(a): Key Derivation Function with input a
o KDF（a）：带输入a的键派生函数
o MAC(MacKey, MacData): MAC function with MacKey as the key and MacData as the input data
o MAC（MacKey，MacData）：MAC功能，MacKey为键，MacData为输入数据
When implemented over a finite field, J-PAKE may use the same group parameters as DSA [FIPS186-4]. Let p and q be two large primes such that q | p-1. Let Gq denote a subgroup of Zp* with prime order q. Let g be a generator for Gq. Any non-identity element in Gq can be a generator. The two communicating parties, Alice and Bob, both agree on (p, q, g), which can be hard-wired in the software code. They can also use the method in NIST FIPS 186-4, Appendix A [FIPS186-4] to generate (p, q, g). Here, DSA group parameters are used only as an example. Other multiplicative groups suitable for cryptography can also be used for the implementation, e.g., groups defined in [RFC4419]. A group setting that provides 128-bit security or above is recommended. The security proof of J-PAKE depends on the Decisional Diffie-Hellman (DDH) problem being intractable in the considered group.
当在有限域上实现时，J-PAKE可以使用与DSA相同的组参数[FIPS186-4]。设p和q是两个大素数，使得q | p-1。设Gq表示具有素数阶q的Zp*的子群。设g为Gq的生成元。Gq中的任何非标识元素都可以是生成器。通信双方Alice和Bob都同意（p，q，g），可以在软件代码中硬连线。他们也可以使用NIST FIPS 186-4附录A[FIPS186-4]中的方法生成（p，q，g）。这里，DSA组参数仅用作示例。适用于加密的其他乘法组也可用于实现，例如，[RFC4419]中定义的组。建议使用提供128位或更高安全性的组设置。J-PAKE的安全性证明依赖于决策Diffie-Hellman（DDH）问题在所考虑的组中是难以解决的。
Let s be a secret value derived from a low-entropy password shared between Alice and Bob. The value of s is REQUIRED to fall within the range of [1, q-1]. (Note that s must not be 0 for any non-empty
设我们是从Alice和Bob之间共享的低熵密码派生的秘密值。要求s的值在[1，q-1]的范围内。（请注意，对于任何非空值，s不得为0。）
secret.) This range is defined as a necessary condition in [HR08] for proving the "on-line dictionary attack resistance", since s, s+q, s+2q, ..., are all considered equivalent values as far as the protocol specification is concerned. In a practical implementation, one may obtain s by taking a cryptographic hash of the password and wrapping the result with respect to modulo q. Alternatively, one may simply treat the password as an octet string and convert the string to an integer modulo q by following the method defined in Section 2.3.8 of [SEC1]. In either case, one MUST ensure s is not equal to 0 modulo q.
机密。）该范围在[HR08]中定义为证明“在线字典攻击抵抗力”的必要条件，因为就协议规范而言，s、s+q、s+2q……都被视为等效值。在实际实现中，可以通过获取密码的密码散列并将结果包装到模q来获得s。或者，可以简单地将密码视为八位字节字符串，并按照[SEC1]第2.3.8节中定义的方法将该字符串转换为整数模q。在这两种情况下，必须确保s不等于0模q。
Round 1: Alice selects an ephemeral private key x1 uniformly at random from [0, q-1] and another ephemeral private key x2 uniformly at random from [1, q-1]. Similarly, Bob selects an ephemeral private key x3 uniformly at random from [0, q-1] and another ephemeral private key x4 uniformly at random from [1, q-1].
第1轮：Alice从[0，q-1]中均匀随机地选择一个临时私钥x1，从[1，q-1]中均匀随机地选择另一个临时私钥x2。类似地，Bob从[0，q-1]中均匀地随机选择一个临时私钥x3，从[1，q-1]中均匀地随机选择另一个临时私钥x4。
o Alice -> Bob: g1 = g^x1 mod p, g2 = g^x2 mod p and ZKPs for x1 and x2
o Alice->Bob:g1=g^x1 mod p，g2=g^x2 mod p和ZKPs表示x1和x2
o Bob -> Alice: g3 = g^x3 mod p, g4 = g^x4 mod p and ZKPs for x3 and x4
o Bob->Alice:g3=g^x3模p，g4=g^x4模p，以及x3和x4的ZKPs
In this round, the sender must send zero knowledge proofs to demonstrate the knowledge of the ephemeral private keys. A suitable technique is to use the Schnorr NIZK proof [RFC8235]. As an example, suppose one wishes to prove the knowledge of the exponent for D = g^d mod p. The generated Schnorr NIZK proof will contain: {UserID, V = g^v mod p, r = v - d * c mod q}, where UserID is the unique identifier for the prover, v is a number chosen uniformly at random from [0, q-1] and c = H(g || V || D || UserID). The "uniqueness" of UserID is defined from the user's perspective -- for example, if Alice communicates with several parties, she shall associate a unique identity with each party. Upon receiving a Schnorr NIZK proof, Alice shall check the prover's UserID is a valid identity and is different from her own identity. During the key exchange process using J-PAKE, each party shall ensure that the other party has been consistently using the same identity throughout the protocol execution. Details about the Schnorr NIZK proof, including the generation and the verification procedures, can be found in [RFC8235].
在这一轮中，发送方必须发送零知识证明来证明对短暂私钥的知识。一种合适的技术是使用Schnorr-NIZK证明[RFC8235]。作为一个例子，假设人们希望证明关于D=g^D mod p的指数的知识。生成的Schnorr-NIZK证明将包含：{UserID，V=g^V mod p，r=V-d*c mod q}，其中UserID是验证程序的唯一标识符，V是从[0，q-1]和c=H（g | | V | | d | UserID）中均匀随机选择的数字。用户ID的“唯一性”是从用户的角度定义的——例如，如果Alice与多个方进行通信，则她应将一个唯一的身份与每一方关联。收到Schnorr NIZK证明后，Alice应检查验证人的用户ID是否有效，是否与自己的身份不同。在使用J-PAKE的密钥交换过程中，各方应确保另一方在整个协议执行过程中始终使用相同的身份。有关Schnorr-NIZK证明的详细信息，包括生成和验证程序，请参见[RFC8235]。
When this round finishes, Alice verifies the received ZKPs as specified in [RFC8235] and also checks that g4 != 1 mod p. Similarly, Bob verifies the received ZKPs and also checks that g2 != 1 mod p. If any of these checks fails, this session should be aborted.
当这一轮结束时，Alice按照[RFC8235]中的规定验证收到的ZKP，并检查g4！=1模p。类似地，Bob验证接收到的ZKP，并检查g2！=1模p。如果其中任何一项检查失败，则应中止此会话。
Round 2:
第二轮：
o Alice -> Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s
o Alice->Bob:A=（g1*g3*g4）^（x2*s）mod p和x2*s的ZKP
o Bob -> Alice: B = (g1*g2*g3)^(x4*s) mod p and a ZKP for x4*s
o Bob->Alice:B=（g1*g2*g3）^（x4*s）mod p和x4*s的ZKP
In this round, the Schnorr NIZK proof is computed in the same way as in the previous round except that the generator is different. For Alice, the generator used is (g1*g3*g4) instead of g; for Bob, the generator is (g1*g2*g3) instead of g. Since any non-identity element in Gq can be used as a generator, Alice and Bob just need to ensure g1*g3*g4 != 1 mod p and g1*g2*g3 != 1 mod p. With overwhelming probability, these inequalities are statistically guaranteed even when the user is communicating with an adversary (i.e., in an active attack). Nonetheless, for absolute guarantee, the receiving party shall explicitly check if these inequalities hold, and abort the session in case such a check fails.
在这一轮中，Schnorr-NIZK证明的计算方法与上一轮相同，只是生成器不同。对于Alice，使用的生成器是（g1*g3*g4）而不是g；对于Bob，生成器是（g1*g2*g3）而不是g。由于Gq中的任何非标识元素都可以用作生成器，Alice和Bob只需确保g1*g3*g4！=1模p和g1*g2*g3！=1模p。以压倒性的概率，即使在用户与对手通信时（即在主动攻击中），这些不平等在统计上也是有保证的。尽管如此，为了绝对保证，接收方应明确检查这些不平等是否成立，并在检查失败时中止会话。
When the second round finishes, Alice and Bob verify the received ZKPs. If the verification fails, the session is aborted. Otherwise, the two parties compute the common key material as follows:
当第二轮结束时，Alice和Bob验证收到的ZKP。如果验证失败，会话将中止。否则，双方计算共同关键材料如下：
o Alice computes Ka = (B/g4^(x2*s))^x2 mod p
o Alice计算Ka=（B/g4^（x2*s））^x2 mod p
o Bob computes Kb = (A/g2^(x4*s))^x4 mod p
o Bob计算Kb=（A/g2^（x4*s））^x4模p
Here, Ka = Kb = g^((x1+x3)*x2*x4*s) mod p. Let K denote the same key material held by both parties. Using K as input, Alice and Bob then apply a Key Derivation Function (KDF) to derive a common session key k. If the subsequent secure communication uses a symmetric cipher in an authenticated mode (say AES-GCM), then one key is sufficient, i.e., k = KDF(K). Otherwise, the session key should comprise an encryption key (for confidentiality) and a MAC key (for integrity), i.e., k = k_enc || k_mac, where k_enc = KDF(K || "JPAKE_ENC") and k_mac = KDF(K || "JPAKE_MAC"). The exact choice of the KDF is left to specific applications to define.
这里，Ka=Kb=g^（（x1+x3）*x2*x4*s）mod p。让K表示双方持有的相同关键材料。使用K作为输入，Alice和Bob然后应用密钥派生函数（KDF）来派生公共会话密钥K。如果随后的安全通信在认证模式下使用对称密码（例如AES-GCM），则一个密钥就足够了，即k=KDF（k）。否则，会话密钥应该包括加密密钥（用于保密）和MAC密钥（用于完整性），即k=k|enc|k|MAC，其中k|enc=KDF（k||“JPAKE|enc”）和k|MAC=KDF（k||“JPAKE|MAC”）。KDF的确切选择留给特定的应用程序来定义。
The computational cost is estimated based on counting the number of modular exponentiations since they are the predominant cost factors. Note that it takes one exponentiation to generate a Schnorr NIZK proof and two to verify it [RFC8235]. For Alice, she needs to perform 8 exponentiations in the first round, 4 in the second round, and 2 in the final computation of the session key. Hence, that is 14 modular exponentiations in total. Based on the symmetry, the computational cost for Bob is exactly the same.
由于模幂运算是主要的成本因素，因此计算成本是基于计算模幂运算的数量来估算的。请注意，生成Schnorr-NIZK证明需要一次求幂运算，验证它需要两次求幂运算[RFC8235]。对于Alice，她需要在第一轮中执行8次幂运算，在第二轮中执行4次幂运算，在会话密钥的最终计算中执行2次幂运算。因此，总共是14次模幂运算。基于对称性，Bob的计算成本完全相同。
The J-PAKE protocol works basically the same in the elliptic curve (EC) setting, except that the underlying multiplicative group over a finite field is replaced by an additive group over an elliptic curve. Nonetheless, the EC version of J-PAKE is specified here for completeness.
J-PAKE协议在椭圆曲线（EC）设置中的工作原理基本相同，只是有限域上的基础乘法群被椭圆曲线上的加法群所取代。尽管如此，为了完整性，这里指定了J-PAKE的EC版本。
When implemented over an elliptic curve, J-PAKE may use the same EC parameters as ECDSA [FIPS186-4]. The FIPS 186-4 standard [FIPS186-4] defines three types of curves suitable for ECDSA: pseudorandom curves over prime fields, pseudorandom curves over binary fields, and special curves over binary fields called Koblitz curves or anomalous binary curves. All these curves that are suitable for ECDSA can also be used to implement J-PAKE. However, for illustration purposes, only curves over prime fields are described in this document. Typically, such curves include NIST P-256, P-384, and P-521. When choosing a curve, a level of 128-bit security or above is recommended. Let E(Fp) be an elliptic curve defined over a finite field Fp, where p is a large prime. Let G be a generator for the subgroup over E(Fp) of prime order n. Here, the NIST curves are used only as an example. Other secure curves such as Curve25519 are also suitable for implementation. The security proof of J-PAKE relies on the assumption that the DDH problem is intractable in the considered group.
当在椭圆曲线上实现时，J-PAKE可以使用与ECDSA相同的EC参数[FIPS186-4]。FIPS 186-4标准[FIPS186-4]定义了三种适用于ECDSA的曲线类型：素域上的伪随机曲线、二元域上的伪随机曲线以及称为Koblitz曲线或异常二元曲线的二元域上的特殊曲线。所有这些适用于ECDSA的曲线也可用于实现J-PAKE。然而，为了便于说明，本文档仅描述素数字段上的曲线。通常，此类曲线包括NIST P-256、P-384和P-521。选择曲线时，建议使用128位或更高级别的安全性。设E（Fp）是有限域Fp上定义的椭圆曲线，其中p是大素数。设G是素数阶n的E（Fp）上的子群的生成元。这里，NIST曲线仅用作示例。其他安全曲线（如Curve25519）也适用于实现。J-PAKE的安全性证明依赖于DDH问题在所考虑的组中是难以解决的假设。
As before, let s denote the shared secret between Alice and Bob. The value of s falls within [1, n-1]. In particular, note that s MUST not be equal to 0 mod n.
和前面一样，让我们表示Alice和Bob之间的共享秘密。s的值在[1，n-1]范围内。特别要注意的是，s不能等于0 mod n。
Round 1: Alice selects ephemeral private keys x1 and x2 uniformly at random from [1, n-1]. Similarly, Bob selects ephemeral private keys x3 and x4 uniformly at random from [1, n-1].
第1轮：Alice从[1，n-1]中随机均匀地选择临时私钥x1和x2。类似地，Bob从[1，n-1]中均匀随机地选择临时私钥x3和x4。
o Alice -> Bob: G1 = G x [x1], G2 = G x [x2] and ZKPs for x1 and x2
o Alice->Bob:G1=gx[x1]，G2=gx[x2]以及x1和x2的ZKPs
o Bob -> Alice: G3 = G x [x3], G4 = G x [x4] and ZKPs for x3 and x4
o Bob->Alice:G3=gx[x3]，G4=gx[x4]和x3和x4的ZKPs
When this round finishes, Alice and Bob verify the received ZKPs as specified in [RFC8235]. As an example, to prove the knowledge of the discrete logarithm of D = G x [d] with respect to the base point G, the ZKP contains: {UserID, V = G x [v], r = v - d * c mod n}, where UserID is the unique identifier for the prover, v is a number chosen uniformly at random from [1, n-1] and c = H(G || V || D || UserID).
当这一轮结束时，Alice和Bob按照[RFC8235]中的规定验证收到的ZKP。例如，为了证明关于基点G的D=gx[D]的离散对数的知识，ZKP包含：{UserID，V=gx[V]，r=V-D*c mod n}，其中UserID是证明者的唯一标识符，V是从[1，n-1]和c=H（G | | | V | | D | UserID）中均匀随机选择的数字。
The verifier shall check the prover's UserID is a valid identity and is different from its own identity. If the verification of the ZKP fails, the session is aborted.
验证人应检查验证人的用户ID是否有效，是否与其自身身份不同。如果ZKP验证失败，会话将中止。
Round 2:
第二轮：
o Alice -> Bob: A = (G1 + G3 + G4) x [x2*s] and a ZKP for x2*s
o Alice->Bob:A=（G1+G3+G4）x[x2*s]和x2*s的ZKP
o Bob -> Alice: B = (G1 + G2 + G3) x [x4*s] and a ZKP for x4*s
o Bob->Alice:B=（G1+G2+G3）x[x4*s]和x4*s的ZKP
When the second round finishes, Alice and Bob verify the received ZKPs. The ZKPs are computed in the same way as in the previous round except that the generator is different. For Alice, the new generator is G1 + G3 + G4; for Bob, it is G1 + G2 + G3. Alice and Bob shall check that these new generators are not points at infinity. If any of these checks fails, the session is aborted. Otherwise, the two parties compute the common key material as follows:
当第二轮结束时，Alice和Bob验证收到的ZKP。ZKPs的计算方法与上一轮相同，只是生成器不同。对于Alice，新发电机为G1+G3+G4；对于Bob，它是G1+G2+G3。Alice和Bob应检查这些新发电机是否为无穷远点。如果其中任何一项检查失败，会话将中止。否则，双方计算共同关键材料如下：
o Alice computes Ka = (B - (G4 x [x2*s])) x [x2]
o Alice计算Ka=（B-（G4 x[x2*s]）x[x2]
o Bob computes Kb = (A - (G2 x [x4*s])) x [x4]
o Bob计算Kb=（A-（G2 x[x4*s]）x[x4]
Here, Ka = Kb = G x [(x1+x3)*(x2*x4*s)]. Let K denote the same key material held by both parties. Using K as input, Alice and Bob then apply a Key Derivation Function (KDF) to derive a common session key k.
这里，Ka=Kb=gx[（x1+x3）*（x2*x4*s）]。让K表示双方持有的相同关键材料。使用K作为输入，Alice和Bob然后应用密钥派生函数（KDF）来派生公共会话密钥K。
In the EC setting, the computational cost of J-PAKE is estimated based on counting the number of scalar multiplications over the elliptic curve. Note that it takes one multiplication to generate a Schnorr NIZK proof and one to verify it [RFC8235]. For Alice, she has to perform 6 multiplications in the first round, 3 in the second round, and 2 in the final computation of the session key. Hence, that is 11 multiplications in total. Based on the symmetry, the computational cost for Bob is exactly the same.
在EC设置中，J-PAKE的计算成本是基于计算椭圆曲线上的标量乘法数来估计的。注意，一次乘法生成Schnorr-NIZK证明，一次乘法验证[RFC8235]。对于Alice，她必须在第一轮中执行6次乘法，在第二轮中执行3次乘法，在会话密钥的最终计算中执行2次乘法。因此，总共是11次乘法。基于对称性，Bob的计算成本完全相同。
The two-round J-PAKE protocol is completely symmetric, which significantly simplifies the security analysis. In practice, one party normally initiates the communication and the other party responds. In that case, the protocol will be completed in three passes instead of two rounds. The two-round J-PAKE protocol can be trivially changed to three passes without losing security. Take the finite field setting as an example, and assume Alice initiates the key exchange. The three-pass variant works as follows:
两轮J-PAKE协议是完全对称的，这大大简化了安全性分析。实际上，一方通常发起通信，另一方响应。在这种情况下，协议将在三次通过中完成，而不是两轮。两轮J-PAKE协议可以简单地更改为三次，而不会失去安全性。以有限域设置为例，假设Alice发起密钥交换。三通变体的工作原理如下：
1. Alice -> Bob: g1 = g^x1 mod p, g2 = g^x2 mod p, ZKPs for x1 and x2.
1. Alice->Bob:g1=g^x1 mod p，g2=g^x2 mod p，ZKPs表示x1和x2。
2. Bob -> Alice: g3 = g^x3 mod p, g4 = g^x4 mod p, B = (g1*g2*g3)^(x4*s) mod p, ZKPs for x3, x4, and x4*s.
2. Bob->Alice:g3=g^x3 mod p，g4=g^x4 mod p，B=（g1*g2*g3）^（x4*s）mod p，x3、x4和x4*s的ZKPs。
3. Alice -> Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s.
3. Alice->Bob:A=（g1*g3*g4）^（x2*s）mod p和x2*s的ZKP。
Both parties compute the session keys in exactly the same way as before.
双方以与之前完全相同的方式计算会话密钥。
The two-round J-PAKE protocol (or the three-pass variant) provides cryptographic guarantee that only the authenticated party who used the same password at the other end is able to compute the same session key. So far, the authentication is only implicit. The key confirmation is also implicit [Stinson06]. The two parties may use the derived key straight away to start secure communication by encrypting messages in an authenticated mode. Only the party with the same derived session key will be able to decrypt and read those messages.
两轮J-PAKE协议（或三通变体）提供了密码保证，只有在另一端使用相同密码的经过身份验证的一方才能计算相同的会话密钥。到目前为止，身份验证只是隐式的。密钥确认也是隐式的[Stinson06]。双方可以直接使用派生密钥，通过在认证模式下加密消息来启动安全通信。只有具有相同派生会话密钥的一方才能解密和读取这些消息。
For achieving explicit authentication, an additional key confirmation procedure should be performed. This provides explicit assurance that the other party has actually derived the same key. In this case, the key confirmation is explicit [Stinson06].
为了实现显式身份验证，应执行额外的密钥确认过程。这提供了另一方实际派生相同密钥的明确保证。在这种情况下，密钥确认是明确的[Stinson06]。
In J-PAKE, explicit key confirmation is recommended whenever the network bandwidth allows it. It has the benefit of providing explicit and immediate confirmation if the two parties have derived the same key and hence are authenticated to each other. This allows a practical implementation of J-PAKE to effectively detect online dictionary attacks (if any), and stop them accordingly by setting a threshold for the consecutively failed connection attempts.
在J-PAKE中，只要网络带宽允许，建议显式确认密钥。如果双方获得了相同的密钥并因此相互进行了身份验证，那么它的好处是提供明确和立即的确认。这使得J-PAKE的实际实现能够有效地检测在线字典攻击（如果有），并通过为连续失败的连接尝试设置阈值来相应地停止它们。
To achieve explicit key confirmation, there are several methods available. They are generically applicable to all key exchange protocols, not just J-PAKE. In general, it is recommended that a different key from the session key be used for key confirmation -- say, k' = KDF(K || "JPAKE_KC"). The advantage of using a different key for key confirmation is that the session key remains indistinguishable from random after the key confirmation process. (However, this perceived advantage is actually subtle and only theoretical.) Two explicit key confirmation methods are presented here.
要实现显式密钥确认，有几种方法可用。它们一般适用于所有密钥交换协议，而不仅仅是J-PAKE。通常，建议使用不同于会话密钥的密钥进行密钥确认——例如，k'=KDF（k | |“JPAKE|u KC”）。使用不同密钥进行密钥确认的优点是，在密钥确认过程之后，会话密钥与随机密钥仍然无法区分。（然而，这种感知优势实际上是微妙的，只是理论上的。）这里给出了两种明确的关键确认方法。
The first method is based on the one used in the SPEKE protocol [Jab96]. Suppose Alice initiates the key confirmation. Alice sends to Bob H(H(k')), which Bob will verify. If the verification is successful, Bob sends back to Alice H(k'), which Alice will verify. This key confirmation procedure needs to be completed in two rounds, as shown below.
第一种方法基于SPEKE协议中使用的方法[Jab96]。假设Alice启动密钥确认。Alice向Bob发送H（H（k'），Bob将验证该消息。如果验证成功，Bob将发送回Alice H（k'），Alice将对其进行验证。此关键确认程序需要分两轮完成，如下所示。
1. Alice -> Bob: H(H(k'))
1. 爱丽丝->鲍勃：H（H（k'））
2. Bob -> Alice: H(k')
2. 鲍勃->爱丽丝：H（k'）
The above procedure requires two rounds instead of one, because the second message depends on the first. If both parties attempt to send the first message at the same time without an agreed order, they cannot tell if the message that they receive is a genuine challenge or a replayed message, and consequently may enter a deadlock.
上述过程需要两轮而不是一轮，因为第二条消息取决于第一条消息。如果双方试图在没有约定顺序的情况下同时发送第一条消息，则无法判断收到的消息是真正的质询消息还是重播消息，因此可能会进入死锁。
The second method is based on the unilateral key confirmation scheme specified in NIST SP 800-56A Revision 1 [BJS07]. Alice and Bob send to each other a MAC tag, which they will verify accordingly. This key confirmation procedure can be completed in one round.
第二种方法基于NIST SP 800-56A第1版[BJS07]中规定的单边密钥确认方案。Alice和Bob互相发送一个MAC标签，他们将据此进行验证。这一关键确认程序可在一轮中完成。
In the finite field setting, it works as follows.
在有限域设置中，它的工作方式如下。
o Alice -> Bob: MacTagAlice = MAC(k', "KC_1_U" || Alice || Bob || g1 || g2 || g3 || g4)
o Alice->Bob:MacTagAlice=MAC（k'，“KC|U 1|U”| Alice | Bob | g1 | g2 | g3 | g4）
o Bob -> Alice: MacTagBob = MAC(k', "KC_1_U" || Bob || Alice || g3 || g4 || g1 || g2)
o Bob->Alice:MacTagBob=MAC（k'，“KC|U 1|U”| Bob | Alice | g3 | g4 | g1 | g2）
In the EC setting, the key confirmation works basically the same.
在EC设置中，按键确认的工作原理基本相同。
o Alice -> Bob: MacTagAlice = MAC(k', "KC_1_U" || Alice || Bob || G1 || G2 || G3 || G4)
o Alice->Bob:MacTagAlice=MAC（k'，“KC|U 1|U”| Alice | Bob | G1 | G2 | G3 | G4）
o Bob -> Alice: MacTagBob = MAC(k', "KC_1_U" || Bob || Alice || G3 || G4 || G1 || G2)
o Bob->Alice:MacTagBob=MAC（k'，“KC|U 1|U”| Bob | Alice | G3 | G4 | G1 | G2）
The second method assumes an additional secure MAC function (e.g., one may use HMAC) and is slightly more complex than the first method. However, it can be completed within one round and it preserves the overall symmetry of the protocol implementation. For this reason, the second method is RECOMMENDED.
第二种方法假设一个附加的安全MAC功能（例如，可以使用HMAC），并且比第一种方法稍微复杂一些。但是，它可以在一轮内完成，并且保持了协议实现的整体对称性。因此，建议采用第二种方法。
A PAKE protocol is designed to provide two functions in one protocol execution. The first one is to provide zero-knowledge authentication of a password. It is called "zero knowledge" because at the end of the protocol, the two communicating parties will learn nothing more than one bit information: whether the passwords supplied at two ends are equal. Therefore, a PAKE protocol is naturally resistant against phishing attacks. The second function is to provide session key establishment if the two passwords are equal. The session key will be used to protect the confidentiality and integrity of the subsequent communication.
PAKE协议设计用于在一个协议执行中提供两个功能。第一种是提供密码的零知识认证。它被称为“零知识”，因为在协议结束时，通信双方只会学到一位信息：两端提供的密码是否相等。因此，PAKE协议自然能够抵抗网络钓鱼攻击。第二个功能是在两个密码相等时提供会话密钥建立。会话密钥将用于保护后续通信的机密性和完整性。
More concretely, a secure PAKE protocol shall satisfy the following security requirements [HR10].
更具体地说，安全PAKE协议应满足以下安全要求[HR10]。
1. Offline dictionary attack resistance: It does not leak any information that allows a passive/active attacker to perform offline exhaustive search of the password.
1. 脱机字典攻击抵抗：它不会泄漏任何信息，使被动/主动攻击者能够执行脱机彻底搜索密码。
2. Forward secrecy: It produces session keys that remain secure even when the password is later disclosed.
2. 前向保密：它产生会话密钥，即使密码后来被泄露，会话密钥仍然是安全的。
3. Known-key security: It prevents a disclosed session key from affecting the security of other sessions.
3. 已知密钥安全性：它防止公开的会话密钥影响其他会话的安全性。
4. Online dictionary attack resistance: It limits an active attacker to test only one password per protocol execution.
4. 在线字典攻击抵抗：它限制主动攻击者在每次协议执行时仅测试一个密码。
First, a PAKE protocol must resist offline dictionary attacks. A password is inherently weak. Typically, it has only about 20-30 bits entropy. This level of security is subject to exhaustive search. Therefore, in the PAKE protocol, the communication must not reveal any data that allows an attacker to learn the password through offline exhaustive search.
首先，PAKE协议必须抵抗脱机字典攻击。密码本身就很弱。通常，它只有大约20-30位的熵。此级别的安全性需要进行彻底搜索。因此，在PAKE协议中，通信不得泄露任何数据，使攻击者能够通过离线穷举搜索了解密码。
Second, a PAKE protocol must provide forward secrecy. The key exchange is authenticated based on a shared password. However, there is no guarantee on the long-term secrecy of the password. A secure PAKE scheme shall protect past session keys even when the password is later disclosed. This property also implies that if an attacker knows the password but only passively observes the key exchange, he cannot learn the session key.
第二，PAKE协议必须提供前向保密性。密钥交换基于共享密码进行身份验证。但是，无法保证密码的长期保密性。安全PAKE方案应保护过去的会话密钥，即使密码后来被披露。此属性还意味着，如果攻击者知道密码，但只是被动地观察密钥交换，则他无法学习会话密钥。
Third, a PAKE protocol must provide known key security. A session key lasts throughout the session. An exposed session key must not cause any global impact on the system, affecting the security of other sessions.
第三，PAKE协议必须提供已知的密钥安全性。会话密钥在整个会话中都有效。公开的会话密钥不得对系统造成任何全局影响，从而影响其他会话的安全性。
Finally, a PAKE protocol must resist online dictionary attacks. If the attacker is directly engaging in the key exchange, there is no way to prevent such an attacker trying a random guess of the password. However, a secure PAKE scheme should minimize the effect of the online attack. In the best case, the attacker can only guess exactly one password per impersonation attempt. Consecutively failed attempts can be easily detected, and the subsequent attempts shall be thwarted accordingly. It is recommended that the false authentication counter be handled in such a way that any error (which causes the session to fail during the key exchange or key confirmation) leads to incrementing the false authentication counter.
最后，PAKE协议必须抵抗在线字典攻击。如果攻击者直接参与密钥交换，则无法阻止此类攻击者尝试随机猜测密码。然而，一个安全的PAKE方案应该最小化在线攻击的影响。在最好的情况下，攻击者每次模拟尝试只能猜测一个密码。连续失败的尝试很容易被检测到，随后的尝试应相应地被挫败。建议以这样的方式处理假身份验证计数器：任何错误（导致会话在密钥交换或密钥确认期间失败）都会导致假身份验证计数器增加。
It has been proven in [HR10] that J-PAKE satisfies all of the four requirements based on the assumptions that the Decisional Diffie-Hellman problem is intractable and the underlying Schnorr NIZK proof is secure. An independent study that proves security of J-PAKE in a model with algebraic adversaries and random oracles can be found in [ABM15]. By comparison, it has been known that EKE has the problem of leaking partial information about the password to a passive attacker, hence not satisfying the first requirement [Jas96]. For SPEKE and SRP-6, an attacker may be able to test more than one password in one online dictionary attack (see [Zha04] and [Hao10]), hence they do not satisfy the fourth requirement in the strict theoretical sense. Furthermore, SPEKE is found vulnerable to an impersonation attack and a key-malleability attack [HS14]. These two attacks affect the SPEKE protocol specified in Jablon's original 1996 paper [Jab96] as well in the D26 draft of IEEE P1363.2 and the ISO/ IEC 11770-4:2006 standard. As a result, the specification of SPEKE in ISO/IEC 11770-4:2006 has been revised to address the identified problems.
[HR10]中已经证明，J-PAKE满足所有四项要求，前提是决策Diffie-Hellman问题难以解决，且基础Schnorr-NIZK证明是安全的。[ABM15]中有一项独立研究证明了J-PAKE在具有代数对手和随机预言者的模型中的安全性。相比之下，众所周知EKE存在向被动攻击者泄露部分密码信息的问题，因此不满足第一个要求[Jas96]。对于SPEKE和SRP-6，攻击者可能能够在一次在线字典攻击中测试多个密码（请参见[Zha04]和[Hao10]），因此从严格的理论意义上讲，它们不满足第四个要求。此外，SPEKE容易受到模仿攻击和关键可塑性攻击[HS14]。这两次攻击影响了Jablon 1996年原始论文[Jab96]以及IEEE P1363.2 D26草案和ISO/IEC 11770-4:2006标准中规定的SPEKE协议。因此，ISO/IEC 11770-4:2006中的SPEKE规范已修订，以解决已识别的问题。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[ABM15] Abdalla, M., Benhamouda, F., and P. MacKenzie, "Security of the J-PAKE Password-Authenticated Key Exchange Protocol", 2015 IEEE Symposium on Security and Privacy, DOI 10.1109/sp.2015.41, May 2015.
[ABM15]Abdalla，M.，Benhamouda，F.，和P.MacKenzie，“J-PAKE密码认证密钥交换协议的安全性”，2015年IEEE安全与隐私研讨会，DOI 10.1109/sp.2015.412015年5月。
[BM92] Bellovin, S. and M. Merrit, "Encrypted Key Exchange: Password-based Protocols Secure against Dictionary Attacks", IEEE Symposium on Security and Privacy, DOI 10.1109/risp.1992.213269, May 1992.
[BM92]Bellovin，S.和M.Merrit，“加密密钥交换：基于密码的协议防止字典攻击”，IEEE安全和隐私研讨会，DOI 10.1109/risp.1992.213269，1992年5月。
[HR08] Hao, F. and P. Ryan, "Password Authenticated Key Exchange by Juggling", Lecture Notes in Computer Science, pp. 159-171, from 16th Security Protocols Workshop (SPW '08), DOI 10.1007/978-3-642-22137-8_23, 2011.
[HR08]Hao，F.和P.Ryan，“通过变戏法进行密码验证的密钥交换”，《计算机科学》课堂讲稿，第159-171页，摘自第16届安全协议研讨会（SPW'08），DOI 10.1007/978-3-642-22137-8_23，2011年。
[HR10] Hao, F. and P. Ryan, "J-PAKE: Authenticated Key Exchange Without PKI", Transactions on Computational Science XI, pp. 192-206, DOI 10.1007/978-3-642-17697-5_10, 2010.
[H10]郝，F和P. Ryan，“J-PAKE：认证密钥交换，没有PKI”，计算科学席，第192-206页，DOI 101007/97 83-62-176975Y10，2010。
[HS14] Hao, F. and S. Shahandashti, "The SPEKE Protocol Revisited", Security Standardisation Research, pp. 26-38, DOI 10.1007/978-3-319-14054-4_2, December 2014.
[HS14]Hao，F.和S.Shahandashti，“重新审视SPEKE协议”，安全标准化研究，第26-38页，DOI 10.1007/978-3-319-14054-4è，2014年12月。
[Jab96] Jablon, D., "Strong Password-Only Authenticated Key Exchange", ACM SIGCOMM Computer Communication Review, Vol. 26, pp. 5-26, DOI 10.1145/242896.242897, October 1996.
[Jab96]Jablon，D.，“仅强密码认证密钥交换”，ACM SIGCOMM计算机通信评论，第26卷，第5-26页，DOI 10.1145/242896.242897，1996年10月。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, DOI 10.17487/RFC5054, November 2007, <https://www.rfc-editor.org/info/rfc5054>.
[RFC5054]Taylor，D.，Wu，T.，Mavrogiannopoulos，N.，和T.Perrin，“使用安全远程密码（SRP）协议进行TLS身份验证”，RFC 5054，DOI 10.17487/RFC5054，2007年11月<https://www.rfc-editor.org/info/rfc5054>.
[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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero Knowledge Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, <https://www.rfc-editor.org/info/rfc8235>.
[RFC8235]Hao，F.，Ed.“Schnorr非交互式零知识证明”，RFC 8235，DOI 10.17487/RFC8235，2017年9月<https://www.rfc-editor.org/info/rfc8235>.
[SEC1] "Standards for Efficient Cryptography. SEC 1: Elliptic Curve Cryptography", SECG SEC1-v2, May 2009, <http://www.secg.org/sec1-v2.pdf>.
[SEC1]“高效密码标准。第1节：椭圆曲线密码术”，SECG SEC1-v2，2009年5月<http://www.secg.org/sec1-v2.pdf>.
[Stinson06] Stinson, D., "Cryptography: Theory and Practice", 3rd Edition, CRC, 2006.
[Stinson06]Stinson，D.，“密码学：理论与实践”，第三版，CRC，2006年。
[Wu98] Wu, T., "The Secure Remote Password Protocol", Internet Society Symposium on Network and Distributed System Security, March 1998.
[Wu98]Wu，T.，“安全远程密码协议”，互联网协会网络和分布式系统安全研讨会，1998年3月。
[AP05] Abdalla, M. and D. Pointcheval, "Simple Password-Based Encrypted Key Exchange Protocols", Topics in Cryptology CT-RSA, DOI 10.1007/978-3-540-30574-3_14, 2005.
[AP05]Abdalla，M.和D.Pointcheval，“基于简单密码的加密密钥交换协议”，密码学CT-RSA中的主题，DOI 10.1007/978-3-540-30574-3収，2005年。
[BJS07] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication 800-56A, March 2007, <http://csrc.nist.gov/publications/nistpubs/800-56A/ SP800-56A_Revision1_Mar08-2007.pdf>.
[BJS07]Barker，E.，Johnson，D.，和M.Smid，“使用离散对数加密的成对密钥建立方案的建议（修订版）”，NIST特别出版物800-56A，2007年3月<http://csrc.nist.gov/publications/nistpubs/800-56A/ SP800-56A_修订1_Mar08-2007.pdf>。
[BOINC] BOINC, "Index of /android-boinc/libssl/crypto/jpake", February 2011, <http://boinc.berkeley.edu/ android-boinc/libssl/crypto/jpake/>.
[BOINC]BOINC，“android/BOINC/libssl/crypto/jpake索引”，2011年2月<http://boinc.berkeley.edu/ android boinc/libssl/crypto/jpake/>。
[BOUNCY] Bouncy Castle Cryptography Library, "org.bouncycastle.crypto.agreement.jpake (Bouncy Castle Library 1.57 API Specification)", May 2017, <https://www.bouncycastle.org/docs/docs1.5on/org/ bouncycastle/crypto/agreement/jpake/package-summary.html>.
[BOUNCY]BOUNCY Castle加密库，“org.BOUNCY Castle.crypto.agreement.jpake（BOUNCY Castle Library 1.57 API规范）”，2017年5月<https://www.bouncycastle.org/docs/docs1.5on/org/ bouncycastle/crypto/agreement/jpake/package summary.html>。
[FIPS186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[FIPS186-4]国家标准与技术研究所，“数字签名标准（DSS）”，FIPS PUB 186-4，DOI 10.6028/NIST.FIPS.186-42013年7月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>。
[Hao10] Hao, F., "On Small Subgroup Non-Confinement Attacks", IEEE Conference on Computer and Information Technology, DOI 10.1109/CIT.2010.187, 2010.
[Hao10]Hao，F.，“关于小分组非限制攻击”，IEEE计算机和信息技术会议，DOI 10.1109/CIT.2010.1872010。
[ISO.11770-4] ISO/IEC, "Information technology -- Security techniques -- Key management -- Part 4: Mechanisms based on weak secrets", (under development), July 2017, <https://www.iso.org/standard/67933.html>.
[ISO.11770-4]ISO/IEC，“信息技术——安全技术——密钥管理——第4部分：基于弱机密的机制”，（正在开发），2017年7月<https://www.iso.org/standard/67933.html>.
[Jas96] Jaspan, B., "Dual-Workfactor Encrypted Key Exchange: Efficiently Preventing Password Chaining and Dictionary Attacks", USENIX Symposium on Security, July 1996.
[Jas96]Jaspan，B.“双工作因素加密密钥交换：有效防止密码链接和字典攻击”，USENIX安全研讨会，1996年7月。
[MOZILLA] Mozilla Wiki, "Services/KeyExchange", August 2011, <https://wiki.mozilla.org/index.php?title=Services/ KeyExchange&oldid=343704>.
[MOZILLA]MOZILLA Wiki，“服务/密钥交换”，2011年8月<https://wiki.mozilla.org/index.php?title=Services/ 密钥交换&oldid=343704>。
[MOZILLA_NSS] Mozilla Central, "jpake.c - DXR", August 2016, <https://dxr.mozilla.org/mozilla-central/source/ security/nss/lib/freebl/jpake.c>.
[MOZILLA_NSS]MOZILLA Central，“jpake.c-DXR”，2016年8月<https://dxr.mozilla.org/mozilla-central/source/ security/nss/lib/freebl/jpake.c>。
[PALEMOON] Moonchild Productions, "Pale Moon Sync", <https://www.palemoon.org/sync/>.
[PALEMOON]月亮儿童制作，“苍白月亮同步”<https://www.palemoon.org/sync/>.
[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, <https://www.rfc-editor.org/info/rfc4419>.
[RFC4419]Friedl，M.，Provos，N.，和W.Simpson，“用于安全外壳（SSH）传输层协议的Diffie-Hellman组交换”，RFC 4419，DOI 10.17487/RFC4419，2006年3月<https://www.rfc-editor.org/info/rfc4419>.
[SOAA15] Smyshlyaev, S., Oshkin, I., Alekseev, E., and L. Ahmetzyanova, "On the Security of One Password Authenticated Key Exchange Protocol", 2015, <http://eprint.iacr.org/2015/1237.pdf>.
[SOAA15]Smyshlyaev，S.，Oshkin，I.，Alekseev，E.，和L.Ahmetzyanova，“关于一个密码认证密钥交换协议的安全性”，2015年<http://eprint.iacr.org/2015/1237.pdf>.
[THREAD] Thread, "Thread Commissioning", White Paper, July 2015, <https://portal.threadgroup.org/DesktopModules/ Inventures_Document/FileDownload.aspx?ContentID=658>.
【线程】线程，“线程调试”，白皮书，2015年7月<https://portal.threadgroup.org/DesktopModules/ Inventures\u Document/FileDownload.aspx？ContentID=658>。
[Zha04] Zhang, M., "Analysis of the SPEKE Password-Authenticated Key Exchange Protocol", IEEE Communications Letters, Vol. 8, pp. 63-65, DOI 10.1109/lcomm.2003.822506, January 2004.
[Zha04]Zhang，M.，“SPEKE密码认证密钥交换协议的分析”，《IEEE通信快报》，第8卷，第63-65页，DOI 10.1109/lcomm.2003.822506，2004年1月。
Acknowledgements
致谢
The editor would like to thank Dylan Clarke, Siamak Shahandashti, Robert Cragie, Stanislav Smyshlyaev, and Russ Housley for many useful comments. This work is supported by EPSRC First Grant (EP/J011541/1) and ERC Starting Grant (No. 306994).
编辑要感谢Dylan Clarke、Siamak Shahandashti、Robert Cragie、Stanislav Smyshlyaev和Russ Housley的许多有用的评论。这项工作得到了EPSRC第一批赠款（EP/J011541/1）和ERC启动赠款（编号306994）的支持。
Author's Address
作者地址
Feng Hao (editor) Newcastle University (UK) Urban Sciences Building, School of Computing, Newcastle University Newcastle Upon Tyne United Kingdom
冯浩（编辑）纽卡斯尔大学（英国）计算学院城市科学大楼纽卡斯尔大学英国泰恩河畔纽卡斯尔
Phone: +44 (0)191-208-6384
Email: feng.hao@ncl.ac.uk
Phone: +44 (0)191-208-6384
Email: feng.hao@ncl.ac.uk