RFC 7919: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc7919
标题 : RFC 7919
翻译类型 : 自动生成

Internet Engineering Task Force (IETF)                        D. Gillmor
Request for Comments: 7919                                          ACLU
Updates: 2246, 4346, 4492, 5246                              August 2016
Category: Standards Track
ISSN: 2070-1721

Internet Engineering Task Force (IETF)                        D. Gillmor
Request for Comments: 7919                                          ACLU
Updates: 2246, 4346, 4492, 5246                              August 2016
Category: Standards Track
ISSN: 2070-1721

Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

传输层安全（TLS）的协商有限域Diffie-Hellman瞬时参数

Abstract

摘要

Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.

传统的传输层安全（TLS）握手过程中基于有限域的Diffie-Hellman（DH）密钥交换存在许多安全性、互操作性和效率缺陷。这些缺点产生于缺乏关于DH group参数TLS服务器应提供哪些参数以及客户端应接受哪些参数的明确性。本文件通过使用TLS“受支持的组注册表”（本文件从“EC命名曲线注册表”重命名）的一部分，建立具有已知结构的公共有限域DH参数，以及对等方协商对这些组的支持的机制，为兼容对等方提供了这些缺点的解决方案。

This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).

本文档更新了TLS版本1.0（RFC 2246）、1.1（RFC 4346）和1.2（RFC 5246）以及TLS椭圆曲线密码（ECC）扩展（RFC 4492）。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7919.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7919.

