Independent Submission D. Harkins, Ed.
Request for Comments: 8492 HP Enterprise
Category: Informational February 2019
ISSN: 2070-1721
Independent Submission D. Harkins, Ed.
Request for Comments: 8492 HP Enterprise
Category: Informational February 2019
ISSN: 2070-1721
Secure Password Ciphersuites for Transport Layer Security (TLS)
用于传输层安全（TLS）的安全密码密码套件
Abstract
摘要
This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificateless, secure authentication using only a simple, low-entropy password. The exchange is called "TLS-PWD". The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to offline dictionary attacks.
此备忘录为传输层安全（TLS）协议定义了几个新的密码套件，以支持仅使用简单、低熵密码的无证书安全身份验证。该交换称为“TLS-PWD”。这些密码套件都基于一个名为“dragonfly”的身份验证和密钥交换协议，该协议能够抵抗离线字典攻击。
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.
这是对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 https://www.rfc-editor.org/info/rfc8492.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8492.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction and Motivation .....................................3
1.1. The Case for Certificateless Authentication ................3
1.2. Resistance to Dictionary Attacks ...........................3
2. Key Words .......................................................4
3. Notation and Background .........................................4
3.1. Notation ...................................................4
3.2. Discrete Logarithm Cryptography ............................5
3.2.1. Elliptic Curve Cryptography .........................5
3.2.2. Finite Field Cryptography ...........................7
3.3. Instantiating the Random Function ..........................8
3.4. Passwords ..................................................8
3.5. Assumptions ................................................9
4. Specification of the TLS-PWD Handshake .........................10
4.1. TLS-PWD Pre-TLS 1.3 .......................................10
4.2. TLS-PWD in TLS 1.3 ........................................11
4.3. Protecting the Username ...................................11
4.3.1. Construction of a Protected Username ...............12
4.3.2. Recovery of a Protected Username ...................13
4.4. Fixing the Password Element ...............................14
4.4.1. Computing an ECC Password Element ..................16
4.4.2. Computing an FFC Password Element ..................18
4.4.3. Password Naming ....................................19
4.4.4. Generating TLS-PWD Commit ..........................20
4.5. Changes to Handshake Message Contents .....................20
4.5.1. Pre-1.3 TLS ........................................20
4.5.1.1. ClientHello Changes .......................20
4.5.1.2. ServerKeyExchange Changes .................21
4.5.1.3. ClientKeyExchange Changes .................23
4.5.2. TLS 1.3 ............................................24
4.5.2.1. TLS 1.3 KeyShare ..........................24
4.5.2.2. ClientHello Changes .......................24
4.5.2.3. ServerHello Changes .......................25
4.5.2.4. HelloRetryRequest Changes .................25
4.6. Computing the Shared Secret ...............................26
5. Ciphersuite Definition .........................................26
6. IANA Considerations ............................................27
7. Security Considerations ........................................27
8. Human Rights Considerations ....................................30
9. Implementation Considerations ..................................31
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................33
Appendix A. Example Exchange ......................................35
Acknowledgements ..................................................40
Author's Address ..................................................40
1. Introduction and Motivation .....................................3
1.1. The Case for Certificateless Authentication ................3
1.2. Resistance to Dictionary Attacks ...........................3
2. Key Words .......................................................4
3. Notation and Background .........................................4
3.1. Notation ...................................................4
3.2. Discrete Logarithm Cryptography ............................5
3.2.1. Elliptic Curve Cryptography .........................5
3.2.2. Finite Field Cryptography ...........................7
3.3. Instantiating the Random Function ..........................8
3.4. Passwords ..................................................8
3.5. Assumptions ................................................9
4. Specification of the TLS-PWD Handshake .........................10
4.1. TLS-PWD Pre-TLS 1.3 .......................................10
4.2. TLS-PWD in TLS 1.3 ........................................11
4.3. Protecting the Username ...................................11
4.3.1. Construction of a Protected Username ...............12
4.3.2. Recovery of a Protected Username ...................13
4.4. Fixing the Password Element ...............................14
4.4.1. Computing an ECC Password Element ..................16
4.4.2. Computing an FFC Password Element ..................18
4.4.3. Password Naming ....................................19
4.4.4. Generating TLS-PWD Commit ..........................20
4.5. Changes to Handshake Message Contents .....................20
4.5.1. Pre-1.3 TLS ........................................20
4.5.1.1. ClientHello Changes .......................20
4.5.1.2. ServerKeyExchange Changes .................21
4.5.1.3. ClientKeyExchange Changes .................23
4.5.2. TLS 1.3 ............................................24
4.5.2.1. TLS 1.3 KeyShare ..........................24
4.5.2.2. ClientHello Changes .......................24
4.5.2.3. ServerHello Changes .......................25
4.5.2.4. HelloRetryRequest Changes .................25
4.6. Computing the Shared Secret ...............................26
5. Ciphersuite Definition .........................................26
6. IANA Considerations ............................................27
7. Security Considerations ........................................27
8. Human Rights Considerations ....................................30
9. Implementation Considerations ..................................31
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................33
Appendix A. Example Exchange ......................................35
Acknowledgements ..................................................40
Author's Address ..................................................40
Transport Layer Security (TLS) usually uses public key certificates for authentication [RFC5246] [RFC8446]. This is problematic in some cases:
传输层安全性（TLS）通常使用公钥证书进行身份验证[RFC5246][RFC8446]。在某些情况下，这是有问题的：
o Frequently, TLS [RFC5246] is used in devices owned, operated, and provisioned by people who lack competency to properly use certificates and merely want to establish a secure connection using a more natural credential like a simple password. The proliferation of deployments that use a self-signed server certificate in TLS [RFC5246] followed by a basic password exchange over the unauthenticated channel underscores this case.
o 通常，TLS[RFC5246]用于由缺乏适当使用证书能力的人员拥有、操作和供应的设备，这些人员只想使用更自然的凭证（如简单密码）建立安全连接。在TLS[RFC5246]中使用自签名服务器证书，然后通过未经身份验证的通道进行基本密码交换的部署激增，突出了这种情况。
o The alternatives to TLS-PWD for employing certificateless TLS authentication -- using pre-shared keys in an exchange that is susceptible to dictionary attacks or using a Secure Remote Password (SRP) exchange that requires users to, a priori, be fixed to a specific Finite Field Cryptography (FFC) group for all subsequent connections -- are not acceptable for modern applications that require both security and cryptographic agility.
o TLS-PWD采用无证书TLS身份验证的替代方案——在易受字典攻击的交换中使用预共享密钥，或使用安全远程密码（SRP）交换，该交换要求用户事先固定到特定的有限域加密（FFC）用于所有后续连接的组—对于既需要安全性又需要加密灵活性的现代应用程序是不可接受的。
o A password is a more natural credential than a certificate (from early childhood, people learn the semantics of a shared secret), so a password-based TLS ciphersuite can be used to protect an HTTP-based certificate enrollment scheme like Enrollment over Secure Transport (EST) [RFC7030] to parlay a simple password into a certificate for subsequent use with any certificate-based authentication protocol. This addresses a significant "chicken-and-egg" dilemma found with certificate-only use of [RFC5246].
o 密码是比证书更自然的凭证（从幼儿时代起，人们就学会了共享秘密的语义），因此基于密码的TLS密码套件可用于保护基于HTTP的证书注册方案，如通过安全传输注册（EST）[RFC7030]将简单密码保存到证书中，以便以后与任何基于证书的身份验证协议一起使用。这解决了[RFC5246]仅凭证书使用时出现的一个重大“鸡和蛋”困境。
o Some PIN-code readers will transfer the entered PIN to a smart card in cleartext. Assuming a hostile environment, this is a bad practice. A password-based TLS ciphersuite can enable the establishment of an authenticated connection between reader and card based on the PIN.
o 一些PIN码阅读器会将输入的PIN以明文形式传输到智能卡。假设环境恶劣，这是一种不好的做法。基于密码的TLS密码套件可以基于PIN在读卡器和卡之间建立经过身份验证的连接。
It is a common misconception that a protocol that authenticates with a shared and secret credential is resistant to dictionary attacks if the credential is assumed to be an N-bit uniformly random secret, where N is sufficiently large. The concept of resistance to dictionary attacks really has nothing to do with whether that secret
一种常见的误解是，如果使用共享和机密凭据进行身份验证的协议被假定为N位一致随机密钥（其中N足够大），则该协议可以抵抗字典攻击。抵抗字典攻击的概念实际上与这个秘密是否存在无关
can be found in a standard collection of a language's defined words (i.e., a dictionary). It has to do with how an adversary gains an advantage in attacking the protocol.
可以在语言定义词的标准集合（即词典）中找到。这与对手如何在攻击协议时获得优势有关。
For a protocol to be resistant to dictionary attacks, any advantage an adversary can gain must be a function of the amount of interactions she makes with an honest protocol participant and not a function of the amount of computation she uses. This means that the adversary will not be able to obtain any information about the password except whether a single guess from a single protocol run that she took part in is correct or incorrect.
对于抵抗字典攻击的协议，对手可以获得的任何优势都必须是其与诚实协议参与者进行交互的数量的函数，而不是其使用的计算量的函数。这意味着对手将无法获得有关密码的任何信息，除非她参与的单个协议运行中的单个猜测是正确的还是不正确的。
It is assumed that the attacker has access to a pool of data from which the secret was drawn -- it could be all numbers between 1 and 2^N; it could be all defined words in a dictionary. The key is that the attacker cannot do an attack and then go offline and enumerate through the pool trying potential secrets (computation) to see if one is correct. She must do an active attack for each secret she wishes to try (interaction), and the only information she can glean from that attack is whether the secret used with that particular attack is correct or not.
假设攻击者可以访问提取秘密的数据池——可能是1到2^N之间的所有数字；它可以是字典中定义的所有单词。关键是攻击者不能进行攻击，然后脱机并枚举池中的潜在秘密（计算），以查看其中一个是否正确。她必须对她希望尝试的每个秘密（交互）进行主动攻击，她从攻击中收集到的唯一信息是与该特定攻击一起使用的秘密是否正确。
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 memo:
本备忘录中使用了以下符号：
password a secret -- and potentially low-entropy -- word, phrase, code, or key used as a credential for authentication. The password is shared between the TLS client and TLS server.
密码作为身份验证凭证使用的秘密（可能是低熵）字、短语、代码或密钥。密码在TLS客户端和TLS服务器之间共享。
y = H(x) a binary string of arbitrary length, x, is given to a function H, which produces a fixed-length output, y.
y=H（x）将任意长度的二进制字符串x赋给函数H，该函数产生固定长度的输出y。
a | b denotes concatenation of string "a" with string "b".
a | b表示字符串“a”与字符串“b”的串联。
[a]b indicates a string consisting of the single bit "a" repeated "b" times.
[a] b表示由单个位“a”重复“b”次组成的字符串。
x mod y indicates the remainder of division of x by y. The result will be between 0 and y.
x mod y表示x除以y的余数。结果将介于0和y之间。
len(x) indicates the length in bits of the string "x".
len（x）表示字符串“x”的位长度。
lgr(a, b) takes "a" and a prime, b, and returns the Legendre symbol (a/b).
lgr（a，b）接受“a”和素数b，并返回勒让德符号（a/b）。
LSB(x) returns the least-significant bit of the bitstring "x".
LSB（x）返回位字符串“x”的最低有效位。
G.x indicates the x-coordinate of a point, G, on an elliptic curve.
G.x表示椭圆曲线上点G的x坐标。
The ciphersuites defined in this memo use discrete logarithm cryptography (see [SP800-56A]) to produce an authenticated and shared secret value that is an Element in a group defined by a set of domain parameters. The domain parameters can be based on either FFC or Elliptic Curve Cryptography (ECC).
本备忘录中定义的密码套件使用离散对数加密（请参见[SP800-56A]）生成经过身份验证的共享秘密值，该值是由一组域参数定义的组中的一个元素。域参数可以基于FFC或椭圆曲线密码（ECC）。
Elements in a group -- either an FFC or ECC group -- are indicated using uppercase, while scalar values are indicated using lowercase.
组中的元素（FFC或ECC组）使用大写字母表示，而标量值使用小写字母表示。
The authenticated key exchange defined in this memo uses fundamental algorithms of elliptic curves defined over GF(p) as described in [RFC6090]. Ciphersuites defined in this memo SHALL only use ECC curves based on the Weierstrass equation y^2 = x^3 + a*x + b.
本备忘录中定义的认证密钥交换使用[RFC6090]中所述的GF（p）上定义的椭圆曲线的基本算法。本备忘录中定义的密码套件只能使用基于Weierstrass方程y^2=x^3+a*x+b的ECC曲线。
Domain parameters for the ECC groups used by this memo are:
此备忘录使用的ECC组的域参数为：
o A prime, p, determining a prime field GF(p). The cryptographic group will be a subgroup of the full elliptic curve group, which consists of points on an elliptic curve -- Elements from GF(p) that satisfy the curve's equation -- together with the "point at infinity" that serves as the identity Element.
o 素数，p，决定素数域GF（p）。密码组将是完整椭圆曲线组的一个子组，它由椭圆曲线上的点组成——GF（p）中满足曲线方程的元素——以及作为身份元素的“无穷远点”。
o Elements a and b from GF(p) that define the curve's equation. The point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only if (y^2 - x^3 - a*x - b) mod p equals zero (0).
o 定义曲线方程的GF（p）中的元素a和b。GF（p）xgf（p）中的点（x，y）在椭圆曲线上当且仅当（y^2-x^3-a*x-b）mod p等于零（0）。
o A point, G, on the elliptic curve, which serves as a generator for the ECC group. G is chosen such that its order, with respect to elliptic curve addition, is a sufficiently large prime.
o 椭圆曲线上的一个点G，用作ECC组的生成器。选择G，使其相对于椭圆曲线加法的阶数是一个足够大的素数。
o A prime, q, which is the order of G and thus is also the size of the cryptographic subgroup that is generated by G.
o 素数q，是G的阶数，因此也是由G生成的加密子群的大小。
o A co-factor, f, defined by the requirement that the size of the full elliptic curve group (including the "point at infinity") be the product of f and q.
o 一个辅因子f，由完整椭圆曲线组（包括“无穷远点”）的大小为f和q的乘积的要求定义。
This memo uses the following ECC functions:
本备忘录使用以下ECC功能：
o Z = elem-op(X, Y) = X + Y: two points on the curve, X and Y, are summed to produce another point on the curve, Z. This is the group operation for ECC groups.
o Z=elem op（X，Y）=X+Y：曲线上的两个点X和Y相加，生成曲线上的另一个点Z。这是ECC组的分组操作。
o Z = scalar-op(x, Y) = x * Y: an integer scalar, x, acts on a point on the curve, Y, via repetitive addition (Y is added to itself x times), to produce another ECC Element, Z.
o Z=标量op（x，Y）=x*Y：整数标量x通过重复加法作用于曲线Y上的一点（Y自身加x次），以产生另一个ECC元素Z。
o Y = inverse(X): a point on the curve, X, has an inverse, Y, which is also a point on the curve, when their sum is the "point at infinity" (the identity for elliptic curve addition). In other words, R + inverse(R) = "0".
o Y=逆（X）：曲线上的点X有一个逆，Y也是曲线上的点，当它们的和是“无穷远点”（椭圆曲线加法的恒等式）时。换句话说，R+逆（R）=“0”。
o z = F(X): the x-coordinate of a point (x, y) on the curve is returned. This is a mapping function to convert a group Element into an integer.
o z=F（X）：返回曲线上点（X，y）的X坐标。这是一个映射函数，用于将组元素转换为整数。
Only ECC groups over GF(p) can be used with TLS-PWD. Characteristic-2 curves SHALL NOT be used by TLS-PWD. ECC groups over GF(2^m) SHALL NOT be used by TLS-PWD. In addition, ECC groups with a co-factor greater than one (1) SHALL NOT be used by TLS-PWD.
只有GF（p）上的ECC组才能与TLS-PWD一起使用。TLS-PWD不得使用特性-2曲线。TLS-PWD不得使用GF（2^m）以上的ECC组。此外，TLS-PWD不得使用系数大于一（1）的ECC组。
A composite (x, y) pair can be validated as a point on the elliptic curve by checking that 1) both coordinates x and y are greater than zero (0) and less than the prime defining the underlying field, 2) coordinates x and y satisfy the equation of the curve, and 3) they do not represent the "point at infinity". If any of those conditions are not true, the (x, y) pair is not a valid point on the curve.
通过检查1）坐标x和y均大于零（0）且小于定义基础场的素数，2）坐标x和y满足曲线方程，以及3）它们不表示“无穷远处的点”，可以将复合（x，y）对验证为椭圆曲线上的点。如果这些条件中的任何一个不正确，则（x，y）对不是曲线上的有效点。
A compliant implementation of TLS-PWD SHALL support group twenty-three (23) and SHOULD support group twenty-four (24) from the "TLS Supported Groups" registry; see [TLS_REG].
TLS-PWD的合规实施应支持第二十三（23）组，并应支持“TLS支持组”登记册中的第二十四（24）组；参见[TLS_REG]。
Domain parameters for the FFC groups used by this memo are:
此备忘录使用的FFC组的域参数为：
o A prime, p, determining a prime field GF(p) (i.e., the integers modulo p). The FFC group will be a subgroup of GF(p)* (i.e., the multiplicative group of non-zero Elements in GF(p)).
o 素数，p，确定素数域GF（p）（即模p的整数）。FFC群将是GF（p）*（即GF（p）中非零元素的乘法群）的子群。
o An Element, G, in GF(p)*, which serves as a generator for the FFC group. G is chosen such that its multiplicative order is a sufficiently large prime divisor of ((p - 1)/2).
o GF（p）*中的一个元素G，用作FFC组的生成器。选择G，使其乘法阶为（（p-1）/2）的足够大的素因子。
o A prime, q, which is the multiplicative order of G and thus is also the size of the cryptographic subgroup of GF(p)* that is generated by G.
o 素数q，是G的乘法阶，因此也是G生成的GF（p）*的密码子群的大小。
This memo uses the following FFC functions:
本备忘录使用以下FFC功能：
o Z = elem-op(X, Y) = (X * Y) mod p: two FFC Elements, X and Y, are multiplied modulo the prime, p, to produce another FFC Element, Z. This is the group operation for FFC groups.
o Z=elem op（X，Y）=（X*Y）mod p：将两个FFC元素X和Y乘以素数p，以生成另一个FFC元素Z。这是FFC组的分组操作。
o Z = scalar-op(x, Y) = Y^x mod p: an integer scalar, x, acts on an FFC group Element, Y, via exponentiation modulo the prime, p, to produce another FFC Element, Z.
o Z=scalar op（x，Y）=Y^x mod p：整数标量x作用于FFC组元素Y，通过对素数p求幂，生成另一个FFC元素Z。
o Y = inverse(X): a group Element, X, has an inverse, Y, when the product of the Element and its inverse modulo the prime equals one (1). In other words, (X * inverse(X)) mod p = 1.
o Y=逆（X）：当元素及其逆模素数的乘积等于一（1）时，群元素X具有逆（Y）。换句话说，（X*逆（X））模p=1。
o z = F(X): is the identity function, since an Element in an FFC group is already an integer. It is included here for consistency in the specification.
o z=F（X）：是标识函数，因为FFC组中的元素已经是整数。为了在规范中保持一致性，此处将其包括在内。
Many FFC groups used in IETF protocols are based on safe primes and do not define an order (q). For these groups, the order (q) used in this memo shall be the prime of the group minus one divided by two -- (p - 1)/2.
IETF协议中使用的许多FFC组基于安全素数，并且不定义顺序（q）。对于这些组，本备忘录中使用的顺序（q）应为组的素数减去1除以2——（p-1）/2。
An integer can be validated as being an Element in an FFC group by checking that 1) it is between one (1) and the prime, p, exclusive and 2) modular exponentiation of the integer by the group order, q, equals one (1). If either of these conditions is not true, the integer is not an Element in the group.
通过检查1）整数是否在一（1）和素数p（互斥）之间，以及2）整数按组顺序q等于一（1）的模幂，可以验证整数是否为FFC组中的元素。如果这两个条件中的任何一个不为真，则整数不是组中的元素。
A compliant implementation of TLS-PWD SHOULD support group two hundred fifty-six (256) and group two hundred fifty-eight (258) from the "TLS Supported Groups" registry on [TLS_REG].
TLS-PWD的合规实施应支持[TLS_REG]上“TLS支持的组”注册表中的二百五十六（256）组和二百五十八（258）组。
The protocol described in this memo uses a random function, H, which is modeled as a "random oracle". At first glance, one may view this as a hash function. As noted in [RANDOR], though, hash functions are too structured to be used directly as a random oracle. But they can be used to instantiate the random oracle.
本备忘录中描述的协议使用了一个随机函数H，它被建模为“随机预言”。乍一看，人们可能认为这是一个散列函数。不过，正如[RANDOR]中所指出的，哈希函数的结构过于结构化，无法直接用作随机预言。但它们可以用来实例化随机预言。
The random function, H, in this memo is instantiated by using the hash algorithm defined by the particular TLS-PWD ciphersuite in Hashed Message Authentication Code (HMAC) mode with a key whose length is equal to the block size of the hash algorithm and whose value is zero. For example, if the ciphersuite is TLS_ECCPWD_WITH_AES_128_GCM_SHA256, then H will be instantiated with SHA256 as:
本备忘录中的随机函数H通过使用特定TLS-PWD密码套件在哈希消息认证码（HMAC）模式下定义的哈希算法进行实例化，该算法的密钥长度等于哈希算法的块大小，其值为零。例如，如果密码套件是TLS_ECCPWD_WITH_AES_128_GCM_SHA256，则H将被SHA256实例化为：
H(x) = HMAC-SHA256([0]32, x)
H(x) = HMAC-SHA256([0]32, x)
The authenticated key exchange used in TLS-PWD requires each side to have a common view of a shared credential. To protect the server's database of stored passwords, a password MAY be salted. When [RFC5246] or earlier is used, the password SHALL be salted. When [RFC8446] is used, a password MAY be stored with a salt or without. The password, username, and, optionally, the salt can create an irreversible digest called the "base", which is used in the authenticated key exchange.
TLS-PWD中使用的经过身份验证的密钥交换要求各方拥有共享凭证的公共视图。为了保护服务器存储的密码数据库，可以对密码进行加密。当使用[RFC5246]或更早版本时，应添加密码。当使用[RFC8446]时，密码可以存储在盐中，也可以不存储。密码、用户名和salt（可选）可以创建一个称为“base”的不可逆摘要，用于经过身份验证的密钥交换。
The salting function is defined as:
盐析功能定义为：
base = HMAC-SHA256(salt, username | password)
base=HMAC-SHA256（salt，用户名|密码）
The unsalted function is defined as:
非盐功能定义为：
base = SHA256(username | password)
base=SHA256（用户名|密码）
The password used for generation of the base SHALL be represented as a UTF-8 encoded character string processed according to the rules of the OpaqueString profile of [RFC8265], and the salt SHALL be a 32-octet random number. The server SHALL store a tuple of the form:
用于生成基的密码应表示为UTF-8编码字符串，根据[RFC8265]的不透明字符串配置文件的规则进行处理，salt应为32个八位随机数。服务器应存储以下格式的元组：
{ username, base, salt }
{username，base，salt}
if the password is salted and:
如果密码是咸的，并且：
{ username, base }
{用户名，base}
if it is not. When password salting is being used, the client generates the base upon receiving the salt from the server; otherwise, it may store the base at the time the username and password are provisioned.
如果不是。当使用密码salt时，客户端从服务器接收salt后生成base；否则，它可能会在设置用户名和密码时存储基。
The security properties of the authenticated key exchange defined in this memo are based on a number of assumptions:
本备忘录中定义的经过身份验证的密钥交换的安全属性基于若干假设：
1. The random function, H, is a "random oracle" as defined in [RANDOR].
1. 随机函数H是[RANDOR]中定义的“随机预言”。
2. The discrete logarithm problem for the chosen group is hard. That is, given g, p, and y = g^x mod p, it is computationally infeasible to determine x. Similarly, for an ECC group given the curve definition, a generator G, and Y = x * G, it is computationally infeasible to determine x.
2. 所选组的离散对数问题很难解决。也就是说，给定g，p和y=g^x mod p，计算上不可能确定x。类似地，对于给定曲线定义的ECC组、生成器G和Y=x*G，确定x在计算上是不可行的。
3. Quality random numbers with sufficient entropy can be created. This may entail the use of specialized hardware. If such hardware is unavailable, a cryptographic mixing function (like a strong hash function) to distill entropy from multiple, uncorrelated sources of information and events may be needed. A very good discussion of this can be found in [RFC4086].
3. 可以创建具有足够熵的高质量随机数。这可能需要使用专用硬件。如果这样的硬件不可用，则可能需要一个加密混合函数（如强散列函数）来从多个不相关的信息源和事件中提取熵。[RFC4086]中对这一点进行了很好的讨论。
If the server supports username protection (see Section 4.3), it is assumed that the server has chosen a domain parameter set and generated a username-protection keypair. The chosen domain parameter set and public key are assumed to be conveyed to the client at the time the client's username and password were provisioned.
如果服务器支持用户名保护（参见第4.3节），则假定服务器已选择域参数集并生成用户名保护密钥对。假定所选域参数集和公钥在设置客户端的用户名和密码时传递给客户端。
The key exchange underlying TLS-PWD is the "dragonfly" password-authenticated key exchange (PAKE) as defined in [RFC7664].
TLS-PWD底层的密钥交换是[RFC7664]中定义的“蜻蜓”密码认证密钥交换（PAKE）。
The authenticated key exchange is accomplished by each side deriving a Password Element (PE) [RFC7664] in the chosen group, making a "commitment" to a single guess of the password using the PE, and generating a shared secret. The ability of each side to produce a valid finished message using a key derived from the shared secret allows each side to authenticates itself to the other side.
经过身份验证的密钥交换由各方在所选组中导出密码元素（PE）[RFC7664]，使用PE对密码的单个猜测作出“承诺”，并生成共享密钥来完成。每一方使用从共享秘密派生的密钥生成有效的完成消息的能力允许每一方向另一方验证自己。
The authenticated key exchange is dropped into the standard TLS message handshake by defining extensions to some of the messages.
通过定义对某些消息的扩展，已验证密钥交换被放入标准TLS消息握手中。
Client Server
-------- --------
Client Server
-------- --------
ClientHello (name) -------->
ClientHello (name) -------->
ServerHello
ServerKeyExchange (commit)
<-------- ServerHello Done
ServerHello
ServerKeyExchange (commit)
<-------- ServerHello Done
ClientKeyExchange (commit)
ChangeCipherSpec
Finished -------->
ClientKeyExchange (commit)
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
ChangeCipherSpec
<-------- Finished
Application Data <-------> Application Data
Application Data <-------> Application Data
Figure 1: Pre-TLS 1.3 TLS-PWD Handshake
图1:TLS前1.3 TLS-PWD握手
Client Server
-------- --------
ClientHello (name)
+ key_share (commit) -------->
ServerHello
+ key_share (commit)
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Client Server
-------- --------
ClientHello (name)
+ key_share (commit) -------->
ServerHello
+ key_share (commit)
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 2: TLS 1.3 TLS-PWD Handshake
图2:TLS 1.3 TLS-PWD握手
The client is required to identify herself to the server before the server can look up the appropriate client credential with which to perform the authenticated key exchange. This has negative privacy implications and opens up the client to tracking and increased monitoring. It is therefore useful for the client to be able to protect her username from passive monitors of the exchange and against active attack by a malicious server. TLS-PWD provides such a mechanism. Support for protected usernames is RECOMMENDED.
在服务器可以查找用于执行经过身份验证的密钥交换的适当客户端凭据之前，客户端需要向服务器标识自己。这会对隐私产生负面影响，并使客户端能够进行跟踪和加强监控。因此，对于客户端来说，能够保护其用户名免受exchange被动监视器的攻击以及恶意服务器的主动攻击是非常有用的。TLS-PWD提供了这样一种机制。建议支持受保护的用户名。
To enable username protection, a server chooses a domain parameter set and generates an ephemeral public/private keypair. This keypair SHALL only be used for username protection. For efficiency, the domain parameter set used for username protection MUST be based on ECC. Any ECC group that is appropriate for TLS-PWD (see Section 3.2.1) is suitable for this purpose, but for interoperability, prime256v1 (aka NIST's p256 curve) MUST be supported. The domain parameter set chosen for username protection is independent of the domain parameter set chosen for the underlying key exchange -- i.e., they need not be the same.
为了启用用户名保护，服务器选择域参数集并生成临时公钥/私钥对。此密钥对仅用于用户名保护。为了提高效率，用于用户名保护的域参数集必须基于ECC。适用于TLS-PWD的任何ECC组（见第3.2.1节）均适用于此目的，但为了实现互操作性，必须支持prime256v1（又名NIST的p256曲线）。为用户名保护选择的域参数集独立于为基础密钥交换选择的域参数集，即它们不必相同。
When the client's username and password are provisioned on the server, the chosen group and its public key are provisioned on the client. This is stored on the client along with the server-specific state (e.g., the hostname) it uses to initiate a TLS-PWD exchange. The server uses the same group and public key with all clients.
在服务器上设置客户端的用户名和密码时，将在客户端上设置所选组及其公钥。这与用于启动TLS-PWD交换的服务器特定状态（例如主机名）一起存储在客户机上。服务器对所有客户端使用相同的组和公钥。
To protect a username, the client and server perform a static-ephemeral Diffie-Hellman exchange. Since the y-coordinate is not necessary and eliminating it will reduce message size, compact representation (and therefore compact output; see [RFC6090]) is used
为了保护用户名，客户机和服务器执行静态短暂的Diffie-Hellman交换。由于y坐标是不必要的，消除它将减少消息大小，因此使用紧凑表示（因此紧凑输出；请参见[RFC6090]）
in the static-ephemeral Diffie-Hellman exchange. The result of the Diffie-Hellman exchange is passed to the HMAC-based Key Derivation Function (HKDF) [RFC5869] to create a key-encrypting key suitable for AES-SIV [RFC5297] (where "AES" stands for "Advanced Encryption Standard" and "SIV" stands for "Synthetic Initialization Vector") in its deterministic authenticated encryption mode. The length of the key-encrypting key (1) and the hash function to use with the HKDF depend on the length of the prime, p, of the group used to provide username protection:
在静态短暂的Diffie-Hellman交换中。Diffie-Hellman交换的结果被传递给基于HMAC的密钥派生函数（HKDF）[RFC5869]，以创建适用于AES-SIV[RFC5297]（其中“AES”代表“高级加密标准”，“SIV”代表“合成初始化向量”）的确定性认证加密模式的密钥加密密钥。密钥加密密钥（1）的长度和与HKDF一起使用的哈希函数取决于用于提供用户名保护的组的素数p的长度：
o SHA-256, SIV-128, l=256 bits: when len(p) <= 256
o SHA-256，SIV-128，l=256位：当len（p）<=256时
o SHA-384, SIV-192, l=384 bits: when 256 < len(p) <= 384
o SHA-384，SIV-192，l=384位：当256<len（p）<=384时
o SHA-512, SIV-256, l=512 bits: when len(p) > 384
o SHA-512，SIV-256，l=512位：当len（p）>384时
Prior to initiating a TLS-PWD exchange, the client chooses a random secret, c, such that 1 < c < (q - 1), where q is the order of the group from which the server's public key was generated, and it uses scalar-op() with the group's generator to create a public key, C. It uses scalar-op() with the server's public key and c to create a shared secret, and it derives a key-encrypting key, k, using the "saltless" mode of the HKDF [RFC5869]:
在启动TLS-PWD交换之前，客户机选择一个随机密钥c，这样1<c<（q-1），其中q是从中生成服务器公钥的组的顺序，它使用scalar-op（）和组的生成器来创建公钥c。它使用scalar-op（）和服务器的公钥以及c来创建共享密钥，它使用HKDF[RFC5869]的“无盐”模式导出密钥加密密钥k：
C = scalar-op(c, G)
C=标量op（C，G）
Z = scalar-op(c, S)
Z=标量op（c，S）
k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l)
k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l)
where NULL indicates the salt-free invocation and "" indicates an empty string (i.e., there is no "context" passed to the HKDF).
其中NULL表示无盐调用，而“”表示空字符串（即，没有传递给HKDF的“上下文”）。
The client's username SHALL be represented as a UTF-8 encoded character string processed according to the rules of the OpaqueString profile of [RFC8265]. The output of OpaqueString is then passed with the key, k, to SIV-encrypt with no Additional Authenticated Data (AAD) and no nonce, to produce an encrypted username, u:
客户的用户名应表示为UTF-8编码字符串，根据[RFC8265]的不透明字符串配置文件的规则进行处理。然后将OpaqueString的输出与密钥k一起传递给SIV encrypt，而不使用额外的身份验证数据（AAD）和nonce，以生成加密用户名u：
u = SIV-encrypt(k, username)
u=SIV加密（k，用户名）
Note: The format of the ciphertext output includes the authenticating SIV.
注意：密文输出的格式包括身份验证SIV。
The protected username SHALL be the concatenation of the x-coordinate of the client's public key, C, and the encrypted username, u. The length of the x-coordinate of C MUST be equal to the length of the group's prime, p, prepended with zeros, if necessary. The protected username is inserted into the extension_data field of the pwd_protect extension (see Section 4.4.3).
受保护的用户名应为客户端公钥C的x坐标和加密用户名u的串联。如有必要，C的x坐标长度必须等于组素数p的长度，p前面加零。受保护的用户名插入pwd_保护扩展的扩展_数据字段（见第4.4.3节）。
To ensure that the username remains confidential, the random secret, c, MUST be generated from a source of random entropy; see Section 3.5.
为了确保用户名保持机密，必须从随机熵源生成随机秘密c；见第3.5节。
The length of the ciphertext output from SIV, minus the synthetic initialization vector, will be equal to the length of the input plaintext -- in this case, the username. To further foil traffic analysis, it is RECOMMENDED that clients append a series of NULL bytes to their usernames prior to passing them to SIV-encrypt() such that the resulting padded length of the username is at least 128 octets.
SIV输出的密文长度减去合成初始化向量，将等于输入明文的长度——在本例中为用户名。为了进一步阻止流量分析，建议客户端在将一系列空字节传递给SIV-encrypt（）之前，先将它们附加到用户名上，这样用户名的填充长度至少为128个八位字节。
A server that receives a protected username needs to recover the client's username prior to performing the key exchange. To do so, the server computes the client's public key; completes the static-ephemeral Diffie-Hellman exchange; derives the key-encrypting key, k; and decrypts the username.
接收受保护用户名的服务器需要在执行密钥交换之前恢复客户端的用户名。为此，服务器计算客户端的公钥；完成静态瞬时Diffie-Hellman交换；导出密钥加密密钥k；并解密用户名。
The length of the x-coordinate of the client's public key is known (it is the length of the prime from the domain parameter set used to protect usernames) and can easily be separated from the ciphertext in the pwd_name extension in the ClientHello -- the first len(p) bits are the x-coordinate of the client's public key, and the remaining bits are the ciphertext.
客户机公钥的x坐标长度是已知的（它是用于保护用户名的域参数集中的素数长度），并且可以很容易地从ClientHello中pwd_名称扩展中的密文中分离出来——第一个len（p）位是客户机公钥的x坐标，剩下的是密文。
Since compressed representation is used by the client, the server MUST compute the y-coordinate of the client's public key by using the equation of the curve:
由于客户端使用压缩表示，服务器必须使用曲线方程计算客户端公钥的y坐标：
y^2 = x^3 + ax + b
y^2 = x^3 + ax + b
and solving for y. There are two solutions for y, but since compressed output is also being used, the selection is irrelevant. The server reconstructs the client's public value, C, from (x, y). If there is no solution for y or if (x, y) is not a valid point on the elliptic curve (see Section 3.2.1), the server MUST treat the ClientHello as if it did not have a password for a given username (see Section 4.5.1.1).
求解y。y有两种解决方案，但由于也使用了压缩输出，因此选择是不相关的。服务器从（x，y）重构客户机的公共值C。如果y没有解决方案，或者（x，y）不是椭圆曲线上的有效点（参见第3.2.1节），服务器必须将ClientHello视为没有给定用户名的密码（参见第4.5.1.1节）。
The server then uses scalar-op() with the reconstructed point C and the private key it uses for protected passwords, s, to generate a shared secret, and it derives a key-encrypting key, k, in the same manner as that described in Section 4.3.1.
然后，服务器使用scalar-op（）和重构点C及其用于受保护密码的私钥s生成共享密钥，并以与第4.3.1节所述相同的方式导出密钥加密密钥k。
Z = scalar-op(s, C)
Z=标量op（s，C）
k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l)
k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l)
The key, k, and the ciphertext portion of the pwd_name extension, u, are passed to SIV-decrypt with no AAD and no nonce, to produce the username:
密钥k和pwd_名称扩展名u的密文部分传递给SIV decrypt，不带AAD和nonce，以生成用户名：
username = SIV-decrypt(k, u)
用户名=SIV解密（k，u）
If SIV-decrypt returns the symbol FAIL indicating unsuccessful decryption and verification, the server MUST treat the ClientHello as if it did not have a password for a given username (see Section 4.5.1.1). If successful, the server has obtained the client's username and can process it as needed. Any NULL octets added by the client prior to encryption can be easily stripped off of the string that represents the username.
如果SIV decrypt返回表示解密和验证失败的符号FAIL，则服务器必须将ClientHello视为没有给定用户名的密码（参见第4.5.1.1节）。如果成功，服务器将获得客户端的用户名，并可以根据需要进行处理。客户端在加密之前添加的任何空八位字节都可以很容易地从表示用户名的字符串中去掉。
Prior to making a "commitment", both sides must generate a secret Element (PE) in the chosen group, using the common password-derived base. The server generates the PE after it receives the ClientHello and chooses the particular group to use, and the client generates the PE prior to sending the ClientHello in TLS 1.3 and upon receipt of the ServerKeyExchange in TLS pre-1.3.
在做出“承诺”之前，双方必须在所选组中使用公共密码派生基生成一个秘密元素（PE）。服务器在收到ClientHello并选择要使用的特定组之后生成PE，客户端在TLS 1.3中发送ClientHello之前以及在TLS 1.3之前收到ServerKeyExchange之后生成PE。
Fixing the PE involves an iterative "hunting-and-pecking" technique using the prime from the negotiated group's domain parameter set and an ECC-specific or FFC-specific operation, depending on the negotiated group.
修复PE涉及使用协商组的域参数集中的素数和特定于ECC或FFC的操作（取决于协商组）的迭代“搜索和啄食”技术。
To thwart side-channel attacks that attempt to determine the number of iterations of the hunting-and-pecking loop that are used to find the PE for a given password, a security parameter, m, is used to ensure that at least m iterations are always performed.
为了阻止试图确定用于查找给定密码的PE的狩猎和啄食循环的迭代次数的侧通道攻击，使用安全参数m确保始终执行至少m次迭代。
First, an 8-bit counter is set to the value one (1). Then, H is used to generate a password seed from the counter, the prime of the selected group, and the base (which is derived from the username, password, and, optionally, the salt; see Section 3.4):
首先，将8位计数器设置为值1（1）。然后，使用H从计数器、所选组的素数和基数（从用户名、密码和可选的salt派生；参见第3.4节）生成密码种子：
pwd-seed = H(base | counter | p)
pwd seed=H（基准|计数器| p）
Next, a context is generated consisting of random information. For versions of TLS less than 1.3, the context is a concatenation of the ClientHello random and the ServerHello random. For TLS 1.3, the context is the ClientHello random:
接下来，生成由随机信息组成的上下文。对于小于1.3的TLS版本，上下文是ClientHello random和ServerHello random的串联。对于TLS 1.3，上下文是ClientHello random：
if (version < 1.3) {
context = ClientHello.random | ServerHello.random
} else {
context = ClientHello.random
}
if (version < 1.3) {
context = ClientHello.random | ServerHello.random
} else {
context = ClientHello.random
}
Then, using the technique from Appendix B.5.1 of [FIPS186-4], the pwd-seed is expanded, using the Pseudorandom Function (PRF), to the length of the prime from the negotiated group's domain parameter set plus a constant, sixty-four (64), to produce an intermediate pwd-tmp, which is modularly reduced to create the pwd-value:
然后，使用[FIPS186-4]附录B.5.1中的技术，使用伪随机函数（PRF）将pwd种子扩展到协商组域参数集的素数长度加上常数六十四（64），以产生中间pwd tmp，该值被模块化减少以产生pwd值：
n = len(p) + 64
pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking",
context) [0..n];
pwd-value = (pwd-tmp mod (p - 1)) + 1
n = len(p) + 64
pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking",
context) [0..n];
pwd-value = (pwd-tmp mod (p - 1)) + 1
The pwd-value is then passed to the group-specific operation, which either returns the selected PE or fails. If the group-specific operation fails, the counter is incremented, a new pwd-seed is generated, and the hunting-and-pecking process continues; this procedure continues until the group-specific operation returns the PE. After the PE has been chosen, the base is changed to a random number, the counter is incremented, and the hunting-and-pecking process continues until the counter is greater than the security parameter, m.
然后将pwd值传递给特定于组的操作，该操作返回所选PE或失败。如果特定于组的操作失败，计数器递增，生成新的pwd种子，狩猎和啄食过程继续；此过程将继续，直到特定于组的操作返回PE。选择PE后，基数更改为随机数，计数器递增，狩猎和啄食过程继续，直到计数器大于安全参数m。
The probability that one requires more than n iterations of the hunting-and-pecking loop to find an ECC PE is roughly (q/2p)^n and to find an FFC PE is roughly (q/p)^n, both of which rapidly approach zero (0) as n increases. The security parameter, m, SHOULD be set sufficiently large such that the probability that finding the PE would take more than m iterations is sufficiently small (see Section 7).
搜索和啄食循环需要n次以上迭代才能找到ECC PE的概率约为（q/2p）^n，而找到FFC PE的概率约为（q/p）^n，两者都随着n的增加而迅速接近零（0）。安全参数m应设置得足够大，以确保找到PE所需迭代次数超过m次的概率足够小（参见第7节）。
When the PE has been discovered, pwd-seed, pwd-tmp, and pwd-value SHALL be irretrievably destroyed.
当发现PE时，pwd种子、pwd tmp和pwd值应被无可挽回地破坏。
The group-specific operation for ECC groups uses pwd-value, pwd-seed, and the equation for the curve to produce the PE. First, pwd-value is used directly as the x-coordinate, x, with the equation for the elliptic curve, with parameters a and b from the domain parameter set of the curve, to solve for a y-coordinate, y. If there is no solution to the quadratic equation, this operation fails and the hunting-and-pecking process continues. If a solution is found, then an ambiguity exists, as there are technically two solutions to the equation, and pwd-seed is used to unambiguously select one of them. If the low-order bit of pwd-seed is equal to the low-order bit of y, then a candidate PE is defined as the point (x, y); if the low-order bit of pwd-seed differs from the low-order bit of y, then a candidate PE is defined as the point (x, p - y), where p is the prime over which the curve is defined. The candidate PE becomes the PE, a random number is used instead of the base, and the hunting-and-pecking process continues until it has looped through m iterations, where m is a suitably large number to prevent side-channel attacks (see [RFC7664]).
ECC组的组特定操作使用pwd值、pwd种子和曲线方程生成PE。首先，pwd值直接用作x坐标x，椭圆曲线方程，参数a和b来自曲线的域参数集，用于求解y坐标y。如果二次方程没有解，该操作将失败，狩猎和啄食过程将继续。如果找到一个解决方案，则存在歧义，因为从技术上讲，方程有两个解决方案，并且使用pwd seed明确地选择其中一个。如果pwd种子的低阶位等于y的低阶位，则将候选PE定义为点（x，y）；如果pwd seed的低阶位与y的低阶位不同，则候选PE被定义为点（x，p-y），其中p是定义曲线的素数。候选PE成为PE，使用一个随机数代替基数，狩猎和啄食过程继续，直到它通过m次迭代循环，其中m是一个适当大的数字，以防止侧信道攻击（参见[RFC7664]）。
Algorithmically, the process looks like this:
从算法上看，该过程如下所示：
found = 0
counter = 0
n = len(p) + 64
if (version < 1.3)
context = ClientHello.random | ServerHello.random
} else {
context = ClientHello.random
}
do {
counter = counter + 1
seed = H(base | counter | p)
tmp = PRF(seed, "TLS-PWD Hunting And Pecking", context) [0..n]
val = (tmp mod (p - 1)) + 1
if ( (val^3 + a*val + b) mod p is a quadratic residue)
then
if (found == 0)
then
x = val
save = seed
found = 1
base = random()
fi
fi
} while ((found == 0) || (counter <= m))
y = sqrt(x^3 + a*x + b) mod p
if ( lsb(y) == lsb(save))
then
PE = (x, y)
else
PE = (x, p - y)
fi
found = 0
counter = 0
n = len(p) + 64
if (version < 1.3)
context = ClientHello.random | ServerHello.random
} else {
context = ClientHello.random
}
do {
counter = counter + 1
seed = H(base | counter | p)
tmp = PRF(seed, "TLS-PWD Hunting And Pecking", context) [0..n]
val = (tmp mod (p - 1)) + 1
if ( (val^3 + a*val + b) mod p is a quadratic residue)
then
if (found == 0)
then
x = val
save = seed
found = 1
base = random()
fi
fi
} while ((found == 0) || (counter <= m))
y = sqrt(x^3 + a*x + b) mod p
if ( lsb(y) == lsb(save))
then
PE = (x, y)
else
PE = (x, p - y)
fi
Figure 3: Fixing PE for ECC Groups
图3：固定ECC组的PE
Checking whether a value is a quadratic residue modulo a prime can leak information about that value in a side-channel attack. Therefore, it is RECOMMENDED that the technique used to determine if the value is a quadratic residue modulo p first blind the value with a random number so that the blinded value can take on all numbers between 1 and (p - 1) with equal probability. Determining the quadratic residue in a fashion that resists leakage of information is handled by flipping a coin and multiplying the blinded value by either a random quadratic residue or a random quadratic nonresidue and checking whether the multiplied value is a quadratic residue or a quadratic nonresidue modulo p, respectively. The random residue and
检查一个值是否是素数模的二次剩余可以在侧通道攻击中泄漏关于该值的信息。因此，建议用于确定该值是否为二次剩余模p的技术首先使用随机数对该值进行盲处理，以便盲处理的值可以以相同的概率对1和（p-1）之间的所有数字进行盲处理。通过翻转硬币并将盲值乘以随机二次剩余或随机二次非剩余，并分别检查乘以的值是二次剩余还是二次非剩余模p，以防止信息泄漏的方式确定二次剩余。随机剩余和
nonresidue can be calculated prior to hunting and pecking by calculating the Legendre symbol on random values until they are found:
在狩猎和啄食之前，可以通过计算随机值上的勒让德符号来计算无残留，直到找到它们：
do {
qr = random()
} while ( lgr(qr, p) != 1)
do {
qr = random()
} while ( lgr(qr, p) != 1)
do {
qnr = random()
} while ( lgr(qnr, p) != -1)
do {
qnr = random()
} while ( lgr(qnr, p) != -1)
Algorithmically, the masking technique to find out whether a value is a quadratic residue modulo a prime or not looks like this:
从算法上讲，确定值是否为素数模的二次剩余的掩蔽技术如下所示：
is_quadratic_residue (val, p) {
r = (random() mod (p - 1)) + 1
num = (val * r * r) mod p
if ( lsb(r) == 1 )
num = (num * qr) mod p
if ( lgr(num, p) == 1)
then
return TRUE
fi
else
num = (num * qnr) mod p
if ( lgr(num, p) == -1)
then
return TRUE
fi
fi
return FALSE
}
is_quadratic_residue (val, p) {
r = (random() mod (p - 1)) + 1
num = (val * r * r) mod p
if ( lsb(r) == 1 )
num = (num * qr) mod p
if ( lgr(num, p) == 1)
then
return TRUE
fi
else
num = (num * qnr) mod p
if ( lgr(num, p) == -1)
then
return TRUE
fi
fi
return FALSE
}
The random quadratic residue and quadratic nonresidue (qr and qnr above) can be used for all the hunting-and-pecking loops, but the blinding value, r, MUST be chosen randomly for each loop.
随机二次剩余和二次非剩余（上面的qr和qnr）可用于所有狩猎和啄食循环，但必须为每个循环随机选择盲值r。
The group-specific operation for FFC groups takes the prime (p) and the order (q) from the group's domain parameter set and the variable pwd-value to directly produce a candidate PE, by exponentiating the pwd-value to the value ((p - 1)/q) modulo p. See Section 3.2.2 when the order is not part of the defined domain parameter set. If the result is greater than one (1), the candidate PE becomes the PE, and
FFC组的组特定操作从组的域参数集和变量pwd值中获取素数（p）和顺序（q），通过将pwd值乘以模p的值（（p-1）/q），直接生成候选PE。当订单不属于定义的域参数集时，请参见第3.2.2节。如果结果大于一（1），则候选PE成为PE，并且
the hunting-and-pecking process continues until it has looped through m iterations, where m is a suitably large number to prevent side-channel attacks (see [RFC7664]).
狩猎和啄食过程一直持续，直到它通过m次迭代循环，其中m是一个适当大的数字，以防止侧通道攻击（请参见[RFC7664]）。
Algorithmically, the process looks like this:
从算法上看，该过程如下所示：
found = 0
counter = 0
n = len(p) + 64
if (version < 1.3)
context = ClientHello.random | ServerHello.random
} else {
context = ClientHello.random
}
do {
counter = counter + 1
pwd-seed = H(base | counter | p)
pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking",
context) [0..n]
pwd-value = (pwd-tmp mod (p - 1)) + 1
PE = pwd-value^((p - 1)/q) mod p
if (PE > 1)
then
found = 1
base = random()
fi
} while ((found == 0) || (counter <= m))
found = 0
counter = 0
n = len(p) + 64
if (version < 1.3)
context = ClientHello.random | ServerHello.random
} else {
context = ClientHello.random
}
do {
counter = counter + 1
pwd-seed = H(base | counter | p)
pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking",
context) [0..n]
pwd-value = (pwd-tmp mod (p - 1)) + 1
PE = pwd-value^((p - 1)/q) mod p
if (PE > 1)
then
found = 1
base = random()
fi
} while ((found == 0) || (counter <= m))
Figure 4: Fixing PE for FFC Groups
图4：固定FFC组的PE
The client is required to identify herself to the server by adding either a pwd_protect or pwd_clear extension to her ClientHello message, depending on whether the client wishes to protect her username (see Section 4.3) or not, respectively. The pwd_protect and pwd_clear extensions use the standard mechanism defined in [RFC5246]. The "extension data" field of the extension SHALL contain a pwd_name, which is used to identify the password shared between the client and server. If username protection is performed and the ExtensionType is pwd_protect, the contents of the pwd_name SHALL be constructed according to Section 4.3.1.
客户端需要通过向其ClientHello消息添加pwd_protect或pwd_clear扩展名向服务器标识自己，具体取决于客户端是否希望保护其用户名（参见第4.3节）。pwd_protect和pwd_clear扩展使用[RFC5246]中定义的标准机制。扩展的“扩展数据”字段应包含pwd_名称，用于标识客户端和服务器之间共享的密码。如果执行用户名保护且扩展类型为pwd_protect，则应根据第4.3.1节构造pwd_名称的内容。
enum { pwd_protect(29), pwd_clear(30) } ExtensionType;
enum { pwd_protect(29), pwd_clear(30) } ExtensionType;
opaque pwd_name<1..2^8-1>;
opaque pwd_name<1..2^8-1>;
An unprotected pwd_name SHALL be a UTF-8 encoded character string processed according to the rules of the OpaqueString profile of [RFC8265], and a protected pwd_name SHALL be a string of bits.
未受保护的pwd_名称应为根据[RFC8265]的不透明字符串配置文件规则处理的UTF-8编码字符串，受保护的pwd_名称应为位字符串。
The scalar and Element that comprise each peer's "commitment" are generated as follows.
构成每个对等方的“承诺”的标量和元素生成如下。
First, two random numbers, called "private" and "mask", between zero and the order of the group (exclusive) are generated. If their sum modulo the order of the group, q, equals zero (0) or one (1), the numbers must be thrown away and new random numbers generated. If their sum modulo the order of the group, q, is greater than one, the sum becomes the scalar.
首先，生成两个随机数，称为“private”和“mask”，介于零和组顺序（排他）之间。如果它们与群的阶数q的和模等于零（0）或一（1），则必须丢弃这些数字并生成新的随机数。如果它们与群的阶数q的和大于1，则和成为标量。
scalar = (private + mask) mod q
scalar = (private + mask) mod q
The Element is then calculated as the inverse of the group's scalar operation (see the group-specific operations discussed in Section 3.2) with the mask and PE.
然后使用掩码和PE将元素计算为组的标量运算的逆运算（参见第3.2节中讨论的组特定运算）。
Element = inverse(scalar-op(mask, PE))
Element = inverse(scalar-op(mask, PE))
After calculation of the scalar and Element, the mask SHALL be irretrievably destroyed.
在计算标量和元素后，掩模应被无可挽回地破坏。
A client offering a PWD ciphersuite MUST include one of the pwd_name extensions from Section 4.4.3 in her ClientHello.
提供PWD密码套件的客户必须在其ClientHello中包含第4.4.3节中的一个PWD_名称扩展。
If a server does not have a password for a client identified by the username either extracted from the pwd_name (if unprotected) or recovered using the technique provided in Section 4.3.2 (if protected), or if recovery of a protected username fails, the server SHOULD hide that fact by simulating the protocol -- putting random data in the PWD-specific components of the ServerKeyExchange -- and then rejecting the client's finished message with a "bad_record_mac" alert [RFC8446]. To properly effect a simulated TLS-PWD exchange, an appropriate delay SHOULD be inserted between receipt of the ClientHello and response of the ServerHello. Alternately, a server
如果服务器没有从pwd_名称中提取的用户名标识的客户端密码（如果未受保护），或者使用第4.3.2节提供的技术进行恢复（如果受保护），或者如果恢复受保护的用户名失败，服务器应该通过模拟协议来隐藏这一事实——将随机数据放入ServerKeyExchange的PWD特定组件中，然后用“bad_record_mac”警报拒绝客户端完成的消息[RFC8446]。为了正确地进行模拟TLS-PWD交换，应该在ClientHello的接收和ServerHello的响应之间插入适当的延迟。或者，服务器
MAY choose to terminate the exchange if a password is not found. The security implication of terminating the exchange is to expose to an attacker whether a username is valid or not.
如果找不到密码，可以选择终止交换。终止交换的安全性意味着向攻击者公开用户名是否有效。
The server decides on a group to use with the named user (see Section 9) and generates the PE according to Section 4.4.2.
服务器决定与命名用户一起使用的组（参见第9节），并根据第4.4.2节生成PE。
The domain parameter set for the selected group MUST be explicitly specified by name in the ServerKeyExchange. ECC groups are specified using the NamedCurve enumeration of [RFC8422], and FFC groups are specified using the NamedGroup extensions added by [RFC7919] to the "TLS Supported Groups" registry in [TLS_REG]. In addition to the group specification, the ServerKeyExchange also contains the server's "commitment" in the form of a scalar and Element, and the salt that was used to store the user's password.
必须在ServerKeyExchange中通过名称显式指定所选组的域参数集。ECC组使用[RFC8422]的NamedCurve枚举指定，FFC组使用[RFC7919]添加到[TLS_REG]中“TLS支持的组”注册表的NamedGroup扩展指定。除了组规范外，ServerKeyExchange还包含标量和元素形式的服务器“承诺”，以及用于存储用户密码的salt。
Two new values have been added to the enumerated KeyExchangeAlgorithm to indicate TLS-PWD using FFC and TLS-PWD using ECC: ff_pwd and ec_pwd, respectively.
在枚举的KeyExchangeAlgorithm中添加了两个新值，分别表示使用FFC的TLS-PWD和使用ECC的TLS-PWD:ff_PWD和ec_PWD。
enum { ff_pwd, ec_pwd } KeyExchangeAlgorithm;
enum { ff_pwd, ec_pwd } KeyExchangeAlgorithm;
struct {
opaque salt<1..2^8-1>;
NamedGroup ff_group;
opaque ff_selement<1..2^16-1>;
opaque ff_sscalar<1..2^16-1>;
} ServerFFPWDParams;
struct {
opaque salt<1..2^8-1>;
NamedGroup ff_group;
opaque ff_selement<1..2^16-1>;
opaque ff_sscalar<1..2^16-1>;
} ServerFFPWDParams;
struct {
opaque salt<1..2^8-1>;
ECParameters curve_params;
ECPoint ec_selement;
opaque ec_sscalar<1..2^8-1>;
} ServerECPWDParams;
struct {
opaque salt<1..2^8-1>;
ECParameters curve_params;
ECPoint ec_selement;
opaque ec_sscalar<1..2^8-1>;
} ServerECPWDParams;
struct {
select (KeyExchangeAlgorithm) {
case ec_pwd:
ServerECPWDParams params;
case ff_pwd:
ServerFFPWDParams params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case ec_pwd:
ServerECPWDParams params;
case ff_pwd:
ServerFFPWDParams params;
};
} ServerKeyExchange;
The scalar and Element referenced in this section are derived according to Section 4.4.4.
本节中引用的标量和元素根据第4.4.4节推导。
ECC domain parameters are specified in the ECParameters component of the ECC-specific ServerKeyExchange as defined in [RFC8422]. The scalar SHALL become the ec_sscalar component, and the Element SHALL become the ec_selement of the ServerKeyExchange. If the client requested a specific point format (compressed or uncompressed) with the Supported Point Formats Extension (see [RFC8422]) in its ClientHello, the Element MUST be formatted in the ec_selement to conform to that request. If the client offered (an) elliptic curve(s) in its ClientHello using the Supported Elliptic Curves Extension, the server MUST include (one of the) named curve(s) in the ECParameters field in the ServerKeyExchange and the key exchange operations specified in Section 4.5.1.2.1 MUST use that group.
ECC域参数在[RFC8422]中定义的ECC特定ServerKeyExchange的ECParameters组件中指定。标量应成为ec_sscalar组件，元素应成为ServerKeyExchange的ec选择。如果客户机在其ClientHello中请求使用支持的点格式扩展名（请参见[RFC8422]）的特定点格式（压缩或未压缩），则必须在ec选项中对元素进行格式化，以符合该请求。如果客户机在其ClientHello中使用支持的椭圆曲线扩展提供了椭圆曲线，则服务器必须在ServerKeyExchange的ECParameters字段中包含（其中一条）命名曲线，并且第4.5.1.2.1节中指定的密钥交换操作必须使用该组。
As mentioned in Section 3.2.1, characteristic-2 curves and curves with a co-factor greater than one (1) SHALL NOT be used by TLS-PWD.
如第3.2.1节所述，TLS-PWD不得使用特征-2曲线和系数大于一（1）的曲线。
FFC domain parameters use the NamedGroup extension specified in [RFC7919]. The scalar SHALL become the ff_sscalar component, and the Element SHALL become the ff_selement in the FFC-specific ServerKeyExchange.
FFC域参数使用[RFC7919]中指定的NamedGroup扩展名。标量应成为ff_sscalar组件，元素应成为FFC特定服务器密钥交换中的ff_选择。
As mentioned in Section 3.2.2, if the prime is a safe prime and no order is included in the domain parameter set, the order added to the ServerKeyExchange SHALL be the prime minus one divided by two -- (p - 1)/2.
如第3.2.2节所述，如果素数是安全素数，并且域参数集中不包含顺序，则添加到ServerKeyExchange的顺序应为素数减1除以2——（p-1）/2。
Upon receipt of the ServerKeyExchange, the client decides whether to support the indicated group or not. If the client decides to support the indicated group, the server's "commitment" MUST be validated by ensuring that 1) the server's scalar value is greater than one (1) and less than the order of the group, q and 2) the Element is valid for the chosen group (see Sections 3.2.1 and 3.2.2 for how to determine whether an Element is valid for the particular group. Note that if the Element is a compressed point on an elliptic curve, it MUST be uncompressed before checking its validity).
收到ServerKeyExchange后，客户机决定是否支持指定的组。如果客户机决定支持指定的组，则必须通过确保1）服务器的标量值大于一（1）且小于组的顺序q和2）元素对所选组有效来验证服务器的“承诺”（参见第3.2.1节和第3.2.2节，了解如何确定元素对特定组是否有效。注意，如果元素是椭圆曲线上的压缩点，则必须在检查其有效性之前对其进行解压缩）。
If the group is acceptable and the server's "commitment" has been successfully validated, the client extracts the salt from the ServerKeyExchange and generates the PE according to Sections 3.4 and 4.4.2. If the group is not acceptable or the server's "commitment" failed validation, the exchange MUST be aborted.
如果组可接受且服务器的“承诺”已成功验证，则客户端将从ServerKeyExchange提取salt，并根据第3.4节和第4.4.2节生成PE。如果组不可接受或服务器的“承诺”验证失败，则必须中止交换。
When the value of KeyExchangeAlgorithm is either ff_pwd or ec_pwd, the ClientKeyExchange is used to convey the client's "commitment" to the server. It therefore contains a scalar and an Element.
当KeyExchangeAlgorithm的值为ff_pwd或ec_pwd时，ClientKeyExchange用于向服务器传递客户端的“承诺”。因此，它包含一个标量和一个元素。
struct {
opaque ff_celement<1..2^16-1>;
opaque ff_cscalar<1..2^16-1>;
} ClientFFPWDParams;
struct {
opaque ff_celement<1..2^16-1>;
opaque ff_cscalar<1..2^16-1>;
} ClientFFPWDParams;
struct {
ECPoint ec_celement;
opaque ec_cscalar<1..2^8-1>;
} ClientECPWDParams;
struct {
ECPoint ec_celement;
opaque ec_cscalar<1..2^8-1>;
} ClientECPWDParams;
struct {
select (KeyExchangeAlgorithm) {
case ff_pwd: ClientFFPWDParams;
case ec_pwd: ClientECPWDParams;
} exchange_keys;
} ClientKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case ff_pwd: ClientFFPWDParams;
case ec_pwd: ClientECPWDParams;
} exchange_keys;
} ClientKeyExchange;
The client's scalar and Element are generated in the manner described in Section 4.5.1.2.1.
客户的标量和元素按照第4.5.1.2.1节所述的方式生成。
For an FFC group, the scalar SHALL become the ff_cscalar component and the Element SHALL become the ff_celement in the FFC-specific ClientKeyExchange.
对于FFC组，标量应成为ff_cCalar组件，元素应成为FFC特定ClientKeyExchange中的ff_celement。
For an ECC group, the scalar SHALL become the ec_cscalar component and the Element SHALL become the ec_celement in the ECC-specific ClientKeyExchange. If the client requested a specific point format (compressed or uncompressed) with the Supported Point Formats Extension in its ClientHello, then the Element MUST be formatted in the ec_celement to conform to its initial request.
对于ECC组，标量应成为ECC cscalar组件，元素应成为ECC特定ClientKeyExchange中的ECC元素。如果客户机在其ClientHello中请求使用支持的point Formats扩展名的特定点格式（压缩或未压缩），则必须在电子商务中对元素进行格式化，以符合其初始请求。
Upon receipt of the ClientKeyExchange, the server must validate the client's "commitment" by ensuring that 1) the client's scalar and Element differ from the server's scalar and Element, 2) the client's scalar value is greater than one (1) and less than the order of the group, q, and 3) the Element is valid for the chosen group (see Sections 3.2.1 and 3.2.2 for how to determine whether an Element is valid for a particular group. Note that if the Element is a compressed point on an elliptic curve, it MUST be uncompressed before checking its validity). If any of these three conditions are not met, the server MUST abort the exchange.
收到ClientKeyExchange后，服务器必须通过确保1）客户端的标量和元素与服务器的标量和元素不同，2）客户端的标量值大于一（1）且小于组的顺序q，以及3）元素对所选组有效来验证客户端的“承诺”（有关如何确定元素对特定组是否有效的信息，请参见第3.2.1节和第3.2.2节。请注意，如果元素是椭圆曲线上的压缩点，则在检查其有效性之前必须先对其进行解压缩）。如果这三个条件中的任何一个不满足，服务器必须中止交换。
TLS 1.3 clients and servers convey their commit values in a "key_share" extension. The structure of this extension SHALL be:
TLS 1.3客户端和服务器在“密钥共享”扩展中传递其提交值。该扩建部分的结构应为：
enum { ff_pwd, ec_pwd } KeyExchangeAlgorithm;
enum { ff_pwd, ec_pwd } KeyExchangeAlgorithm;
struct {
select (KeyExchangeAlgorithm) {
case ec_pwd:
opaque elemX[coordinate_length];
opaque elemY[coordinate_length];
case ff_pwd:
opaque elem[coordinate_length];
};
opaque scalar<1..2^8-1>
} PWDKeyShareEntry;
struct {
select (KeyExchangeAlgorithm) {
case ec_pwd:
opaque elemX[coordinate_length];
opaque elemY[coordinate_length];
case ff_pwd:
opaque elem[coordinate_length];
};
opaque scalar<1..2^8-1>
} PWDKeyShareEntry;
struct {
NamedGroup group;
PWDKeyShareEntry pwd_key_exchange<1..2^16-1>;
} KeyShareEntry;
struct {
NamedGroup group;
PWDKeyShareEntry pwd_key_exchange<1..2^16-1>;
} KeyShareEntry;
The ClientHello message MUST include a pwd_name extension from Section 4.4.3 and it MUST include a key_share extension from Section 4.5.2.1.
ClientHello消息必须包含第4.4.3节中的pwd_名称扩展，并且必须包含第4.5.2.1节中的密钥共享扩展。
Upon receipt of a ClientHello, the server MUST validate the key_share extension_data [RFC8446] to ensure that the scalar value is greater than one (1) and less than the order of the group q, and that the Element is valid for the chosen group (see Sections 3.2.1 and 3.2.2).
收到ClientHello后，服务器必须验证密钥共享扩展数据[RFC8446]，以确保标量值大于一（1）且小于组q的顺序，并且元素对所选组有效（请参见第3.2.1和3.2.2节）。
If a server does not have a password for a client identified by the username either extracted from the pwd_name (if unprotected) or recovered using the technique in Section 4.3.2 (if protected), or if recovery of a protected username fails, the server SHOULD hide that fact by simulating the protocol -- putting random data in the PWD-specific components of its KeyShareEntry -- and then rejecting the client's finished message with a "bad_record_mac" alert. To properly effect a simulated TLS-PWD exchange, an appropriate delay SHOULD be inserted between receipt of the ClientHello and response of the ServerHello. Alternately, a server MAY choose to terminate the exchange if a password is not found. The security implication of terminating the exchange is to expose to an attacker whether a username is valid or not.
如果服务器没有从pwd_名称中提取的用户名（如果未受保护）或使用第4.3.2节中的技术恢复的用户名标识的客户端密码（如果受保护），或者如果恢复受保护的用户名失败，服务器应该通过模拟协议来隐藏这一事实——将随机数据放入其密钥共享的PWD特定组件中——然后用“bad_record_mac”警报拒绝客户端完成的消息。为了正确地进行模拟TLS-PWD交换，应该在ClientHello的接收和ServerHello的响应之间插入适当的延迟。或者，如果找不到密码，服务器可以选择终止交换。终止交换的安全性意味着向攻击者公开用户名是否有效。
If the server supports TLS-PWD, agrees with the group chosen by the client, and finds an unsalted password indicated by the pwd_name extension of the received ClientHello, its ServerHello MUST contain a key_share extension from Section 4.5.2.1 in the same group as that chosen by the client.
如果服务器支持TLS-PWD，同意客户端选择的组，并找到由接收的ClientHello的PWD_名称扩展指示的未加密密码，则其ServerHello必须在与客户端选择的组相同的组中包含第4.5.2.1节中的密钥共享扩展。
Upon receipt of a ServerHello, the client MUST validate the key_share extension_data to ensure that the scalar value is greater than one (1) and less than the order of the group q, and that the Element is valid for the chosen group (see Sections 3.2.1 and 3.2.2).
收到ServerHello后，客户端必须验证密钥共享扩展数据，以确保标量值大于一（1）且小于组q的顺序，并且元素对所选组有效（请参见第3.2.1和3.2.2节）。
The server sends this message in response to a ClientHello if it desires a different group or if the password identified by the client's password identified by pwd_name is salted.
如果服务器需要另一个组，或者如果pwd_name标识的客户机密码标识的密码是salt，则服务器会将此消息发送给ClientHello。
A different group is indicated by adding the KeyShareHelloRetryRequest extension to the HelloRetryRequest. The indication of a salted password, and the salt used, is done by adding the following structure:
通过将KeyShareHelloRetryRequest扩展添加到HelloRetryRequest来指示不同的组。通过添加以下结构来指示salt密码和使用的salt：
enum { password_salt(31) } ExtensionType;
enum { password_salt(31) } ExtensionType;
struct {
opaque pwd_salt<2^16-1>;
} password_salt;
struct {
opaque pwd_salt<2^16-1>;
} password_salt;
A client that receives a HelloRetryRequest indicating the password salt SHALL delete its computed PE and derive another version using the salt prior to sending another ClientHello.
接收到指示密码salt的HelloRetryRequest的客户端应删除其计算的PE，并在发送另一个ClientHello之前使用salt派生另一个版本。
The client and server use their private value as calculated in Section 4.4.4 with the other party's Element and scalar for the ServerHello or ClientHello, respectively (here denoted "Peer_Element" and "peer_scalar") to generate the shared secret z.
客户机和服务器使用第4.4.4节中计算的私有值，分别使用另一方的元素和ServerHello或ClientHello的标量（此处表示为“Peer_元素”和“Peer_标量”）生成共享秘密z。
z = F(scalar-op(private,
elem-op(Peer_Element,
scalar-op(peer_scalar, PE))))
z = F(scalar-op(private,
elem-op(Peer_Element,
scalar-op(peer_scalar, PE))))
For TLS versions prior to 1.3, the intermediate value, z, is then used as the premaster secret after any leading bytes of z that contain all zero bits have been stripped off. For TLS version 1.3, leading zero bytes are retained, and the intermediate value z is used as the (EC)DHE input in the key schedule.
对于1.3之前的TLS版本，在包含所有零位的z的任何前导字节被剥离后，中间值z将被用作预主密钥。对于TLS版本1.3，保留前导零字节，中间值z用作密钥计划中的（EC）DHE输入。
This memo adds the following ciphersuites:
此备忘录添加了以下密码套件：
CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (0xC0,0xB0);
CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (0xC0,0xB0);
CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (0xC0,0xB1);
CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (0xC0,0xB1);
CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (0xC0,0xB2);
CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (0xC0,0xB2);
CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (0xC0,0xB3);
CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (0xC0,0xB3);
Implementations conforming to this specification MUST support the TLS_ECCPWD_WITH_AES_128_GCM_SHA256 ciphersuite; they SHOULD support the remaining ciphersuites.
符合本规范的实施必须支持TLS_ECCPWD_和_AES_128_GCM_SHA256密码套件；它们应该支持其余的密码套件。
When negotiated with a version of TLS prior to 1.2, the PRF from that earlier version is used; when the negotiated version of TLS is TLS 1.2, the PRF is the TLS 1.2 PRF [RFC5246], using the hash function indicated by the ciphersuite; when the negotiated version of TLS is TLS 1.3, the PRF is the Derive-Secret function from Section 7.1 of [RFC8446]. Regardless of the TLS version, the TLS-PWD random function, H, is always instantiated with the hash algorithm indicated by the ciphersuite.
当与1.2之前版本的TLS协商时，使用该早期版本的PRF；当TLS的协商版本为TLS 1.2时，PRF为TLS 1.2 PRF[RFC5246]，使用密码套件指示的哈希函数；当TLS的协商版本为TLS 1.3时，PRF是[RFC8446]第7.1节中的派生秘密函数。无论TLS版本如何，TLS-PWD随机函数H始终使用密码套件指示的哈希算法进行实例化。
For those ciphersuites that use Cipher Block Chaining (CBC) [SP800-38A] mode, the MAC is HMAC [RFC2104] with the hash function indicated by the ciphersuite.
对于那些使用密码块链接（CBC）[SP800-38A]模式的密码套件，MAC为HMAC[RFC2104]，其哈希函数由密码套件指示。
IANA has assigned three values for new TLS extension types from the "TLS ExtensionType Values" registry defined in [RFC8446] and [RFC8447]. They are pwd_protect (29), pwd_clear (30), and password_salt (31). See Sections 4.5.1.1 and 4.5.2.2 for more information.
IANA从[RFC8446]和[RFC8447]中定义的“TLS ExtensionType values”注册表中为新的TLS扩展类型分配了三个值。它们是pwd_保护（29）、pwd_清除（30）和密码_盐（31）。详见第4.5.1.1节和第4.5.2.2节。
In summary, the following rows have been added to the "TLS ExtensionType Values" registry:
总之，以下行已添加到“TLS ExtensionType值”注册表中：
+-------+----------------+-------------+-----------+
| Value | Extension Name | TLS 1.3 | Reference |
+-------+----------------+-------------+-----------+
| 29 | pwd_protect | CH | RFC 8492 |
| 30 | pwd_clear | CH | RFC 8492 |
| 31 | password_salt | CH, SH, HRR | RFC 8492 |
+-------+----------------+-------------+-----------+
+-------+----------------+-------------+-----------+
| Value | Extension Name | TLS 1.3 | Reference |
+-------+----------------+-------------+-----------+
| 29 | pwd_protect | CH | RFC 8492 |
| 30 | pwd_clear | CH | RFC 8492 |
| 31 | password_salt | CH, SH, HRR | RFC 8492 |
+-------+----------------+-------------+-----------+
IANA has assigned the following ciphersuites from the "TLS Cipher Suites" registry defined in [RFC8446] and [RFC8447]:
IANA已从[RFC8446]和[RFC8447]中定义的“TLS密码套件”注册表中分配了以下密码套件：
CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (0xC0,0xB0);
CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (0xC0,0xB0);
CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (0xC0,0xB1);
CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (0xC0,0xB1);
CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (0xC0,0xB2);
CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (0xC0,0xB2);
CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (0xC0,0xB3);
CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (0xC0,0xB3);
The "DTLS-OK" column in the registry has been set to "Y", and the "Recommended" column has been set to "N" for all ciphersuites defined in this memo.
注册表中的“DTLS-OK”列已设置为“Y”，对于本备忘录中定义的所有密码套件，“推荐”列已设置为“N”。
A security proof of this key exchange in the random oracle model is found in [lanskro].
[lanskro]中提供了随机oracle模型中此密钥交换的安全性证明。
A passive attacker against this protocol will see the ServerKeyExchange and the ClientKeyExchange (in TLS pre-1.3), or the KeyShare (from TLS 1.3), containing the scalar and Element of the server and the client, respectively. The client and server effectively hide their secret private value by masking it modulo the order of the selected group. If the order is "q", then there are approximately "q" distinct pairs of numbers that will sum to the scalar values observed. It is possible for an attacker to iterate through all such values, but for a large value of "q", this
针对该协议的被动攻击者将看到ServerKeyExchange和ClientKeyExchange（在TLS 1.3之前版本中）或KeyShare（来自TLS 1.3），分别包含服务器和客户端的标量和元素。客户端和服务器通过按所选组的顺序屏蔽它们的秘密私有值，从而有效地隐藏了它们的秘密私有值。如果顺序为“q”，则大约有“q”个不同的数字对，它们将和观测到的标量值相加。攻击者有可能遍历所有这些值，但对于较大的“q”值，这
exhaustive search technique is computationally infeasible. The attacker would have a better chance in solving the discrete logarithm problem, which we have already assumed (see Section 3.5) to be an intractable problem.
穷举搜索技术在计算上是不可行的。攻击者将有更好的机会解决离散对数问题，我们已经假设（见第3.5节）这是一个难以解决的问题。
A passive attacker can take the Element from the ServerKeyExchange or the ClientKeyExchange (in TLS pre-1.3), or from the KeyShare (from TLS 1.3), and try to determine the random "mask" value used in its construction and then recover the other party's "private" value from the scalar in the same message. But this requires the attacker to solve the discrete logarithm problem, which we assumed was intractable.
被动攻击者可以从ServerKeyExchange或ClientKeyExchange（在TLS pre-1.3中）或KeyShare（在TLS 1.3中）获取元素，并尝试确定其构造中使用的随机“掩码”值，然后从同一消息中的标量恢复另一方的“私有”值。但这需要攻击者解决离散对数问题，我们认为这个问题很难解决。
Both the client and the server obtain a shared secret based on a secret group Element and the private information they contributed to the exchange. The secret group Element is based on the password. If they do not share the same password, they will be unable to derive the same secret group Element, and if they don't generate the same secret group Element, they will be unable to generate the same shared secret. Seeing a finished message will not provide any additional advantage of attack, since it is generated with the unknowable secret.
客户端和服务器都根据秘密组元素和它们为交换贡献的私有信息获取共享秘密。秘密组元素基于密码。如果它们不共享相同的密码，它们将无法派生相同的机密组元素，如果它们不生成相同的机密组元素，它们将无法生成相同的共享机密。看到完成的消息不会提供任何额外的攻击优势，因为它是用不可知的秘密生成的。
In TLS pre-1.3, an active attacker impersonating the client can induce a server to send a ServerKeyExchange containing the server's scalar and Element. The attacker can attempt to generate a ClientKeyExchange and send it to the server, but she is required to send a finished message first; therefore, the only information she can obtain in this attack is less than the information she can obtain from a passive attack, so this particular active attack is not very fruitful.
在TLS pre-1.3中，模拟客户端的主动攻击者可以诱使服务器发送包含服务器标量和元素的ServerKeyExchange。攻击者可以尝试生成ClientKeyExchange并将其发送到服务器，但要求她首先发送一条完成的消息；因此，她在这次攻击中所能获得的唯一信息少于她从被动攻击中所能获得的信息，因此这种特定的主动攻击不是很有效。
In TLS pre-1.3, an active attacker can impersonate the server and send a forged ServerKeyExchange after receiving the ClientHello. The attacker then waits until it receives the ClientKeyExchange and finished message from the client. Now the attacker can attempt to run through all possible values of the password, computing the PE (see Section 4.4), computing candidate premaster secrets (see Section 4.6), and attempting to recreate the client's finished message.
在TLS pre-1.3中，主动攻击者可以模拟服务器并在收到ClientHello后发送伪造的ServerKeyExchange。然后，攻击者等待，直到从客户端收到ClientKeyExchange和完成消息。现在，攻击者可以尝试运行所有可能的密码值，计算PE（请参见第4.4节），计算候选premaster机密（请参见第4.6节），并尝试重新创建客户端完成的消息。
But the attacker committed to a single guess of the password with her forged ServerKeyExchange. That value was used by the client in her computation of the premaster secret, which was used to produce the finished message. Any guess of the password that differs from the password used in the forged ServerKeyExchange would result in each side using a different PE in the computation of the premaster secret; therefore, the finished message cannot be verified as correct, even
但攻击者利用伪造的ServerKeyExchange对密码进行了一次猜测。客户机在计算premaster机密时使用了该值，该机密用于生成完成的消息。任何与伪造ServerKeyExchange中使用的密码不同的密码猜测都会导致双方在计算premaster机密时使用不同的PE；因此，无法验证完成的消息是否正确，甚至
if a subsequent guess, while running through all possible values, was correct. The attacker gets one guess, and one guess only, per active attack.
在运行所有可能的值时，如果后续猜测是正确的。每次主动攻击，攻击者只能猜测一次。
Instead of attempting to guess at the password, an attacker can attempt to determine the PE and then launch an attack. But the PE is determined by the output of the random function, H, which is indistinguishable from a random source, since H is assumed to be a "random oracle" (Section 3.5). Therefore, each Element of the finite cyclic group will have an equal probability of being the PE. The probability of guessing the PE will be 1/q, where q is the order of the group. For a large value of "q", this will be computationally infeasible.
攻击者可以尝试确定PE，然后发起攻击，而不是试图猜测密码。但PE由随机函数H的输出确定，该函数与随机源无法区分，因为H被假定为“随机预言”（第3.5节）。因此，有限循环群中的每个元素都具有成为PE的相同概率。猜测PE的概率为1/q，其中q是组的顺序。对于较大的“q”值，这在计算上是不可行的。
The implications of resistance to dictionary attacks are significant. An implementation can provision a password in a practical and realistic manner -- i.e., it MAY be a character string, and it MAY be relatively short -- and still maintain security. The nature of the pool of potential passwords determines the size of the pool, D, and countermeasures can prevent an attacker from determining the password in the only possible way: repeated, active, guessing attacks. For example, a simple four-character string using lowercase English characters, and assuming random selection of those characters, will result in D of over four hundred thousand. An attacker would need to mount over one hundred thousand active, guessing attacks (which will easily be detected) before gaining any significant advantage in determining the pre-shared key.
抵抗字典攻击的含义非常重要。一个实现可以以实际可行的方式提供密码——也就是说，它可能是一个字符串，也可能相对较短——并且仍然保持安全性。潜在密码池的性质决定了池的大小，而对策可以防止攻击者以唯一可能的方式确定密码：重复、主动、猜测攻击。例如，一个简单的使用小写英文字符的四个字符字符串，并假设随机选择这些字符，将导致D超过四十万。在确定预共享密钥时，攻击者需要发起超过十万次的活动猜测攻击（很容易被检测到），才能获得任何显著优势。
Countermeasures to deal with successive active, guessing attacks are only possible by noticing that a certain username is failing repeatedly over a certain period of time. Attacks that attempt to find a password for a random user are more difficult to detect. For instance, if a device uses a serial number as a username and the pool of potential passwords is sufficiently small, a more effective attack would be to select a password and try all potential "users" to disperse the attack and confound countermeasures. It is therefore RECOMMENDED that implementations of TLS-PWD keep track of the total number of failed authentications, regardless of username, in an effort to detect and thwart this type of attack.
只有注意到某个用户名在一段时间内反复失败，才能采取应对连续主动猜测攻击的对策。试图为随机用户查找密码的攻击更难检测。例如，如果设备使用序列号作为用户名，且潜在密码池足够小，则更有效的攻击是选择密码并尝试所有潜在“用户”分散攻击并混淆对策。因此，建议TLS-PWD的实现跟踪失败身份验证的总数，无论用户名如何，以检测并阻止此类攻击。
The benefits of resistance to dictionary attacks can be lessened by a client using the same passwords with multiple servers. An attacker could redirect a session from one server to the other if the attacker knew that the intended server stored the same password for the client as another server.
如果客户端在多台服务器上使用相同的密码，那么抵抗字典攻击的好处就会减少。如果攻击者知道目标服务器为客户端存储的密码与另一台服务器相同，则攻击者可以将会话从一台服务器重定向到另一台服务器。
An adversary that has access to, and a considerable amount of control over, a client or server could attempt to mount a side-channel attack to determine the number of times it took for a certain password (plus client random and server random) to select a PE. Each such attack could result in a successive "paring down" of the size of the pool of potential passwords, resulting in a manageably small set from which to launch a series of active attacks to determine the password. A security parameter, m, is used to normalize the amount of work necessary to determine the PE (see Section 4.4). The probability that a password will require more than m iterations is roughly (q/2p)^m for ECC groups and (q/p)^m for FFC groups, so it is possible to mitigate side-channel attacks at the expense of a constant cost per connection attempt. But if a particular password requires more than k iterations, it will leak k bits of information to the side-channel attacker; for some dictionaries, this will uniquely identify the password. Therefore, the security parameter, m, needs to be set with great care. It is RECOMMENDED that an implementation set the security parameter, m, to a value of at least forty (40), which will put the probability that more than forty iterations are needed in the order of one in one trillion (1:1,000,000,000,000).
能够访问客户端或服务器并对其进行大量控制的对手可以尝试发起侧通道攻击，以确定特定密码（加上客户端随机密码和服务器随机密码）选择PE所需的次数。每一次这样的攻击都可能导致潜在密码池大小的连续“缩减”，从而形成一个可管理的小集合，从中发起一系列主动攻击以确定密码。安全参数m用于标准化确定PE所需的工作量（见第4.4节）。密码需要超过m次迭代的概率对于ECC组约为（q/2p）^m，对于FFC组约为（q/p）^m，因此可以以每次连接尝试的恒定成本为代价来减轻侧通道攻击。但是，如果某个特定密码需要超过k次迭代，它将向侧通道攻击者泄漏k位信息；对于某些字典，这将唯一标识密码。因此，需要非常小心地设置安全参数m。建议实现将安全参数m设置为至少四十（40）的值，这将使需要四十次以上迭代的概率达到万亿分之一（1:10000000000）。
A database of salted passwords prevents an adversary who gains access to the database from learning the client's password; it does not prevent such an adversary from impersonating the client back to the server. Each side uses the salted password, called the base, as the authentication credential, so the database of salted passwords MUST be afforded the security of a database of plaintext passwords.
盐渍密码数据库防止获得数据库访问权限的对手学习客户的密码；它不会阻止这样的对手将客户端模拟回服务器。每一方都使用被称为base的salt密码作为身份验证凭证，因此salt密码数据库必须具有明文密码数据库的安全性。
Authentication is performed by proving knowledge of the password. Any third party that knows the password shared by the client and server can impersonate one to the other.
身份验证是通过证明知道密码来执行的。任何知道客户端和服务器共享的密码的第三方都可以相互模拟。
The static-ephemeral Diffie-Hellman exchange used to protect usernames requires the server to reuse its Diffie-Hellman public key. To prevent an "invalid curve" attack, an entity that reuses its Diffie-Hellman public key needs to check whether the received ephemeral public key is actually a point on the curve. This is done explicitly as part of the server's reconstruction of the client's public key out of only its x-coordinate ("compact representation").
用于保护用户名的静态临时Diffie-Hellman交换要求服务器重用其Diffie-Hellman公钥。为了防止“无效曲线”攻击，重用Diffie-Hellman公钥的实体需要检查收到的临时公钥是否实际上是曲线上的一个点。这是作为服务器仅从x坐标（“紧凑表示”）重建客户机公钥的一部分而明确完成的。
At the time of publication of this document, there was a growing interest in considering the impacts that IETF (and IRTF) work can have on human rights; some related research is discussed in [RFC8280]. As such, the human rights considerations of TLS-PWD are presented here.
在本文件出版时，人们越来越有兴趣考虑IETF（和IRTF）工作对人权的影响；[RFC8280]中讨论了一些相关研究。因此，这里介绍了TLS-PWD的人权考虑。
The key exchange underlying TLS-PWD uses public key cryptography to perform authentication and authenticated key exchange. The keys it produces can be used to establish secure connections between two people to protect their communication. Implementations of TLS-PWD, like implementations of other TLS ciphersuites that perform authentication and authenticated key establishment, are considered "armaments" or "munitions" by many governments around the world.
TLS-PWD底层的密钥交换使用公钥加密来执行身份验证和身份验证密钥交换。它产生的密钥可用于在两个人之间建立安全连接，以保护他们的通信。TLS-PWD的实现与执行身份验证和身份验证密钥建立的其他TLS密码套件的实现一样，被世界各地的许多政府视为“武器”或“弹药”。
The most fundamental of human rights is the right to protect oneself. The right to keep and bear arms is an example of this right. Implementations of TLS-PWD can be used as arms, kept and borne, to defend oneself against all manner of attackers -- criminals, governments, lawyers, etc. TLS-PWD is a powerful tool in the promotion and defense of universal human rights.
最基本的人权是保护自己的权利。持有和携带武器的权利就是这一权利的一个例子。TLS-PWD的实施可作为武器，随身携带，以抵御各种形式的攻击者——罪犯、政府、律师等。TLS-PWD是促进和捍卫普遍人权的有力工具。
The selection of the ciphersuite and selection of the particular finite cyclic group to use with the ciphersuite are divorced in this memo, but they remain intimately close.
在本备忘录中，密码套件的选择和与密码套件一起使用的特定有限循环群的选择是分离的，但它们仍然密切相关。
It is RECOMMENDED that implementations take note of the strength estimates of particular groups and select a ciphersuite providing commensurate security with its hash and encryption algorithms. A ciphersuite whose encryption algorithm has a keylength less than the strength estimate or whose hash algorithm has a block size that is less than twice the strength estimate SHOULD NOT be used.
建议实现注意特定组的强度估计，并选择一个密码套件，该套件通过其哈希和加密算法提供相应的安全性。不应使用加密算法的密钥长度小于强度估计值或哈希算法的块大小小于强度估计值两倍的密码套件。
For example, the elliptic curve named "brainpoolP256r1" (whose IANA-assigned number is 26) [RFC7027] provides an estimated 128 bits of strength and would be compatible with 1) an encryption algorithm supporting a key of that length and 2) a hash algorithm that has at least a 256-bit block size. Therefore, a suitable ciphersuite to use with brainpoolP256r1 could be TLS_ECCPWD_WITH_AES_128_GCM_SHA256 (see Appendix A for an example of such an exchange).
例如，名为“brainpoolP256r1”（其IANA分配号为26）[RFC7027]的椭圆曲线提供了估计的128位强度，并将与1）支持该长度密钥的加密算法和2）具有至少256位块大小的哈希算法兼容。因此，与brainpoolP256r1一起使用的合适密码套件可以是TLS_ECCPWD_with_AES_128_GCM_SHA256（此类交换示例见附录a）。
Resistance to dictionary attacks means that the attacker must launch an active attack to make a single guess at the password. If the size of the pool from which the password was extracted was D and each password in the pool has an equal probability of being chosen, then the probability of success after a single guess is 1/D. After X guesses and the removal of failed guesses from the pool of possible passwords, the probability becomes 1/(D-X). As X grows, so does the probability of success. Therefore, it is possible for an attacker to determine the password through repeated brute-force, active, guessing attacks. Implementations SHOULD take note of this fact and choose an appropriate pool of potential passwords -- i.e., make D big. Implementations SHOULD also take countermeasures -- for instance,
抵抗字典攻击意味着攻击者必须发起主动攻击才能猜测密码。如果提取密码的池的大小为D，且池中的每个密码被选择的概率相等，则单次猜测后的成功概率为1/D。在X次猜测并从可能的密码池中删除失败的猜测后，概率为1/（D-X）。随着X的增长，成功的概率也随之增加。因此，攻击者有可能通过反复的暴力、主动、猜测攻击来确定密码。实现应该注意这一事实，并选择一个合适的潜在密码池——即使D变大。实施还应采取应对措施，例如，
refusing authentication attempts by a particular username for a certain amount of time, after the number of failed authentication attempts reaches a certain threshold. No such threshold or amount of time is recommended in this memo.
在失败的身份验证尝试次数达到某个阈值后，在一定时间内拒绝特定用户名的身份验证尝试。本备忘录中不建议使用此类阈值或时间量。
[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>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 2008, <https://www.rfc-editor.org/info/rfc5297>.
[RFC5297]Harkins，D.“使用高级加密标准（AES）的合成初始化向量（SIV）认证加密”，RFC 5297，DOI 10.17487/RFC5297，2008年10月<https://www.rfc-editor.org/info/rfc5297>.
[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>.
[RFC5869]Krawczyk，H.和P.Eronen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，DOI 10.17487/RFC5869，2010年5月<https://www.rfc-editor.org/info/rfc5869>.
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10.17487/RFC7919, August 2016, <https://www.rfc-editor.org/info/rfc7919>.
[RFC7919]Gillmor，D.“传输层安全（TLS）的协商有限域Diffie-Hellman瞬时参数”，RFC 7919，DOI 10.17487/RFC7919，2016年8月<https://www.rfc-editor.org/info/rfc7919>.
[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>.
[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>.
[RFC8265]Saint Andre，P.和A.Melnikov，“代表用户名和密码的国际化字符串的准备、实施和比较”，RFC 8265，DOI 10.17487/RFC8265，2017年10月<https://www.rfc-editor.org/info/rfc8265>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>.
[RFC8422]Nir，Y.，Josefsson，S.，和M.Pegourie Gonnard，“传输层安全（TLS）版本1.2及更早版本的椭圆曲线密码（ECC）套件”，RFC 8422，DOI 10.17487/RFC8422，2018年8月<https://www.rfc-editor.org/info/rfc8422>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.
[RFC8447]Salowey，J.和S.Turner，“TLS和DTL的IANA注册更新”，RFC 8447，DOI 10.17487/RFC8447，2018年8月<https://www.rfc-editor.org/info/rfc8447>.
[TLS_REG] IANA, "Transport Layer Security (TLS) Parameters", <https://www.iana.org/assignments/tls-parameters/>.
[TLS_REG]IANA，“传输层安全（TLS）参数”<https://www.iana.org/assignments/tls-parameters/>.
[FIPS186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[FIPS186-4]国家标准与技术研究所，“数字签名标准（DSS）”，联邦信息处理标准出版物186-4，DOI 10.6028/NIST.FIPS.186-42013年7月<https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>。
[lanskro] Lancrenon, J. and M. Skrobot, "On the Provable Security of the Dragonfly Protocol", ISC 2015 Proceedings of the 18th International Conference on Information Security - Volume 9290, pp. 244-261, DOI 10.1007/978-3-319-23318-5_14, September 2015.
[lanskro]Lancrenon，J.和M.Skrobot，“关于蜻蜓协议的可证明安全性”，ISC 2015第18届信息安全国际会议记录，第9290卷，第244-261页，DOI 10.1007/978-3-319-23318-5Ö，2015年9月。
[RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: A Paradigm for Designing Efficient Protocols", Proceedings of the 1st ACM Conference on Computer and Communications Security, pp. 62-73, ACM Press, DOI 10.1145/168588.168596, November 1993.
[RANDOR]Bellare，M.和P.Rogaway，“随机预言是实用的：设计有效协议的范例”，《第一届ACM计算机和通信安全会议记录》，第62-73页，ACM出版社，DOI 10.1145/168588.168596，1993年11月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<https://www.rfc-editor.org/info/rfc4086>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/info/rfc6090>.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 6090，DOI 10.17487/RFC6090，2011年2月<https://www.rfc-editor.org/info/rfc6090>.
[RFC7027] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)", RFC 7027, DOI 10.17487/RFC7027, October 2013, <https://www.rfc-editor.org/info/rfc7027>.
[RFC7027]Merkle，J.和M.Lochter，“用于传输层安全（TLS）的椭圆曲线加密（ECC）脑池曲线”，RFC 7027，DOI 10.17487/RFC7027，2013年10月<https://www.rfc-editor.org/info/rfc7027>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.
[RFC7030]Pritikin，M.，Ed.，Yee，P.，Ed.，和D.Harkins，Ed.，“安全传输的注册”，RFC 7030，DOI 10.17487/RFC7030，2013年10月<https://www.rfc-editor.org/info/rfc7030>.
[RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI 10.17487/RFC7664, November 2015, <https://www.rfc-editor.org/info/rfc7664>.
[RFC7664]Harkins，D.，Ed.，“蜻蜓密钥交换”，RFC 7664，DOI 10.17487/RFC7664，2015年11月<https://www.rfc-editor.org/info/rfc7664>.
[RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, October 2017, <https://www.rfc-editor.org/info/rfc8280>.
[RFC8280]ten Oever，N.和C.Cath，“人权议定书考虑因素研究”，RFC 8280，DOI 10.17487/RFC8280，2017年10月<https://www.rfc-editor.org/info/rfc8280>.
[SP800-38A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation - Methods and Techniques", NIST Special Publication 800-38A, DOI 10.6028/NIST.SP.800-38A, December 2001, <https://nvlpubs.nist.gov/nistpubs/ Legacy/SP/nistspecialpublication800-38a.pdf>.
[SP800-38A]德沃金，M.，“分组密码操作模式的建议-方法和技术”，NIST特别出版物800-38A，DOI 10.6028/NIST.SP.800-38A，2001年12月<https://nvlpubs.nist.gov/nistpubs/ Legacy/SP/nistspecialpublication800-38a.pdf>。
[SP800-56A] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, Revision 3, DOI 10.6028/NIST.SP.800-56Ar3, April 2018, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar3.pdf>.
[SP800-56A]Barker，E.，Chen，L.，Roginsky，A.，Vassilev，A.，和R.Davis，“使用离散对数加密的成对密钥建立方案的建议”，NIST特别出版物800-56A，第3版，DOI 10.6028/NIST.SP.800-56Ar3，2018年4月<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar3.pdf>。
username: fred password: barney
用户名：fred密码：barney
---- prior to running TLS-PWD ----
---- prior to running TLS-PWD ----
server generates salt:
服务器生成盐：
96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3
96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3
and a base:
和一个基地：
6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28 c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75
6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28 c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75
---- state derived during the TLS-PWD exchange ----
---- state derived during the TLS-PWD exchange ----
client and server agree to use brainpoolP256r1
客户端和服务器同意使用brainpoolP256r1
client and server generate the PE:
客户端和服务器生成PE：
PE.x: 29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3 a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6
PE.x:29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3 a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6
server private and mask:
服务器专用和掩码：
private: 21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c mask: 0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5
私人：21 d9 9d 34 1c 97 b3 ae 72 df d2 89 97 1f 1b 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c面具：0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5
client private and mask:
客户端私有和掩码：
private: 17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b mask: 4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88 83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd
私人：17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b面具：4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd
both parties generate premaster secret and master secret
双方生成主密钥和主密钥
premaster secret: 01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11 af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4 master secret: 65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1 60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f 3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad
主秘密：01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11 af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4主秘密：65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1 60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f 3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad
---- ssldump output of exchange ----
---- ssldump output of exchange ----
New TCP connection #1: Charlene Client <-> Sammy Server 1 1 0.0018 (0.0018) C>SV3.3(173) Handshake ClientHello Version 3.3 random[32]= 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d ciphersuites TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV Unknown value 0xff compression methods NULL extensions TLS-PWD unprotected name[5]= 04 66 72 65 64 elliptic curve point format[4]= 03 00 01 02 elliptic curve list[58]= 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 Packet data[178]= 16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3 ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65 64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 01 01
新的TCP连接#1:Charlene客户端<->Sammy服务器1 1 0.0018（0.0018）C>SV3.3（173）握手客户端版本3.3 random[32]=52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d密码套件TLS_ECCPWD_带_AES_128_GCM_SHA256_PRIV TLS_ECCPWD_带_AES_256_GCM_SHA384_PRIV未知值0xff压缩方法空扩展TLS-PWD未保护名称[5]=04 66 72 64椭圆曲线点格式[4]=03 00 01 02椭圆曲线列表[58]=00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 00 10 00 11数据包数据[178]=16 03 03 00 ad 01 00 00 a9 03 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 06 ff b3 ff b4 00 ff 01 00 7a b8 aa 00 05 04 66 72 65 64 00 0b 00 04 00 00 00 01 00 0a 00 3a 00 38 00 E 00 00 00 00 0d 00 1c 00 19 00 0b 00 00 0b 00 0b 00 00 0b 00 01 00 1b 00 00 18 00 09 00 A 00 1a 00 16 00 17 00 08 00 00 06 00 07 00 14 00 15 0004 00 05 00 12 00 13 00 01 00 02 00 03 00 00 00 00 01 00 00 00 11 00 00 00 00 22 00 20 06 01 06 06 06 03 05 02 05 03 03 03 03 03 03 03 02 02 02 02 03 01 00 00 00 01
1 2 0.0043 (0.0024) S>CV3.3(94) Handshake ServerHello Version 3.3 random[32]= 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa session_id[32]= ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 cipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV compressionMethod NULL extensions renegotiate[1]= 00 elliptic curve point format[4]= 03 00 01 02 heartbeat[1]= 01 Packet data[99]= 16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f 00 01 01
1 2 0.0043（0.0024）S>CV3.3（94）握手服务器Hello版本3.3 random[32]=52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa会话id[32]=ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 0e 09 f0 73 d5 21 cf 9f bf 62 88密码套件TLS_ECCPWD_与_AES_128_GCM_SHA256_私有压缩方法空扩展重新协商[1]=00椭圆曲线点格式[4]=03 00 01 02心跳[1]=01数据包数据[99]=16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 70 72 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00 12 ff 01 00 01 00 00 00 00 00 00 00 00 00 00 01
1 3 0.0043 (0.0000) S>CV3.3(141) Handshake ServerKeyExchange params salt[32]= 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 EC parameters = 3 curve id = 26 element[65]= 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1 scalar[32]= 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21 Packet data[146]= 16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1 00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21
1 3 0.0043（0.0000）S>CV3.3（141）握手服务器密钥交换参数salt[32]=96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 EC参数=3曲线id=26元素[65]=04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 8a 07 78 de 50 6b 1b c3 88 ab c7 31 ee f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43是34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1标量[32]=2f 70 48 96 69 F c4 24 d3 ce c3 37 17 64 F 5a df 7f 68 48 34 ee 51 49 2b b9 66 fc 21数据包数据[146]=16 03 03 00 8d 0c 00 89 00 20 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 c2 1d 47 ce 6e 63 cd da 37 e4 7d a3 03 00 1a 41 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 8a 07 78 de 50 6b c3 88 ab c7 32 ee f3 7 F 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43是34 b9 28 83 d0 3d 6c d9 87 24 b1 20 2f 7048 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21
1 4 0.0043 (0.0000) S>CV3.3(4) Handshake ServerHelloDone Packet data[9]= 16 03 03 00 04 0e 00 00 00
1 4 0.0043（0.0000）S>CV3.3（4）握手服务器Hellodone数据包数据[9]=16 03 03 00 04 0e 00
1 5 0.0086 (0.0043) C>SV3.3(104) Handshake ClientKeyExchange element[65]= 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd a0 scalar[32]= 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 Packet data[109]= 16 03 03 00 68 10 00 00 64 41 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48
1 5 0.0086（0.0043）C>SV3.3（104）握手客户端密钥交换元素[65]=04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd d6 83 8d 92 fd 54 29 91 b2 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd a0标量[32]=66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48数据包数据[109]=16 03 00 68 10 00 64 41 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 42 42 42 8f cd 40 69 ae 08 E6 67 E7 7a
1 6 0.0086 (0.0000) C>SV3.3(1) ChangeCipherSpec Packet data[6]= 14 03 03 00 01 01
1 6 0.0086（0.0000）C>SV3.3（1）ChangeCipherSpec数据包数据[6]=14 03 00 01
1 7 0.0086 (0.0000) C>SV3.3(40) Handshake Packet data[45]= 16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7 0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a 0b 4b 70 f5 1f 39 c2 9c 7b 6c cc 57 20
1 7 0.0086（0.0000）C>SV3.3（40）握手数据包[45]=16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7 0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a 0b 70 f5 1f 39 c2 9c 7b 6c cc 57 20
1 8 0.0105 (0.0018) S>CV3.3(1) ChangeCipherSpec Packet data[6]= 14 03 03 00 01 01
1 8 0.0105（0.0018）S>CV3.3（1）ChangeCipherSpec数据包数据[6]=14 03 00 01
1 9 0.0105 (0.0000) S>CV3.3(40) Handshake Packet data[45]= 16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41 a2 21 94 90 12 72 23 18 24 21 c3 60 a4
1 9 0.0105（0.0000）S>CV3.3（40）握手数据包[45]=16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41 a2 21 94 90 12 72 23 18 24 c3 60 a4
1 10 0.0107 (0.0002) C>SV3.3(100) application_data
Packet data....
1 10 0.0107 (0.0002) C>SV3.3(100) application_data
Packet data....
Acknowledgements
致谢
The authenticated key exchange defined here has also been defined for use in 802.11 networks, as an Extensible Authentication Protocol (EAP) method, and as an authentication method for the Internet Key Exchange Protocol (IKE). Each of these specifications has elicited very helpful comments from a wide collection of people that have allowed the definition of the authenticated key exchange to be refined and improved.
这里定义的认证密钥交换也被定义为在802.11网络中使用，作为可扩展认证协议（EAP）方法，以及作为因特网密钥交换协议（IKE）的认证方法。这些规范中的每一个都从广泛的人群中得到了非常有用的意见，这些意见使得经过身份验证的密钥交换的定义得以细化和改进。
The author would like to thank Scott Fluhrer for discovering the "password as exponent" attack that was possible in an early version of this key exchange and for his very helpful suggestions on the techniques for fixing the PE to prevent it. The author would also like to thank Hideyuki Suzuki for his insight in discovering an attack against a previous version of the underlying key exchange protocol. Special thanks to Lily Chen for helpful discussions on hashing into an elliptic curve. Rich Davis suggested the defensive checks that are part of the processing of the ServerKeyExchange and ClientKeyExchange messages, and his various comments have greatly improved the quality of this memo and the underlying key exchange on which it is based.
作者要感谢Scott Fluhrer发现了此密钥交换早期版本中可能存在的“密码为指数”攻击，并就修复PE以防止其发生的技术提出了非常有用的建议。作者还要感谢Suzuki Hideyuki在发现针对基础密钥交换协议先前版本的攻击方面的洞察力。特别感谢Lily Chen对椭圆曲线散列的有益讨论。Rich Davis建议进行防御检查，这是ServerKeyExchange和ClientKeyExchange消息处理的一部分，他的各种评论极大地提高了此备忘录的质量及其所基于的底层密钥交换。
Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik discussed on the TLS mailing list the possibility of a side-channel attack against the hunting-and-pecking loop. That discussion prompted the addition of the security parameter, m, to the hunting-and-pecking loop. Scott Fluhrer suggested the blinding technique to test whether a value is a quadratic residue modulo a prime in a manner that does not leak information about the value being tested.
Martin Rex、Peter Gutmann、Marsh Ray和Rene Struik在TLS邮件列表中讨论了对狩猎和啄食环路进行旁道攻击的可能性。这一讨论促使将安全参数m添加到狩猎和啄食循环中。Scott Fluhrer提出了盲法技术来测试一个值是否是一个模素数的二次剩余，这种方法不会泄露有关被测试值的信息。
Author's Address
作者地址
Dan Harkins (editor) HP Enterprise 3333 Scott Blvd. Santa Clara, CA 95054 United States of America
Dan Harkins（编辑）斯科特大道3333号惠普企业。美国加利福尼亚州圣克拉拉95054
Email: dharkins@lounge.org
Email: dharkins@lounge.org