版权公告

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     1.2.  Vocabulary  . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Named Group Overview  . . . . . . . . . . . . . . . . . . . .   5
   3.  Client Behavior . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Client Local Policy on Custom Groups  . . . . . . . . . .   7
   4.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Optimizations . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Checking the Peer's Public Key  . . . . . . . . . . . . .   9
     5.2.  Short Exponents . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Table Acceleration  . . . . . . . . . . . . . . . . . . .  10
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .  10
     6.1.  Preference Ordering . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     8.1.  Negotiation Resistance to Active Attacks  . . . . . . . .  12
     8.2.  Group Strength Considerations . . . . . . . . . . . . . .  13
     8.3.  Finite Field DHE Only . . . . . . . . . . . . . . . . . .  13
     8.4.  Deprecating Weak Groups . . . . . . . . . . . . . . . . .  14
     8.5.  Choice of Groups  . . . . . . . . . . . . . . . . . . . .  14
     8.6.  Timing Attacks  . . . . . . . . . . . . . . . . . . . . .  14
     8.7.  Replay Attacks from Non-negotiated FFDHE  . . . . . . . .  15
     8.8.  Forward Secrecy . . . . . . . . . . . . . . . . . . . . .  15
     8.9.  False Start . . . . . . . . . . . . . . . . . . . . . . .  15
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  16
     9.1.  Client Fingerprinting . . . . . . . . . . . . . . . . . .  16
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  Supported Groups Registry (Formerly "EC Named Curve
                Registry") . . . . . . . . . . . . . . . . . . . . .  19
     A.1.  ffdhe2048 . . . . . . . . . . . . . . . . . . . . . . . .  19
     A.2.  ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . .  20
     A.3.  ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . .  22
     A.4.  ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . .  23
     A.5.  ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . .  26
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  29
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  29

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     1.2.  Vocabulary  . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Named Group Overview  . . . . . . . . . . . . . . . . . . . .   5
   3.  Client Behavior . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Client Local Policy on Custom Groups  . . . . . . . . . .   7
   4.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Optimizations . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Checking the Peer's Public Key  . . . . . . . . . . . . .   9
     5.2.  Short Exponents . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Table Acceleration  . . . . . . . . . . . . . . . . . . .  10
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .  10
     6.1.  Preference Ordering . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     8.1.  Negotiation Resistance to Active Attacks  . . . . . . . .  12
     8.2.  Group Strength Considerations . . . . . . . . . . . . . .  13
     8.3.  Finite Field DHE Only . . . . . . . . . . . . . . . . . .  13
     8.4.  Deprecating Weak Groups . . . . . . . . . . . . . . . . .  14
     8.5.  Choice of Groups  . . . . . . . . . . . . . . . . . . . .  14
     8.6.  Timing Attacks  . . . . . . . . . . . . . . . . . . . . .  14
     8.7.  Replay Attacks from Non-negotiated FFDHE  . . . . . . . .  15
     8.8.  Forward Secrecy . . . . . . . . . . . . . . . . . . . . .  15
     8.9.  False Start . . . . . . . . . . . . . . . . . . . . . . .  15
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  16
     9.1.  Client Fingerprinting . . . . . . . . . . . . . . . . . .  16
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  Supported Groups Registry (Formerly "EC Named Curve
                Registry") . . . . . . . . . . . . . . . . . . . . .  19
     A.1.  ffdhe2048 . . . . . . . . . . . . . . . . . . . . . . . .  19
     A.2.  ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . .  20
     A.3.  ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . .  22
     A.4.  ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . .  23
     A.5.  ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . .  26
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  29
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  29

1. Introduction

1. 介绍

Traditional TLS [RFC5246] offers a Diffie-Hellman Ephemeral (DHE) key exchange mode that provides forward secrecy for the connection. The client offers a cipher suite in the ClientHello that includes DHE, and the server offers the client group parameters generator g and modulus p. If the client does not consider the group strong enough (e.g., p is too small, p is not prime, or there are small subgroups that cannot be easily avoided) or if it is unable to process the group for other reasons, the client has no recourse but to terminate the connection.

传统的TLS[RFC5246]提供Diffie-Hellman临时（DHE）密钥交换模式，为连接提供前向保密性。客户端在ClientHello中提供一个密码套件，其中包括DHE，服务器提供客户端组参数生成器g和模数p。如果客户端不认为该组足够强（例如，P太小，P不是素数，或者存在不容易避免的小子组），或者如果由于其他原因无法处理该组，则客户端没有追索权，而是终止连接。

Conversely, when a TLS server receives a suggestion for a DHE cipher suite from a client, it has no way of knowing what kinds of DH groups the client is capable of handling or what the client's security requirements are for this key exchange session. For example, some widely distributed TLS clients are not capable of DH groups where p > 1024 bits. Other TLS clients may, by policy, wish to use DHE only if the server can offer a stronger group (and are willing to use a non-PFS (Perfect Forward Secrecy) key exchange mechanism otherwise). The server has no way of knowing which type of client is connecting but must select DH parameters with insufficient knowledge.

相反，当TLS服务器从客户端接收到关于DHE密码套件的建议时，它无法知道客户端能够处理什么类型的DH组，或者客户端对此密钥交换会话的安全要求是什么。例如，一些分布广泛的TLS客户机不支持p>1024位的DH组。根据策略，其他TLS客户端可能只希望在服务器能够提供更强的组（并且愿意使用非PFS（完美前向保密）密钥交换机制）的情况下使用DHE。服务器无法知道连接的是哪种类型的客户端，但必须在知识不足的情况下选择DH参数。

Additionally, the DH parameters selected by the server may have a known structure that renders them secure against a small subgroup attack, but a client receiving an arbitrary p and g has no efficient way to verify that the structure of a new group is reasonable for use.

此外，服务器选择的DH参数可能具有已知的结构，使得它们能够抵御小子组攻击，但是接收任意p和g的客户端无法有效地验证新组的结构是否合理。

This modification to TLS solves these problems by using a section of the "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to select common DH groups with known structure and defining the use of the "elliptic_curves(10)" extension (described here as the Supported Groups extension) for clients advertising support for DHE with these groups. This document also provides guidance for compatible peers to take advantage of the additional security, availability, and efficiency offered.

对TLS的这一修改通过使用“受支持组注册表”（本文件从“EC命名曲线注册表”重命名）的一部分来选择具有已知结构的常见DH组，并定义“椭圆曲线（10）”扩展（此处描述为受支持组扩展）的使用，从而解决了这些问题为客户在这些团体中宣传DHE支持。本文档还为兼容的对等方提供指导，以利用提供的额外安全性、可用性和效率。

The use of this mechanism by one compatible peer when interacting with a non-compatible peer should have no detrimental effects.

当一个兼容的对等方与一个不兼容的对等方交互时，该机制的使用应该不会产生有害影响。

This document updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246], as well as the TLS ECC extensions [RFC4492].

本文档更新了TLS版本1.0[RFC2246]、1.1[RFC4346]和1.2[RFC5246]，以及TLS ECC扩展[RFC4492]。

1.1. Requirements Language

1.1. 需求语言

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。

1.2. Vocabulary

1.2. 词汇

The terms "DHE" or "FFDHE" are used in this document to refer to the finite-field-based Diffie-Hellman ephemeral key exchange mechanism in TLS. TLS also supports Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchanges [RFC4492], but this document does not document their use. A registry previously used only by ECDHE-capable implementations is expanded in this document to cover FFDHE groups as well. "FFDHE cipher suites" is used in this document to refer exclusively to cipher suites with FFDHE key exchange mechanisms, but note that these suites are typically labeled with a TLS_DHE_ prefix.

本文档中使用的术语“DHE”或“FFDHE”是指TLS中基于有限域的Diffie-Hellman临时密钥交换机制。TLS还支持椭圆曲线Diffie-Hellman瞬时（ECDHE）密钥交换[RFC4492]，但本文档未记录它们的使用。以前仅由支持ECDHE的实现使用的注册表在本文档中进行了扩展，以涵盖FFDHE组。本文档中使用的“FFDHE密码套件”仅指具有FFDHE密钥交换机制的密码套件，但请注意，这些套件通常标有TLS_DHE_前缀。

2. Named Group Overview

2. 命名组概述

We use previously unallocated codepoints within the extension currently known as "elliptic_curves" (Section 5.1.1. of [RFC4492]) to indicate known finite field groups. The extension's semantics are expanded from "Supported Elliptic Curves" to "Supported Groups". The enum datatype used in the extension has been renamed from NamedCurve to NamedGroup. Its semantics are likewise expanded from "named curve" to "named group".

我们在当前称为“椭圆曲线”（RFC4492第5.1.1节）的扩展中使用先前未分配的码点来指示已知的有限域组。扩展的语义从“支持的椭圆曲线”扩展到“支持的群”。扩展中使用的枚举数据类型已从NamedCurve重命名为NamedGroup。它的语义同样从“命名曲线”扩展到“命名组”。

Additionally, we explicitly relax the requirement about when the Supported Groups extension can be sent. This extension MAY be sent by the client when either FFDHE or ECDHE cipher suites are listed.

此外，我们明确放宽了关于何时可以发送受支持的组扩展的要求。当列出FFDHE或ECDHE密码套件时，客户端可能会发送此扩展。

Codepoints in the "Supported Groups Registry" with a high byte of 0x01 (that is, between 256 and 511, inclusive) are set aside for FFDHE groups, though only a small number of them are initially defined and we do not expect many other FFDHE groups to be added to this range. No codepoints outside of this range will be allocated to FFDHE groups. The new codepoints for the "Supported Groups Registry" are:

“支持的组注册表”中高字节为0x01（即256到511之间，包括256和511）的代码点是为FFDHE组预留的，尽管最初只定义了少量代码点，我们不希望将许多其他FFDHE组添加到此范围。此范围之外的任何代码点都不会分配给FFDHE组。“受支持的组注册表”的新代码点为：

           enum {
           // other already defined elliptic curves (see RFC 4492)
               ffdhe2048(256), ffdhe3072(257), ffdhe4096(258),
               ffdhe6144(259), ffdhe8192(260),
           //
           } NamedGroup;

           enum {
           // other already defined elliptic curves (see RFC 4492)
               ffdhe2048(256), ffdhe3072(257), ffdhe4096(258),
               ffdhe6144(259), ffdhe8192(260),
           //
           } NamedGroup;

These additions to the "Supported Groups Registry" are described in detail in Appendix A. They are all safe primes derived from the base of the natural logarithm ("e"), with the high and low 64 bits set to 1 for efficient Montgomery or Barrett reduction.

附录A中详细描述了“受支持组注册表”中的这些添加项。它们都是从自然对数的底（“e”）派生的安全素数，高64位和低64位设置为1，以实现有效的Montgomery或Barrett归约。

The use of the base of the natural logarithm here is as a "nothing-up-my-sleeve" number. The goal is to guarantee that the bits in the middle of the modulus are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak according to some secret criteria. [RFC3526] used pi for this value. See Section 8.5 for reasons that this document does not reuse pi.

这里使用自然对数的底作为“袖子里没什么”的数字。目标是保证模数中间的位有效地随机，同时避免根据某些秘密标准秘密地选择素数弱的任何怀疑。[RFC3526]将pi用于该值。有关本文件不重复使用pi的原因，请参见第8.5节。

3. Client Behavior

3. 客户行为

A TLS client that is capable of using strong finite field Diffie-Hellman groups can advertise its capabilities and its preferences for stronger key exchange by using this mechanism.

能够使用强有限域Diffie-Hellman组的TLS客户机可以通过使用此机制宣传其功能和偏好，以实现更强的密钥交换。

The compatible client that wants to be able to negotiate strong FFDHE sends a Supported Groups extension (identified by type elliptic_curves(10) in [RFC4492]) in the ClientHello and includes a list of known FFDHE groups in the extension data, ordered from most preferred to least preferred. If the client also supports and wants to offer ECDHE key exchange, it MUST use a single Supported Groups extension to include all supported groups (both ECDHE and FFDHE groups). The ordering SHOULD be based on client preference, but see Section 6.1 for more nuance.

希望能够协商强FFDHE的兼容客户端在ClientHello中发送受支持的组扩展（由[RFC4492]中的椭圆曲线（10）类型标识），并在扩展数据中包括已知FFDHE组的列表，按从最优先到最不优先的顺序排列。如果客户端还支持并希望提供ECDHE密钥交换，则必须使用单个受支持的组扩展来包括所有受支持的组（ECDHE和FFDHE组）。订购应基于客户偏好，但更多细节请参见第6.1节。

A client that offers a Supported Groups extension containing an FFDHE group SHOULD also include at least one FFDHE cipher suite in the ClientHello.

提供包含FFDHE组的受支持组扩展的客户端还应在ClientHello中至少包含一个FFDHE密码套件。

A client that offers a group MUST be able and willing to perform a DH key exchange using that group.

提供组的客户端必须能够并愿意使用该组执行DH密钥交换。

A client that offers one or more FFDHE groups in the Supported Groups extension and an FFDHE cipher suite and that receives an FFDHE cipher suite from the server SHOULD take the following steps upon receiving the ServerKeyExchange:

在受支持的组扩展和FFDHE密码套件中提供一个或多个FFDHE组并从服务器接收FFDHE密码套件的客户端在接收到ServerKeyExchange后应采取以下步骤：

o For non-anonymous cipher suites where the offered certificate is valid and appropriate for the peer, validate the signature over the ServerDHParams. If not valid, terminate the connection.

o 对于提供的证书有效且适用于对等方的非匿名密码套件，请通过ServerDHParams验证签名。如果无效，请终止连接。

o If the signature over ServerDHParams is valid, compare the selected dh_p and dh_g with the FFDHE groups offered by the client. If none of the offered groups match, the server is not compatible with this document. The client MAY decide to continue the connection if the selected group is acceptable under local policy, or it MAY decide to terminate the connection with a fatal insufficient_security(71) alert.

o 如果ServerDHParams上的签名有效，请将所选dh_p和dh_g与客户端提供的FFDHE组进行比较。如果提供的组均不匹配，则服务器与此文档不兼容。如果所选组在本地策略下是可接受的，则客户端可以决定继续连接，也可以决定使用致命的安全性不足（71）警报终止连接。

o If the client continues (either because the server offered a matching group or because local policy permits the offered custom group), the client MUST verify that dh_Ys is in the range 1 < dh_Ys < dh_p - 1. If dh_Ys is not in this range, the client MUST terminate the connection with a fatal handshake_failure(40) alert.

o 如果客户端继续（因为服务器提供了匹配的组，或者因为本地策略允许提供的自定义组），客户端必须验证dh_Ys是否在范围1<dh_Ys<dh_p-1内。如果dh_Ys不在此范围内，则客户端必须使用致命握手失败（40）警报终止连接。

o If dh_Ys is in range, then the client SHOULD continue with the connection as usual.

o 如果dh_Ys在范围内，则客户端应像往常一样继续连接。

3.1. Client Local Policy on Custom Groups

3.1. 自定义组上的客户端本地策略

Compatible clients that are willing to accept FFDHE cipher suites from non-compatible servers may have local policy about what custom FFDHE groups they are willing to accept. This local policy presents a risk to clients, who may accept weakly protected communications from misconfigured servers.

愿意接受来自不兼容服务器的FFDHE密码套件的兼容客户端可能有关于其愿意接受的自定义FFDHE组的本地策略。此本地策略会给客户端带来风险，客户端可能会接受来自配置错误的服务器的弱保护通信。

This document cannot enumerate all possible safe local policy (the safest may be to simply reject all custom groups), but compatible clients that accept some custom groups from the server MUST do at least cursory checks on group size and may take other properties into consideration as well.

此文档无法枚举所有可能的安全本地策略（最安全的方法可能是简单地拒绝所有自定义组），但从服务器接受某些自定义组的兼容客户端必须至少粗略检查组大小，并可能考虑其他属性。

A compatible client that accepts FFDHE cipher suites using custom groups from non-compatible servers MUST reject any group with |dh_p| < 768 bits and SHOULD reject any group with |dh_p| < 1024 bits.

使用来自不兼容服务器的自定义组接受FFDHE密码套件的兼容客户端必须拒绝任何| dh|u p |<768位的组，并且应拒绝任何| dh|u p |<1024位的组。

A compatible client that rejects a non-compatible server's custom group may decide to retry the connection while omitting all FFDHE cipher suites from the ClientHello. A client SHOULD only use this approach if it successfully verified the server's expected signature over the ServerDHParams, to avoid being forced by an active attacker into a non-preferred cipher suite.

拒绝不兼容服务器的自定义组的兼容客户端可能决定重试连接，同时从ClientHello中忽略所有FFDHE密码套件。只有当客户端通过ServerDHParams成功验证了服务器的预期签名时，才应使用此方法，以避免被活动攻击者强制进入非首选密码套件。

4. Server Behavior

4. 服务器行为

If a compatible TLS server receives a Supported Groups extension from a client that includes any FFDHE group (i.e., any codepoint between 256 and 511, inclusive, even if unknown to the server), and if none of the client-proposed FFDHE groups are known and acceptable to the server, then the server MUST NOT select an FFDHE cipher suite. In this case, the server SHOULD select an acceptable non-FFDHE cipher suite from the client's offered list. If the extension is present with FFDHE groups, none of the client's offered groups are acceptable by the server, and none of the client's proposed non-FFDHE cipher suites are acceptable to the server, the server MUST end the connection with a fatal TLS alert of type insufficient_security(71).

如果兼容TLS服务器从包含任何FFDHE组（即，256和511之间的任何代码点，即使服务器未知）的客户端接收到受支持的组扩展，并且如果服务器不知道和接受任何客户端建议的FFDHE组，则服务器不得选择FFDHE密码套件。在这种情况下，服务器应该从客户端提供的列表中选择一个可接受的非FFDHE密码套件。如果扩展与FFDHE组一起存在，则服务器不接受客户端提供的组，并且服务器不接受客户端建议的非FFDHE密码套件，则服务器必须使用类型为“安全性不足”（71）的致命TLS警报结束连接。

If at least one FFDHE cipher suite is present in the client cipher suite list and the Supported Groups extension is either absent from the ClientHello entirely or contains no FFDHE groups (i.e., no codepoints between 256 and 511, inclusive), then the server knows that the client is not compatible with this document. In this scenario, a server MAY select a non-FFDHE cipher suite, or it MAY select an FFDHE cipher suite and offer an FFDHE group of its choice to the client as part of a traditional ServerKeyExchange.

如果客户机密码套件列表中至少存在一个FFDHE密码套件，并且受支持的组扩展插件完全不在ClientHello中，或者不包含FFDHE组（即256和511之间没有代码点，包括256和511），则服务器知道客户机与此文档不兼容。在这种情况下，服务器可以选择非FFDHE密码套件，也可以选择FFDHE密码套件并将其选择的FFDHE组作为传统ServerKeyExchange的一部分提供给客户端。

A compatible TLS server that receives the Supported Groups extension with FFDHE codepoints in it and that selects an FFDHE cipher suite MUST select one of the client's offered groups. The server indicates the choice of group to the client by sending the group's parameters as usual in the ServerKeyExchange as described in Section 7.4.3 of [RFC5246].

接收包含FFDHE代码点的受支持组扩展并选择FFDHE密码套件的兼容TLS服务器必须选择客户端提供的组之一。如[RFC5246]第7.4.3节所述，服务器通过在ServerKeyExchange中像往常一样发送组参数来向客户端指示组的选择。

A TLS server MUST NOT select a named FFDHE group that was not offered by a compatible client.

TLS服务器不得选择不由兼容客户端提供的命名FFDHE组。

A TLS server MUST NOT select an FFDHE cipher suite if the client did not offer one, even if the client offered an FFDHE group in the Supported Groups extension.

如果客户端未提供FFDHE密码套件，则TLS服务器不得选择FFDHE密码套件，即使客户端在受支持的组扩展中提供了FFDHE组。

If a non-anonymous FFDHE cipher suite is selected and the TLS client has used this extension to offer an FFDHE group of comparable or greater strength than the server's public key, the server SHOULD select an FFDHE group at least as strong as the server's public key. For example, if the server has a 3072-bit RSA key and the client offers only ffdhe2048 and ffdhe4096, the server SHOULD select ffdhe4096.

如果选择了非匿名FFDHE密码套件，并且TLS客户端已使用此扩展提供与服务器公钥强度相当或更高的FFDHE组，则服务器应选择至少与服务器公钥强度相同的FFDHE组。例如，如果服务器具有3072位RSA密钥，而客户端仅提供ffdhe2048和ffdhe4096，则服务器应选择ffdhe4096。

When an FFDHE cipher suite is selected and the client sends a ClientKeyExchange, the server MUST verify that 1 < dh_Yc < dh_p - 1. If dh_Yc is out of range, the server MUST terminate the connection with a fatal handshake_failure(40) alert.

当选择FFDHE密码套件并且客户端发送ClientKeyExchange时，服务器必须验证1<dh_Yc<dh_p-1。如果dh_Yc超出范围，服务器必须通过致命握手失败（40）警报终止连接。

5. Optimizations

5. 优化

In a key exchange with a successfully negotiated known FFDHE group, both peers know that the group in question uses a safe prime as a modulus and that the group in use is of size p-1 or (p-1)/2. This allows at least three optimizations that can be used to improve performance.

在与成功协商的已知FFDHE组的密钥交换中，两个对等方都知道所讨论的组使用安全素数作为模，并且所使用的组的大小为p-1或（p-1）/2。这允许至少进行三次优化，以提高性能。

5.1. Checking the Peer's Public Key

5.1. 检查对等方的公钥

Peers MUST validate each other's public key Y (dh_Ys offered by the server or dh_Yc offered by the client) by ensuring that 1 < Y < p-1. This simple check ensures that the remote peer is properly behaved and isn't forcing the local system into the 2-element subgroup.

对等方必须通过确保1<Y<p-1来验证彼此的公钥Y（服务器提供的dh_Ys或客户端提供的dh_Yc）。这个简单的检查确保远程对等机的行为正确，并且不会强制本地系统进入2元素子组。

To reach the same assurance with an unknown group, the client would need to verify the primality of the modulus, learn the factors of p-1, and test both the generator g and Y against each factor to avoid small subgroup attacks.

为了对未知组达到相同的保证，客户需要验证模的素性，了解p-1的因子，并针对每个因子测试生成器g和Y，以避免小的子组攻击。

5.2. Short Exponents

5.2. 短指数

Traditional finite field Diffie-Hellman has each peer choose their secret exponent from the range [2, p-2]. Using exponentiation by squaring, this means each peer must do roughly 2*log_2(p) multiplications, twice (once for the generator and once for the peer's public key).

传统的有限域Diffie-Hellman让每个节点从[2，p-2]范围内选择其秘密指数。使用平方求幂，这意味着每个对等方必须进行大约2*log_2（p）乘法，两次（一次用于生成器，一次用于对等方的公钥）。

Peers concerned with performance may also prefer to choose their secret exponent from a smaller range, doing fewer multiplications, while retaining the same level of overall security. Each named group indicates its approximate security level and provides a lower bound on the range of secret exponents that should preserve it. For example, rather than doing 2*2*3072 multiplications for an ffdhe3072 handshake, each peer can choose to do 2*2*275 multiplications by choosing their secret exponent from the range [2^274, 2^275] (that is, an m-bit integer where m is at least 275) and still keep the same approximate security level.

关心性能的对等方也可能更喜欢从较小的范围内选择其秘密指数，进行较少的乘法运算，同时保持相同的总体安全性水平。每个命名组指示其近似安全级别，并提供应保留该组的秘密指数范围的下限。例如，与对ffdhe3072握手执行2*2*3072乘法不同，每个对等方可以通过从范围[2^274，2^275]（即m位整数，其中m至少为275）中选择其秘密指数来选择执行2*2*275乘法，并且仍然保持相同的近似安全级别。

A similar short-exponent approach is suggested in a Secure SHell (SSH) Diffie-Hellman key exchange (see Section 6.2 of [RFC4419]).

在安全SHell（SSH）Diffie-Hellman密钥交换中建议使用类似的短指数方法（参见[RFC4419]第6.2节）。

5.3. Table Acceleration

5.3. 表加速度

Peers wishing to further accelerate FFDHE key exchange can also pre-compute a table of powers of the generator of a known group. This is a memory vs. time trade-off, and it only accelerates the first exponentiation of the ephemeral DH exchange (the fixed-base exponentiation). The variable-base exponentiation (using the peer's public exponent as a base) still needs to be calculated as normal.

希望进一步加速FFDHE密钥交换的对等方还可以预先计算已知组的生成器的幂表。这是内存与时间的折衷，它只会加速短暂DH交换的第一次幂运算（固定基幂运算）。可变基数的求幂（使用对等方的公共指数作为基数）仍然需要按正常方式计算。

6. Operational Considerations

6. 业务考虑

6.1. Preference Ordering

6.1. 优先顺序

The ordering of named groups in the Supported Groups extension may contain some ECDHE groups and some FFDHE groups. These SHOULD be ranked in the order preferred by the client.

受支持组扩展中命名组的顺序可能包含一些ECDHE组和一些FFDHE组。这些应按照客户首选的顺序排列。

However, the ClientHello also contains a list of desired cipher suites, also ranked in preference order. This presents the possibility of conflicted preferences. For example, if the ClientHello contains a cipher_suite field with two choices in order <TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA> and the Supported Groups extension contains two choices in order <secp256r1,ffdhe3072>, then there is a clear contradiction. Clients SHOULD NOT present such a contradiction since it does not represent a sensible ordering. A server that encounters such a contradiction when selecting between an ECDHE or FFDHE key exchange mechanism while trying to respect client preferences SHOULD give priority to the Supported Groups extension (in the example case, it should select TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with secp256r1) but MAY resolve the contradiction any way it sees fit.

但是，ClientHello还包含所需密码套件的列表，这些密码套件也按优先顺序排列。这可能导致偏好冲突。例如，如果ClientHello包含一个具有两个选项的密码套件字段，顺序为<TLS\u DHE\u RSA\u with_AES\u 128\u CBC\u SHA，TLS\u ECDHE\u RSA\u with_AES\u 128\u CBC\u SHA>，并且受支持的组扩展包含两个选项，顺序为<secp256r1，ffdhe3072>，则存在明显的矛盾。客户不应出现这种矛盾，因为这并不代表合理的订购。在尝试尊重客户端首选项的同时在选择ECDHE或FFDHE密钥交换机制时遇到这种矛盾的服务器应优先考虑受支持的组扩展（在示例中，它应选择TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA WITH secp256r1）但可能会以其认为合适的任何方式解决矛盾。

More subtly, clients MAY interleave preferences between ECDHE and FFDHE groups; for example, if stronger groups are preferred regardless of cost, but weaker groups are acceptable, the Supported Groups extension could consist of <ffdhe8192,secp384p1,ffdhe3072,secp256r1>. In this example, with the same cipher_suite field offered as the previous example, a server configured to respect client preferences and with support for all listed groups SHOULD select TLS_DHE_RSA_WITH_AES_128_CBC_SHA with ffdhe8192. A server configured to respect client preferences and with support for only secp384p1 and ffdhe3072 SHOULD select TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with secp384p1.

更微妙的是，客户可以在ECDHE和FFDHE组之间交错选择偏好；例如，如果不管成本如何，优先选择更强的组，但可以接受较弱的组，则支持的组扩展可以包括<ffdhe8192、secp384p1、ffdhe3072、secp256r1>。在此示例中，使用与前一示例相同的cipher_suite字段，配置为尊重客户端首选项并支持所有列出的组的服务器应选择TLS_DHE_RSA_with_AES_128_CBC_SHA with ffdhe8192。配置为尊重客户端首选项并仅支持secp384p1和ffdhe3072的服务器应选择TLS_ECDHE_RSA_with_AES_128_CBC_SHA with secp384p1。

7. IANA Considerations

7. IANA考虑

This document renames the "EC Named Curve Registry" (originally defined in [RFC4492] and updated by [RFC7027]) to the "Supported Groups Registry". See <https://www.iana.org/assignments/tls-parameters>.

本文档将“EC命名曲线注册表”（最初在[RFC4492]中定义，并由[RFC7027]更新）重命名为“受支持的组注册表”。看<https://www.iana.org/assignments/tls-parameters>.

This document expands the semantics of this registry to include groups based on finite fields in addition to groups based on elliptic curves. IANA has added a range designation to the registry, indicating that values from 256-511 (inclusive) are set aside for "Finite Field Diffie-Hellman groups" and that all other entries in the registry are "Elliptic curve groups".

本文档扩展了该注册表的语义，除了基于椭圆曲线的组之外，还包括基于有限域的组。IANA在注册表中添加了一个范围名称，表示256-511（含256-511）的值被预留给“有限域Diffie-Hellman组”，注册表中的所有其他项都是“椭圆曲线组”。

This document allocates five well-defined codepoints in the registry for specific finite field Diffie-Hellman groups defined in Appendix A.

本文档在注册表中为附录A中定义的特定有限域Diffie-Hellman组分配五个定义良好的代码点。

In addition, the four highest codepoints in the range 508-511, inclusive, are designated for Private Use [RFC5226] by peers who have privately developed finite field Diffie-Hellman groups that they wish to signal internally.

此外，508-511范围内（含508-511）的四个最高码点被私人开发有限域Diffie-Hellman组的同行指定为私人使用[RFC5226]，他们希望在内部发出信号。

The updated registry section is as follows:

更新的注册表部分如下：

   +---------+-------------+---------+-----------+
   | Value   | Description | DTLS-OK | Reference |
   +---------+-------------+---------+-----------+
   | 256     | ffdhe2048   | Y       | RFC 7919  |
   | 257     | ffdhe3072   | Y       | RFC 7919  |
   | 258     | ffdhe4096   | Y       | RFC 7919  |
   | 259     | ffdhe6144   | Y       | RFC 7919  |
   | 260     | ffdhe8192   | Y       | RFC 7919  |
   | 508-511 | Private Use | -       | RFC 7919  |
   +---------+-------------+---------+-----------+

   +---------+-------------+---------+-----------+
   | Value   | Description | DTLS-OK | Reference |
   +---------+-------------+---------+-----------+
   | 256     | ffdhe2048   | Y       | RFC 7919  |
   | 257     | ffdhe3072   | Y       | RFC 7919  |
   | 258     | ffdhe4096   | Y       | RFC 7919  |
   | 259     | ffdhe6144   | Y       | RFC 7919  |
   | 260     | ffdhe8192   | Y       | RFC 7919  |
   | 508-511 | Private Use | -       | RFC 7919  |
   +---------+-------------+---------+-----------+

IANA has also renamed the "elliptic_curves" extension as "supported_groups" and added a reference to this document in the "ExtensionType Values" registry. See <http://www.iana.org/assignments/tls-extensiontype-values>.

IANA还将“椭圆曲线”扩展名重命名为“受支持的组”，并在“ExtensionType值”注册表中添加了对该文档的引用。看<http://www.iana.org/assignments/tls-extensiontype-values>.

8. Security Considerations

8. 安全考虑

8.1. Negotiation Resistance to Active Attacks

8.1. 对抗主动攻击的协商

Because the contents of the Supported Groups extension are hashed in the Finished message, an active Man in the Middle (MITM) that tries to filter or omit groups will cause the handshake to fail, but possibly not before getting the peer to do something it would not otherwise have done.

因为所支持的组扩展的内容在完成的消息中被哈希，中间的活跃的中间人（MITM）试图过滤或省略组将导致握手失败，但可能不在使对等人做不应该做的事情之前。

An attacker who impersonates the server can try to do any of the following:

模拟服务器的攻击者可以尝试执行以下任一操作：

o Pretend that a non-compatible server is actually capable of this extension and select a group from the client's list, causing the client to select a group it is willing to negotiate. It is unclear how this would be an effective attack.

o 假设一个不兼容的服务器实际上能够进行此扩展，并从客户端列表中选择一个组，使客户端选择一个它愿意协商的组。目前尚不清楚这将如何成为一次有效的攻击。

o Pretend that a compatible server is actually non-compatible by negotiating a non-FFDHE cipher suite. This is no different than MITM cipher suite filtering.

o 通过协商非FFDHE密码套件，假装兼容的服务器实际上是不兼容的。这与MITM密码套件过滤没有什么不同。

o Pretend that a compatible server is actually non-compatible by negotiating a DHE cipher suite with a custom (perhaps weak) group selected by the attacker. This is no worse than the current scenario and would require the attacker to be able to sign the ServerDHParams, which should not be possible without access to the server's secret key.

o 通过与攻击者选择的自定义（可能较弱）组协商DHE密码套件，假装兼容服务器实际上不兼容。这并不比当前的情况更糟，并且需要攻击者能够对ServerDHParams进行签名，如果不访问服务器的密钥，这应该是不可能的。

An attacker who impersonates the client can try to do the following:

模拟客户端的攻击者可以尝试执行以下操作：

o Pretend that a compatible client is not compatible (e.g., by not offering the Supported Groups extension or by replacing the Supported Groups extension with one that includes no FFDHE groups). This could cause the server to negotiate a weaker DHE group during the handshake or to select a non-FFDHE cipher suite, but it would fail to complete during the final check of the Finished message.

o 假装兼容的客户端不兼容（例如，不提供受支持的组扩展，或将受支持的组扩展替换为不包含FFDHE组的扩展）。这可能会导致服务器在握手过程中协商较弱的DHE组或选择非FFDHE密码套件，但在完成消息的最终检查过程中无法完成。

o Pretend that a non-compatible client is compatible (e.g., by adding the Supported Groups extension or by adding FFDHE groups to the extension). This could cause the server to select a particular named group in the ServerKeyExchange or to avoid selecting an FFDHE cipher suite. The peers would fail to compute the final check of the Finished message.

o 假设不兼容的客户端是兼容的（例如，通过添加受支持的组扩展或向扩展添加FFDHE组）。这可能导致服务器在ServerKeyExchange中选择特定的命名组，或避免选择FFDHE密码套件。对等方将无法计算完成消息的最终检查。

o Change the list of groups offered by the client (e.g., by removing the stronger of the set of groups offered). This could cause the server to negotiate a weaker group than desired, but again, should be caught by the check in the Finished message.

o 更改客户提供的组列表（例如，删除所提供组中的强组）。这可能会导致服务器协商一个弱于预期的组，但同样，应该在完成的消息中进行检查。

8.2. Group Strength Considerations

8.2. 团体实力考虑

TLS implementations using FFDHE key exchange should consider the strength of the group they negotiate. The strength of the selected group is one of the factors that define the connection's resilience against attacks on the session's confidentiality and integrity, since the session keys are derived from the DHE handshake.

使用FFDHE密钥交换的TLS实现应该考虑它们所协商的组的强度。所选组的强度是定义连接抵抗会话机密性和完整性攻击的能力的因素之一，因为会话密钥来自DHE握手。

While attacks on integrity must generally happen while the session is in progress, attacks against session confidentiality can happen significantly later if the entire TLS session is stored for offline analysis. Therefore, FFDHE groups should be selected by clients and servers based on confidentiality guarantees they need. Sessions that need extremely long-term confidentiality should prefer stronger groups.

虽然对完整性的攻击通常必须在会话进行过程中发生，但如果整个TLS会话被存储以供脱机分析，则对会话机密性的攻击可能会在稍后发生。因此，客户机和服务器应根据其所需的保密性保证来选择FFDHE组。需要长期保密的会议应该选择更强大的团队。

[ENISA] provides rough estimates of group resistance to attack and recommends that forward-looking implementations ("future systems") should use FFDHE group sizes of at least 3072 bits. ffdhe3072 is intended for use in these implementations.

[ENISA]提供了对组抗攻击能力的粗略估计，并建议前瞻性实施（“未来系统”）应使用至少3072位的FFDHE组大小。ffdhe3072旨在用于这些实现中。

Other sources (e.g., [NIST]) estimate the security levels of the Discrete Log (DLOG) problem to be slightly more difficult than [ENISA]. This document's suggested minimum exponent sizes in Appendix A for implementations that use the short-exponent optimization (Section 5.2) are deliberately conservative to account for the range of these estimates.

其他来源（如[NIST]）估计离散日志（DLOG）问题的安全级别比[ENISA]稍难。本文件附录A中针对使用短指数优化（第5.2节）的实施建议的最小指数大小有意保守，以说明这些估计的范围。

8.3. Finite Field DHE Only

8.3. 仅有限域DHE

Note that this document specifically targets only finite field Diffie-Hellman ephemeral key exchange mechanisms. It does not cover the non-ephemeral DH key exchange mechanisms, nor does it address ECDHE key exchange, which is defined in [RFC4492].

请注意，本文档专门针对有限域Diffie-Hellman临时密钥交换机制。它不包括非临时DH密钥交换机制，也不涉及[RFC4492]中定义的ECDHE密钥交换。

Measured by computational cost to the TLS peers, ECDHE appears today to offer a much stronger key exchange mechanism than FFDHE.

以TLS对等方的计算成本衡量，ECDHE今天似乎比FFDHE提供了更强的密钥交换机制。

8.4. Deprecating Weak Groups

8.4. 贬低弱势群体

Advances in hardware or in finite field cryptanalysis may cause some of the negotiated groups to not provide the desired security margins, as indicated by the estimated work factor of an adversary to discover the premaster secret (and may therefore compromise the confidentiality and integrity of the TLS session).

硬件或有限域密码分析方面的进步可能导致某些协商组无法提供所需的安全余量，如对手发现主前秘密的估计工作系数所示（因此可能危及TLS会话的机密性和完整性）。

Revisions of this document should mark known weak groups as explicitly deprecated for use in TLS and should update the estimated work factor needed to break the group if the cryptanalysis has changed. Implementations that require strong confidentiality and integrity guarantees should avoid using deprecated groups and should be updated when the estimated security margins are updated.

本文档的修订版应将已知的弱组标记为明确不推荐在TLS中使用，并应在密码分析发生更改时更新中断该组所需的估计工作系数。需要严格保密性和完整性保证的实现应避免使用不推荐的组，并应在更新估计的安全余量时进行更新。

8.5. Choice of Groups

8.5. 群体选择

Other lists of named finite field Diffie-Hellman groups [STRONGSWAN-IKE] exist. This document chooses to not reuse them for several reasons:

存在命名有限域Diffie-Hellman群[STRONGSWAN-IKE]的其他列表。由于以下几个原因，本文档选择不重用它们：

o Using the same groups in multiple protocols increases the value for an attacker with the resources to crack any single group.

o 在多个协议中使用相同的组会增加攻击者破解任何单个组的资源的价值。

o The Internet Key Exchange Protocol (IKE) groups include weak groups like MODP768 that are unacceptable for secure TLS traffic.

o Internet密钥交换协议（IKE）组包括对安全TLS通信不可接受的弱组，如MODP768。

o Mixing group parameters across multiple implementations leaves open the possibility of some sort of cross-protocol attack. This shouldn't be relevant for ephemeral scenarios, and even with non-ephemeral keying, services shouldn't share keys; however, using different groups avoids these failure modes entirely.

o 在多个实现中混合组参数可能导致某种跨协议攻击。这与短暂的场景无关，即使使用非短暂的键控，服务也不应该共享键；但是，使用不同的组可以完全避免这些故障模式。

8.6. Timing Attacks

8.6. 定时攻击

Any implementation of finite field Diffie-Hellman key exchange should use constant-time modular-exponentiation implementations. This is particularly true for those implementations that ever reuse DHE secret keys (so-called "semi-static" ephemeral keying) or share DHE secret keys across a multiple machines (e.g., in a load-balancer situation).

有限域Diffie-Hellman密钥交换的任何实现都应该使用常数时间模幂实现。对于那些重用DHE密钥（所谓的“半静态”临时密钥）或在多台机器上共享DHE密钥（例如，在负载平衡器情况下）的实现来说，这尤其正确。

8.7. Replay Attacks from Non-negotiated FFDHE

8.7. 来自非协商FFDHE的重播攻击

[SECURE-RESUMPTION], [CROSS-PROTOCOL], and [SSL3-ANALYSIS] all show a malicious peer using a bad FFDHE group to maneuver a client into selecting a premaster secret of the peer's choice, which can be replayed to another server using a non-FFDHE key exchange and can then be bootstrapped to replay client authentication.

[安全恢复]、[跨协议]和[SSL3-ANALYSIS]都显示恶意对等方使用错误的FFDHE组操纵客户端选择对等方选择的主密钥，该密钥可以使用非FFDHE密钥交换重播到另一台服务器，然后可以引导以重播客户端身份验证。

To prevent this attack (barring the session hash fix documented in [RFC7627]), a client would need not only to implement this document, but also to reject non-negotiated FFDHE cipher suites whose group structure it cannot afford to verify. Such a client would need to abort the initial handshake and reconnect to the server in question without listing any FFDHE cipher suites on the subsequent connection.

为了防止此攻击（除了[RFC7627]中记录的会话哈希修复），客户端不仅需要实现此文档，还需要拒绝其无法验证组结构的未协商FFDHE密码套件。这样的客户端需要中止初始握手并重新连接到相关服务器，而不在后续连接中列出任何FFDHE密码套件。

This trade-off may be too costly for most TLS clients today but may be a reasonable choice for clients performing client certificate authentication or for clients who have other reasons to be concerned about server-controlled premaster secrets.

这一权衡对于当今的大多数TLS客户端来说可能代价太高，但对于执行客户端证书身份验证的客户端或出于其他原因担心服务器控制的主机前机密的客户端来说，这可能是一个合理的选择。

8.8. Forward Secrecy

8.8. 正向安全

One of the main reasons to prefer FFDHE ciphersuites is forward secrecy, the ability to resist decryption even if the endpoint's long-term secret key (usually RSA) is revealed in the future.

选择FFDHE密码套件的主要原因之一是前向保密性，即即使端点的长期密钥（通常是RSA）在将来被泄露，也能抵抗解密的能力。

This property depends on both sides of the connection discarding their ephemeral keys promptly. Implementations should wipe their FFDHE secret key material from memory as soon as it is no longer needed and should never store it in persistent storage.

此属性依赖于连接的两侧迅速丢弃其临时密钥。一旦不再需要FFDHE密钥材料，实现应该立即从内存中擦除该材料，并且永远不要将其存储在持久性存储器中。

Forward secrecy also depends on the strength of the Diffie-Hellman group; using a very strong symmetric cipher like AES256 with a forward-secret cipher suite but generating the keys with a much weaker group like dhe2048 simply moves the adversary's cost from attacking the symmetric cipher to attacking the dh_Ys or dh_Yc ephemeral key shares.

前向保密还取决于Diffie-Hellman集团的实力；使用一个非常强的对称密码（如AES256）和一个前向秘密密码套件，但使用一个弱得多的组（如dhe2048）生成密钥只会将对手的成本从攻击对称密码转移到攻击dh_Ys或dh_Yc临时密钥共享。

If the goal is to provide forward secrecy, attention should be paid to all parts of the cipher suite selection process, both key exchange and symmetric cipher choice.

如果目标是提供前向保密性，则应注意密码套件选择过程的所有部分，包括密钥交换和对称密码选择。

8.9. False Start

8.9. 错误的开始

Clients capable of TLS False Start [RFC7918] may receive a proposed FFDHE group from a server that is attacker controlled. In particular, the attacker can modify the ClientHello to strip the proposed FFDHE groups, which may cause the server to offer a weaker

能够进行TLS错误启动[RFC7918]的客户端可能会从攻击者控制的服务器接收建议的FFDHE组。特别是，攻击者可以修改ClientHello以剥离建议的FFDHE组，这可能会导致服务器提供较弱的安全性

FFDHE group than it should, and this will not be detected until receipt of the server's Finished message. This could cause a client using the False Start protocol modification to send data encrypted under a weak key agreement.

FFDHE组超出了它应该的范围，并且在收到服务器完成的消息之前不会检测到这一点。这可能会导致使用错误启动协议修改的客户端发送根据弱密钥协议加密的数据。

Clients should have their own classification of FFDHE groups that are "cryptographically strong" in the same sense described in the description of symmetric ciphers in [RFC7918] and SHOULD offer at least one of these in the initial handshake if they contemplate using the False Start protocol modification with an FFDHE cipher suite.

客户机应该有自己的FFDHE组分类，这些FFDHE组在[RFC7918]中对称密码描述中描述的相同意义上是“加密强”的，并且如果他们考虑对FFDHE密码套件使用假启动协议修改，则应该在初始握手中提供其中至少一个。

Compatible clients performing a full handshake MUST NOT use the False Start protocol modification if the server selects an FFDHE cipher suite but sends a group that is not cryptographically strong from the client's perspective.

如果服务器选择FFDHE密码套件，但从客户端的角度来看，发送的组加密性不强，则执行完全握手的兼容客户端不得使用假启动协议修改。

9. Privacy Considerations

9. 隐私考虑

9.1. Client Fingerprinting

9.1. 客户指纹识别

This extension provides a few additional bits of information to distinguish between classes of TLS clients (e.g., see [PANOPTICLICK]). To minimize this sort of fingerprinting, clients SHOULD support all named groups at or above their minimum security threshold. New groups SHOULD NOT be added to the "Supported Groups Registry" without consideration of the cost of browser fingerprinting.

此扩展提供了一些额外的信息来区分TLS客户端的类别（例如，请参见[Panoptick]）。为了最大限度地减少这种指纹，客户端应该支持所有达到或高于其最低安全阈值的命名组。在不考虑浏览器指纹识别成本的情况下，不应将新组添加到“受支持组注册表”。

10. References

10. 工具书类

10.1. Normative References

10.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.

[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.

[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，DOI 10.17487/RFC4492，2006年5月<http://www.rfc-editor.org/info/rfc4492>.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.

[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", DOI 10.17487/RFC7918, June 2016, <http://www.rfc-editor.org/info/rfc7918>.

[RFC7918]Langley，A.，Modadugu，N.，和B.Moeller，“传输层安全（TLS）错误启动”，DOI 10.17487/RFC7918，2016年6月<http://www.rfc-editor.org/info/rfc7918>.

10.2. Informative References

10.2. 资料性引用

[CROSS-PROTOCOL] Mavrogiannopolous, N., Vercauteren, F., Velichkov, V., and B. Preneel, "A Cross-Protocol Attack on the TLS Protocol", In Proceedings of the 2012 ACM Conference on Computer and Communications Security, DOI 10.1145/2382196.2382206, October 2012, <http://www.cosic.esat.kuleuven.be/ publications/article-2216.pdf>.

[跨协议]Mavrogiannopolous，N.，Vercauteren，F.，Velichkov，V.，和B.Preneel，“TLS协议的跨协议攻击”，2012年ACM计算机和通信安全会议记录，DOI 10.1145/2382196.2382206，2012年10月<http://www.cosic.esat.kuleuven.be/ 出版物/文章-2216.pdf>。

[ECRYPTII] European Network of Excellence in Cryptology II, "ECRYPT II Yearly Report on Algorithms and Keysizes (2011-2012)", Revision 1.0, September 2012, <http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf>.

[ECRYPTII]欧洲密码学卓越网络II，“ECRYPTII算法和密钥设置年度报告（2011-2012）”，第1.0版，2012年9月<http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf>.

[ENISA] European Union Agency for Network and Information Security (ENISA), "Algorithms, Key Sizes and Parameters Report - 2014", November 2014, <https://www.enisa.europa.eu/publications/ algorithms-key-size-and-parameters-report-2014>.

[ENISA]欧盟网络和信息安全署（ENISA），“算法、密钥大小和参数报告-2014”，2014年11月<https://www.enisa.europa.eu/publications/ 算法-key-size-and-parameters-report-2014>。

[NIST] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General", NIST Special Publication 800-57, Revision 4, DOI 10.6028/NIST.SP.800-57pt1r4, January 2016, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>.

[NIST]国家标准与技术研究所，“关键管理建议-第1部分：总则”，NIST专门出版物800-57，第4版，DOI 10.6028/NIST.SP.800-57pt1r4，2016年1月<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>。

[PANOPTICLICK] Electronic Frontier Foundation, "Panopticlick: Is your browser safe against tracking?", <https://panopticlick.eff.org/>.

[ PopopTiLIK]电子前沿基金会，“Panopticlick：你的浏览器对跟踪安全吗？”https://panopticlick.eff.org/>.

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <http://www.rfc-editor.org/info/rfc2246>.

[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，DOI 10.17487/RFC2246，1999年1月<http://www.rfc-editor.org/info/rfc2246>.

[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, <http://www.rfc-editor.org/info/rfc3526>.

[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，DOI 10.17487/RFC3526，2003年5月<http://www.rfc-editor.org/info/rfc3526>.

[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <http://www.rfc-editor.org/info/rfc4346>.

[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，DOI 10.17487/RFC4346，2006年4月<http://www.rfc-editor.org/info/rfc4346>.

[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, <http://www.rfc-editor.org/info/rfc4419>.

[RFC4419]Friedl，M.，Provos，N.，和W.Simpson，“用于安全外壳（SSH）传输层协议的Diffie-Hellman组交换”，RFC 4419，DOI 10.17487/RFC4419，2006年3月<http://www.rfc-editor.org/info/rfc4419>.

[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, <http://www.rfc-editor.org/info/rfc7027>.

[RFC7027]Merkle，J.和M.Lochter，“用于传输层安全（TLS）的椭圆曲线加密（ECC）脑池曲线”，RFC 7027，DOI 10.17487/RFC7027，2013年10月<http://www.rfc-editor.org/info/rfc7027>.

[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <http://www.rfc-editor.org/info/rfc7627>.

[RFC7627]Bhargavan，K.，Ed.，Delignat Lavaud，A.，Pironti，A.，Langley，A.，和M.Ray，“传输层安全（TLS）会话哈希和扩展主秘密扩展”，RFC 7627，DOI 10.17487/RFC7627，2015年9月<http://www.rfc-editor.org/info/rfc7627>.

[SECURE-RESUMPTION] Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, "Triple Handshakes Considered Harmful: Breaking and Fixing Authentication over TLS", 2014 IEEE Symposium on Security and Privacy, DOI 10.1109/SP.2014.14, March 2014, <https://secure-resumption.com/>.

[安全恢复]Delignat Lavaud，A.，Bhargavan，K.，和A.Pironti，“被认为有害的三次握手：通过TLS破坏和修复身份验证”，2014年IEEE安全和隐私研讨会，DOI 10.1109/SP.2014.142014年3月<https://secure-resumption.com/>.

[SSL3-ANALYSIS] Schneier, B. and D. Wagner, "Analysis of the SSL 3.0 protocol", In Proceedings of the Second UNIX Workshop on Electronic Commerce, 1996, <https://www.schneier.com/paper-ssl.pdf>.

[SSL3-ANALYSIS]Schneier，B.和D.Wagner，“SSL 3.0协议的分析”，载于第二届UNIX电子商务研讨会论文集，1996年<https://www.schneier.com/paper-ssl.pdf>.

[STRONGSWAN-IKE] Brunner, T. and A. Steffen, "IKEv2 Cipher Suites: Diffie Hellman Groups", October 2013, <https://wiki.strongswan.org/projects/strongswan/wiki/ IKEv2CipherSuites#Diffie-Hellman-Groups>.

[STRONGSWAN-IKE]Brunner，T.和A.Steffen，“IKEv2密码套件：Diffie Hellman Group”，2013年10月<https://wiki.strongswan.org/projects/strongswan/wiki/ IKEv2 iPhone套件#Diffie Hellman Group>。

Appendix A. Supported Groups Registry (Formerly "EC Named Curve Registry")

附录A.受支持的组注册表（以前称为“EC命名曲线注册表”）

Each description below indicates the group itself, its derivation, its expected strength (estimated roughly from guidelines in [ECRYPTII]), and whether it is recommended for use in TLS key exchange at the given security level. It is not recommended to add further finite field groups to the "Supported Groups Registry"; any attempt to do so should consider Section 9.1.

下面的每个描述都说明了该组本身、其来源、预期强度（根据[ECRYPTII]中的指南粗略估计），以及是否建议在给定安全级别的TLS密钥交换中使用该组。不建议在“支持的组注册表”中添加更多的有限字段组；任何尝试这样做都应该考虑第9.1节。

   The primes in these finite field groups are all safe primes; that is,
   a prime p is a safe prime when q = (p-1)/2 is also prime.  Where e is
   the base of the natural logarithm and square brackets denote the
   floor operation, the groups that initially populate this registry are
   derived for a given bit length b by finding the lowest positive
   integer X that creates a safe prime p where:

   The primes in these finite field groups are all safe primes; that is,
   a prime p is a safe prime when q = (p-1)/2 is also prime.  Where e is
   the base of the natural logarithm and square brackets denote the
   floor operation, the groups that initially populate this registry are
   derived for a given bit length b by finding the lowest positive
   integer X that creates a safe prime p where:

    p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1

    p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1

New additions of FFDHE groups to this registry may use this same derivation (e.g., with different bit lengths) or may choose their parameters in a different way, but they must be clear about how the parameters were derived.

此注册表中新添加的FFDHE组可能使用相同的派生（例如，具有不同的位长度）或可能以不同的方式选择其参数，但必须清楚这些参数是如何派生的。

New additions of FFDHE groups MUST use a safe prime as the modulus to enable the inexpensive peer verification described in Section 5.1.

新添加的FFDHE组必须使用安全素数作为模数，以实现第5.1节所述的廉价对等验证。

A.1. ffdhe2048

The 2048-bit group has registry value 256 and is calculated from the following formula:

2048位组的注册表值为256，根据以下公式计算：

The modulus is:

模量为：

   p = 2^2048 - 2^1984 + {[2^1918 * e] + 560316 } * 2^64 - 1

   p = 2^2048 - 2^1984 + {[2^1918 * e] + 560316 } * 2^64 - 1

The hexadecimal representation of p is:

p的十六进制表示形式为：

The generator is: g = 2

发电机为：g=2

   The group size is: q = (p-1)/2

   The group size is: q = (p-1)/2

The hexadecimal representation of q is:

q的十六进制表示形式为：

The estimated symmetric-equivalent strength of this group is 103 bits.

该组的估计对称等效强度为103位。

Peers using ffdhe2048 that want to optimize their key exchange with a short exponent (Section 5.2) should choose a secret key of at least 225 bits.

使用ffdhe2048的对等方如果希望使用短指数（第5.2节）优化密钥交换，则应选择至少225位的密钥。

A.2. ffdhe3072

The 3072-bit prime has registry value 257 and is calculated from the following formula:

3072位素数的注册表值为257，根据以下公式计算：

The modulus is:

模量为：

   p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 - 1

   p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 - 1

The hexadecimal representation of p is:

p的十六进制表示形式为：

The generator is: g = 2

发电机为：g=2

   The group size is: q = (p-1)/2

   The group size is: q = (p-1)/2

The hexadecimal representation of q is:

q的十六进制表示形式为：

The estimated symmetric-equivalent strength of this group is 125 bits.

该组的估计对称等效强度为125位。

Peers using ffdhe3072 that want to optimize their key exchange with a short exponent (Section 5.2) should choose a secret key of at least 275 bits.

使用ffdhe3072的对等方如果希望使用短指数（第5.2节）优化密钥交换，则应选择至少275位的密钥。

A.3. ffdhe4096

The 4096-bit group has registry value 258 and is calculated from the following formula:

4096位组的注册表值为258，根据以下公式计算：

The modulus is:

模量为：

   p = 2^4096 - 2^4032 + {[2^3966 * e] + 5736041} * 2^64 - 1

   p = 2^4096 - 2^4032 + {[2^3966 * e] + 5736041} * 2^64 - 1

The hexadecimal representation of p is:

p的十六进制表示形式为：

The generator is: g = 2

发电机为：g=2

   The group size is: q = (p-1)/2

   The group size is: q = (p-1)/2

The hexadecimal representation of q is:

q的十六进制表示形式为：

The estimated symmetric-equivalent strength of this group is 150 bits.

该组的估计对称等效强度为150位。

Peers using ffdhe4096 that want to optimize their key exchange with a short exponent (Section 5.2) should choose a secret key of at least 325 bits.

使用ffdhe4096的对等方如果希望使用短指数（第5.2节）优化密钥交换，则应选择至少325位的密钥。

A.4. ffdhe6144

The 6144-bit group has registry value 259 and is calculated from the following formula:

6144位组的注册表值为259，根据以下公式计算：

The modulus is:

模量为：

   p = 2^6144 - 2^6080 + {[2^6014 * e] + 15705020} * 2^64 - 1

   p = 2^6144 - 2^6080 + {[2^6014 * e] + 15705020} * 2^64 - 1

The hexadecimal representation of p is:

p的十六进制表示形式为：

FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 A41D570D 7938DAD4 A40E329C D0E40E65 FFFFFFFF FFFFFFFF

FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F577C935 984F0C70 E68B77 E289DA F3EFE872 1DF158A1 36735 AB798B37A B967A B6B6B6B6B6B7A B6B7B7B7B7B7A1D4F42A3 DE394F4 AE56ED7 6372BB19 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 2834F61 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B6FAD73 5FCBC 2EC22005C58EF183 7D1683B2 C6F34A26 C1B2EFFA 886B4238 61FCFDC DE355B3B 6519035B BC34F4F4DE F99C0238 61B466F6E6907 7F6E6E6E6907 7ADD2683B12C6C22005 C58EF183 7B6B6F7B6B6F7B6F7C1799 137B9AE799F4FD4452 E2D74DD3 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D ABC52197 9B0ADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 3C1B20 EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 7930E9E58857B6 AC7D5F42 D69F6D18 7763CF1D 5503404 87F5BA5 7E31CC7A 7135C886 EFB7A ED6A01 2D697A 797A 29938B9CF7A 29938B81AB93D 7140003C 2 ECEA9 F98D0ACC 0A8291CD CEC97DCF 8EC9B55A 7F88A46B 4DB5A851 F4482E1 C68A007E 5E0DD902 0BFD64B6 45036C7A 4E677D2C 38533A 23BA4442 CAF53EA6 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 3881477FB FDB42777 A96910 10EF538E408F604187FB29F8C 183023C3 587E38DA 0077D9B4 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 B3A73PC1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 5B3B71F9 DC6D680D4D462D462D468D4E4E498D4E4E4E4E4E4E4E4A798D4E4E4E4E4E4E4E4E4E4E4E4E4E4E4E4E4E4A798D49FFFFFFFFFFFFFF

The generator is: g = 2

发电机为：g=2

   The group size is: q = (p-1)/2

   The group size is: q = (p-1)/2

The hexadecimal representation of q is:

q的十六进制表示形式为：

7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1 855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6 6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5 724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582 2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0 D20EAB86 BC9C6D6A 5207194E 68720732 FFFFFFFF FFFFFFFF

7FFFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C BE97F1B1 B1863EC 7B40D901 576230BD 69EF8F6A EAFEB2B0 9219FA8F 833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9F39A 98566527 A41D35B1555B1B2B9B5B5B5F46D7D0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7CC011C 3078E4 EB736464B9 E8B8B8C6787B8B9E7A7EA229716BA6E9B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2911B1D06 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 9E0D9077 1FEBE 12F20E95 B34F0F78 B737A961 8B26FA7D BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 43FAADD 2 BF18E63A3437CFB19 B709 B50B786 B567B988B6C4047C0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764ADA和3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 1DDA219 4BB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 66D6832B FE67F638 CD8FAE1F 27C230F 9C40A3FD A67EDA28917 DBD468AD28285F287F 1AD28457F F2828287F F13FD94FC6 0C1811E1 AC3F1C6D 003BECDA 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C66B9581BA 3573BFAF 31149618 8AB15423 28EE6 DC2A19C5 724FA91A E4ADC88B C66796EA E56777A01 F64E8C08 63139582 2DB8FC EE35C06B 14EEEEEEE547A56D8F364E8B164E8E8E8E8C08 63139582 6B6E5E5E5E5E5E5E5E5E5E5E5E5E5E5E5E5E4E5E5E5E5E5E5FFFFFFFFFFFFFF

The estimated symmetric-equivalent strength of this group is 175 bits.

该组的估计对称等效强度为175位。

Peers using ffdhe6144 that want to optimize their key exchange with a short exponent (Section 5.2) should choose a secret key of at least 375 bits.

使用ffdhe6144的对等方如果希望使用短指数（第5.2节）优化密钥交换，则应选择至少375位的密钥。

A.5. ffdhe8192

The 8192-bit group has registry value 260 and is calculated from the following formula:

8192位组的注册表值为260，根据以下公式计算：

The modulus is:

模量为：

   p = 2^8192 - 2^8128 + {[2^8062 * e] + 10965728} * 2^64 - 1

   p = 2^8192 - 2^8128 + {[2^8062 * e] + 10965728} * 2^64 - 1

The hexadecimal representation of p is:

p的十六进制表示形式为：

FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F577C935 984F0C70 E68B77 E289DA F3EFE872 1DF158A1 36735 AB798B37A B967A B6B6B6B6B6B7A B6B7B7B7B7B7A1D4F42A3 DE394F4 AE56ED7 6372BB19 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 2834F61 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B6FAD73 5FCBC 2EC22005C58EF183 7D1683B2 C6F34A26 C1B2EFFA 886B4238 61FCFDC DE355B3B 6519035B BC34F4F4DE F99C0238 61B466F6E6907 7F6E6E6E6907 7ADD2683B12C6C22005 C58EF183 7B6B6F7B6B6F7B6F7C1799 137B9AE799F4FD4452 E2D74DD3 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D ABC52197 9B0ADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 3C1B20 EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 7930E9E58857B6 AC7D5F42 D69F6D18 7763CF1D 5503404 87F5BA5 7E31CC7A 7135C886 EFB7A ED6A01 2D697A 797A 29938B9CF7A 29938B81AB93D 7140003C 2 ECEA9 F98D0ACC 0A8291CD CEC97DCF 8EC9B55A 7F88A46B 4DB5A851 F4482E1 C68A007E 5E0DD902 0BFD64B6 45036C7A 4E677D2C 38533A 23BA4442 CAF53EA6 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 3881477FB FDB42777 A96910 10EF538E408F604187FB29F8C 183023C3 587E38DA 0077D9B4 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 B3A73PC1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 5B3B71F9 DC6D680D462D462D468D462D468D468D468D468D468D4A798D4A4 CF418A D498D4A798A D4A798D36AD004C F600C838 1E425A31 D951AE64 FDB23FCE C9509D43 687FEB69 EDD1CC5E 0B8CC3BD F64B10EF 86B63142 A38829 555B2F74 7C932665 CB2C0F1C C01BD702 29388839 D2AF05E4 54504AC7 8B758282 2846C0BA 35C35C 59160CC0 46FD8251 541FC68C 9C86B022 BB709987 6A460E74 51A931 091费用1C217E569CFC 38758226D5B80194 88D9C0A0 A1FE3075 A577E231 83F81D4A 3F2FA457 1EFC8CE0 BA8A4FE8 B6855DFE 72B0A66E DED2FBE58A30 FAFAFAFABE1C 5D71A87E 2F741EF8 C1FE86FE A6BBFDE5 30677F0D 97D149 F7A8443D 0822E506 A9F4614E 011E2A94 838FF88C D68C8B7C5C6424CFFFFFFFFFF

The generator is: g = 2

发电机为：g=2

   The group size is: q = (p-1)/2

   The group size is: q = (p-1)/2

The hexadecimal representation of q is:

q的十六进制表示形式为：

7FFFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C BE97F1B1 B1863EC 7B40D901 576230BD 69EF8F6A EAFEB2B0 9219FA8F 833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9F39A 98566527 A41D35B1555B1B2B9B5B5B5F46D7D0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7CC011C 3078E4 EB736464B9 E8B8B8C6787B8B9E7A7EA229716BA6E9B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2911B1D06 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 9E0D9077 1FEBE 12F20E95 B34F0F78 B737A961 8B26FA7D BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 43FAADD 2 BF18E63A3437CFB19 B709 B50B786 B567B988B6C4047C0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764ADA和3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 1DDA219 4BB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 66D6832B FE67F638 CD8FAE1F 27C230F 9C40A3FD A67EDA28917 DBD468AD28285F287F 1AD28457F F2828287F F13FD94FC6 0C1811E1 AC3F1C6D 003BECDA 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 59D39CE0 91308B41 05746DAC 23D33F 7CE4848D A316A9C66B9581BA 3573BFAF 31149618 8AB15423 28EE6 DC2A19C5 724FA91A E4ADC88B C66796EA E56777A01 F64E8C08 63139582 2DB8FC EE356B6EE47 4A56D8F38B1538BFF 3149686 FA6791B568026 7B00641C 0F212D18 ECA8D732 7ED91FE7 64A84EA1 B43FF5B4 F6E8E62F 05C661DE FB258877 C35B18A1 51D5C414 AAAD97BA 3E499332 E59078E 600DEB81 149C441C E95782F2A282563 C5BAC1414 1423605D 1AE1AFAE 2C8B0660 237EC128 AA346 4E435811 5DB84CC3 B73A 28D45498 B818 B817FF787 0E1368F42607B16 AFB16EADC00CA 446CE050 50FF183A D2BBF118 C1FC0EA5 1F97D22B 8F7E4670 5D4527F4 5B42AEFF 39585337 6F697DD5 FDF2C518 7D7D7D5F0E 2EB8D43F 17BA0F7C 60FF437F 535DF2 9833BF86 CBE88EAFB4 D4221E 84117283 54FA30A7 008F154A 41C7FC46 6B4645DB E2E32126 7FFFFFFFFFFFF FFFF

The estimated symmetric-equivalent strength of this group is 192 bits.

该组的估计对称等效强度为192位。

Peers using ffdhe8192 that want to optimize their key exchange with a short exponent (Section 5.2) should choose a secret key of at least 400 bits.

使用ffdhe8192的对等方如果希望使用短指数（第5.2节）优化密钥交换，则应选择至少400位的密钥。

Acknowledgements

致谢

Thanks to Fedor Brunner, Dave Fergemann, Niels Ferguson, Sandy Harris, Tero Kivinen, Watson Ladd, Nikos Mavrogiannopolous, Niels Moeller, Bodo Moeller, Kenny Paterson, Eric Rescorla, Tom Ritter, Rene Struik, Martin Thomson, Sean Turner, and other members of the TLS Working Group for their comments and suggestions on this document. Any mistakes here are not theirs.

感谢Fedor Brunner、Dave Fergemann、Niels Ferguson、Sandy Harris、Tero Kivinen、Watson Ladd、Nikos Mavrogiannopolous、Niels Moeller、Bodo Moeller、Kenny Paterson、Eric Rescorla、Tom Ritter、Rene Struik、Martin Thomson、Sean Turner和TLS工作组其他成员对本文件的评论和建议。这里的任何错误都不是他们的。

Author's Address

作者地址

Daniel Kahn Gillmor ACLU 125 Broad Street, 18th Floor New York, NY 10004 United States of America

美国纽约州纽约市布罗德街125号18楼Daniel Kahn Gillmor ACLU 10004

   Email: dkg@fifthhorseman.net

   Email: dkg@fifthhorseman.net