idnits 2.17.1 draft-ietf-tls-negotiated-ff-dhe-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 11, 2014) is 3478 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 644 ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational October 11, 2014 5 Expires: April 14, 2015 7 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS 8 draft-ietf-tls-negotiated-ff-dhe-02 10 Abstract 12 Traditional finite-field-based Diffie-Hellman (DH) key exchange 13 during the TLS handshake suffers from a number of security, 14 interoperability, and efficiency shortcomings. These shortcomings 15 arise from lack of clarity about which DH group parameters TLS 16 servers should offer and clients should accept. This document offers 17 a solution to these shortcomings for compatible peers by using a 18 section of the TLS "EC Named Curve Registry" to establish common DH 19 parameters with known structure and a mechanism for peers to 20 negotiate support for these groups. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 14, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. ServerDHParams changes . . . . . . . . . . . . . . . . . 6 62 4. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Checking the Peer's Public Key . . . . . . . . . . . . . 6 64 4.2. Short Exponents . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Table Acceleration . . . . . . . . . . . . . . . . . . . 7 66 5. Operational Considerations . . . . . . . . . . . . . . . . . 7 67 5.1. Preference Ordering . . . . . . . . . . . . . . . . . . . 7 68 6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.1. Server Indication of support . . . . . . . . . . . . . . 8 70 6.2. Normalizing Weak Groups . . . . . . . . . . . . . . . . . 9 71 6.3. Arbitrary Groups . . . . . . . . . . . . . . . . . . . . 9 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 9.1. Negotiation resistance to active attacks . . . . . . . . 10 76 9.2. DHE only . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.3. Deprecating weak groups . . . . . . . . . . . . . . . . . 11 78 9.4. Choice of groups . . . . . . . . . . . . . . . . . . . . 11 79 9.5. Timing attacks . . . . . . . . . . . . . . . . . . . . . 12 80 9.6. Replay attacks from non-negotiated FF DHE . . . . . . . . 12 81 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 82 10.1. Client fingerprinting . . . . . . . . . . . . . . . . . 12 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 85 11.2. Informative References . . . . . . . . . . . . . . . . . 13 86 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 Appendix A. Named Group Registry . . . . . . . . . . . . . . . . 14 88 A.1. ffdhe2432 . . . . . . . . . . . . . . . . . . . . . . . . 15 89 A.2. ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 16 90 A.3. ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 17 91 A.4. ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . . 19 92 A.5. ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 21 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 95 1. Introduction 97 Traditional TLS [RFC5246] offers a Diffie-Hellman ephemeral (DHE) key 98 exchange mode which provides Perfect Forward Secrecy for the 99 connection. The client offers a ciphersuite in the ClientHello that 100 includes DHE, and the server offers the client group parameters g and 101 p. If the client does not consider the group strong enough (e.g. if 102 p is too small, or if p is not prime, or there are small subgroups), 103 or if it is unable to process it for other reasons, it has no 104 recourse but to terminate the connection. 106 Conversely, when a TLS server receives a suggestion for a DHE 107 ciphersuite from a client, it has no way of knowing what kinds of DH 108 groups the client is capable of handling, or what the client's 109 security requirements are for this key exchange session. Some 110 widely-distributed TLS clients are not capable of DH groups where p > 111 1024. Other TLS clients may by policy wish to use DHE only if the 112 server can offer a stronger group (and are willing to use a non-PFS 113 key-exchange mechanism otherwise). The server has no way of knowing 114 which type of client is connecting, but must select DH parameters 115 with insufficient knowledge. 117 Additionally, the DH parameters chosen by the server may have a known 118 structure which renders them secure against a small subgroup attack, 119 but a client receiving an arbitrary p has no efficient way to verify 120 that the structure of a new group is reasonable for use. 122 This modification to TLS solves these problems by using a section of 123 the "EC Named Curves" registry to select common DH groups with known 124 structure; defining the use of the "elliptic_curves(10)" extension 125 for clients advertising support for DHE with these groups; and 126 defining how a server indicates acceptance of a proposed common 127 group. This document also provides guidance for compliant peers to 128 take advantage of the additional security, availability, and 129 efficiency offered. 131 The use of this mechanism by one compliant peer when interacting with 132 a non-compliant peer should have no detrimental effects. 134 1.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 1.2. Vocabulary 142 The terms "DHE" or "FFDHE" are used in this document to refer to the 143 finite-field-based Diffie-Hellman ephemeral key exchange mechanism in 144 TLS. TLS also supports elliptic-curve-based Diffie-Hellman (ECDHE) 145 ephemeral key exchanges [RFC4492], but this document does not 146 document their use. A registry previously used only by ECHDE-capable 147 implementations is expanded in this document to cover FFDHE groups as 148 well. "FFDHE ciphersuites" is used in this document to refer 149 exclusively to ciphersuites with FFDHE key exchange mechanisms, but 150 note that these suites are typically labeled with a TLS_DHE_ prefix. 152 2. Client Behavior 154 A TLS client that is capable of using strong finite field Diffie- 155 Hellman groups can advertise its capabilities and its preferences for 156 stronger key exchange by using this mechanism. 158 We use previously-unallocated codepoints within the extension 159 currently known as "elliptic_curves" (section 5.1.1. of [RFC4492]) to 160 indicate known finite field groups. The extension's semantics is 161 expanded from "known elliptic curve groups" to "known groups". The 162 semantics of the extension's data type (enum NamedCurve) is also 163 expanded from "named curve" to "named group". 165 The compatible client that wants to be able to negotiate strong FFDHE 166 SHOULD send an extension of type "elliptic_curves" ([RFC4492]) in the 167 ClientHello, and include a list of known FFDHE groups in the 168 extension data, ordered from most preferred to least preferred. If 169 the client also supports and wants to offer ECDHE key exchange, it 170 MUST use a single elliptic_curves extension to include all supported 171 groups (both ECDHE and FFDHE groups). The ordering SHOULD be based 172 on client preference, but see Section 5.1 for more nuance. 174 Here are the new code points for the NamedCurve registry: 176 enum { 177 // other already defined elliptic curves (see RFC 4492) 178 ffdhe2432(256), ffdhe3072(257), ffdhe4096(258), 179 ffdhe6144(259), ffdhe8192(260), 180 // 181 } NamedCurve; 183 A client that offers any of these values in the NamedCurves extension 184 SHOULD ALSO include at least one FFDHE ciphersuite in the Client 185 Hello. 187 These additions to the Named Curve registry are described in detail 188 in Appendix A. They are all safe primes derived from the base of the 189 natural logarithm ("e"), with the high and low 64 bits set to 1 for 190 efficient Montgomery or Barrett reduction. 192 The use of the base of the natural logarithm here is as a "nothing- 193 up-my-sleeve" number. The goal is to guarantee that the bits in the 194 middle of the modulus are effectively random, while avoiding any 195 suspicion that the primes have secretly been selected to be weak 196 according to some secret criteria. [RFC3526] used pi for this value. 197 See Section 9.4 for reasons that this draft does not reuse pi. 199 A client who offers a group MUST be able and willing to perform a DH 200 key exchange using that group. 202 3. Server Behavior 204 If a compatible TLS server receives a NamedCurves extension from a 205 client that includes any FFDHE groups, the server SHOULD NOT select 206 an FFDHE ciphersuite if it is unwilling to use one of the FFDHE 207 groups named by the client. In this case, the server SHOULD select 208 an acceptable non-FFDHE ciphersuite from the client's offered list. 209 If the extension is present, none of the client's offered groups are 210 acceptable by the server, and none of the client's proposed non-FFDHE 211 ciphersuites are acceptable to the server, the server SHOULD end the 212 connection with a fatal TLS alert of type insufficient_security. 214 A compatible TLS server that receives the NamedCurve extension with 215 FFDHE codepoints in it, and which selects an FFDHE ciphersuite MUST 216 select one of the offered groups and indicates the choice of groups 217 to the client by sending a specially-formatted ServerDHParams as 218 described below. 220 A TLS server MUST NOT send the specially-formatted ServerDHParams 221 message to a client that did not offer an FFDHE group in the 222 NamedCurves extension first. 224 A TLS server MUST NOT select a named group that was not offered by 225 the client. 227 A TLS server MUST NOT select an FFDHE ciphersuite if the client did 228 not offer one, even if the client offered an FFDHE group in the 229 NamedCurves extension. 231 If a non-anonymous FFDHE ciphersuite is chosen, and the TLS client 232 has used this extension to offer an FFDHE group of comparable or 233 greater strength than the server's public key, the server SHOULD 234 select an FFDHE group at least as strong as the server's public key. 236 For example, if the server has a 3072-bit RSA key, and the client 237 offers only ffdhe2432 and ffdhe4096, the server SHOULD select 238 ffdhe4096. 240 3.1. ServerDHParams changes 242 When the compatible server selects an FFDHE ciphersuite for a client 243 who offered FFDHE groups via Named Curves, the ServerDHParams member 244 of the subsequent ServerKeyExchange message should indicate a one- 245 byte zero value (0) in place of dh_g to indicate support for a pre- 246 known FFDHE group. It places the value of the named group 247 (represented as a two-byte value) in place of dh_p. dh_Ys must be 248 transmitted as normal. 250 This re-purposing of dh_p and dh_g is unambiguous: there are no 251 groups with a generator of 0, and no implementation should accept a 252 modulus of size < 17 bits. Aside from making the ServerDHParams an 253 unambiguous indicator of support for named FFDHE groups, this change 254 serves two purposes: 256 The size of the handshake is reduced (significantly, in the case 257 of a large prime modulus). 259 The signed struct should not be re-playable in a subsequent key 260 exchange that does not indicate named FFDHE groups. 262 4. Optimizations 264 In a key exchange with a successfully negotiated known FFDHE group, 265 both peers know that the group in question uses a safe prime as a 266 modulus, and that the group in use is of size p-1 or (p-1)/2. This 267 allows at least three optimizations that can be used to improve 268 performance. 270 4.1. Checking the Peer's Public Key 272 Peers should validate each other's public key Y (dh_Ys offered by the 273 server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1. 274 This simple check ensures that the remote peer is properly behaved 275 and isn't forcing the local system into a small subgroup. 277 To reach the same assurance with an unknown group, the client would 278 need to verify the primality of the modulus, learn the factors of 279 p-1, and test both the generator g and Y against each factor to avoid 280 small subgroup attacks. 282 4.2. Short Exponents 284 Traditional Finite Field Diffie-Hellman has each peer choose their 285 secret exponent from the range [2,p-2]. Using exponentiation by 286 squaring, this means each peer must do roughly 2*log_2(p) 287 multiplications, twice (once for the generator and once for the 288 peer's public key). 290 Peers concerned with performance may also prefer to choose their 291 secret exponent from a smaller range, doing fewer multiplications, 292 while retaining the same level of overall security. Each named group 293 indicates its approximate security level, and provides a lower-bound 294 on the range of secret exponents that should preserve it. For 295 example, rather than doing 2*2*2432 multiplications for a ffdhe2432 296 handshake, each peer can choose to do 2*2*224 multiplications by 297 choosing their secret exponent in the range [2,2^224] and still keep 298 the approximate 112-bit security level. 300 A similar short-exponent approach is suggested in SSH's Diffie- 301 Hellman key exchange (See section 6.2 of [RFC4419]). 303 4.3. Table Acceleration 305 Peers wishing to further accelerate FFDHE key exchange can also pre- 306 compute a table of powers of the generator of a known group. This is 307 a memory vs. time tradeoff, and it only accelerates the first 308 exponentiation of the ephemeral DH exchange (the exponentiation using 309 the peer's public exponent as a base still needs to be done as 310 normal). 312 5. Operational Considerations 314 5.1. Preference Ordering 316 The ordering of named groups in the NamedCurves extension may contain 317 some ECDHE groups and some FFDHE groups. These SHOULD be ranked in 318 preference order. 320 However, the ClientHello also contains list of desired ciphersuites, 321 also ranked in preference order. This presents the possibility of 322 conflicted preferences. For example, if the ClientHello contains a 323 CipherSuite with two choices in order 324 and the NamedCurves Extension 326 contains two choices in order then there is a 327 clear contradiction. Clients MUST NOT present such a contradiction. 328 A server that encounters such an contradiction when selecting between 329 an ECDHE or FFDHE key exchange mechanism while trying to respect 330 client preferences SHOULD give priority to the NamedCurves extension 331 (in the example case, it should select 332 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with secp256r1. 334 More subtly, it is possible for a client to present an ambiguity that 335 is not a clear contradiction. For example, the ClientHello could be 336 the same as the above example, but NamedCurves could be: 337 . Clients MAY present such 338 a mixed set of groups. In this case, a server configured to respect 339 client preferences and with support for all listed groups SHOULD 340 select TLS_DHE_RSA_WITH_AES_128_CBC_SHA with ffdhe8192. A server 341 configured to respect client preferences and with support for only 342 secp384p1 and ffdhe3072 SHOULD select 343 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with secp384p1. 345 6. Open Questions 347 [This section should be removed, and questions resolved, before any 348 formalization of this draft] 350 6.1. Server Indication of support 352 Some servers will support this mechanism, but for whatever reason 353 decide to not negotiate a ciphersuite with DHE key exchange at all. 354 Some possible reasons include: 356 The client indicated that a server-supported non-FFDHE ciphersuite 357 was preferred over all FFDHE ciphersuites, and the server honors 358 that preference. 360 The server prefers a client-supported non-FFDHE ciphersuite over 361 all FFDHE ciphersuites, and selects it unilaterally. 363 The server would have chosen a FFDHE ciphersuite, but none of the 364 client's offered groups are acceptable to the server, 366 Clients will not know that such a server supports this mechanism. 368 Should we offer a way for a server to indicate its support for this 369 mechanism to a compatible client in this case? 371 Should the server have a way to advertise that it supports this 372 mechanism even if the client does not offer an FFDHE group in 373 NamedCurves, or does not offer any NamedCurve at all? 375 [dkg] I think the answer here is that we do not care about signalling 376 this support to the client in general. 378 6.2. Normalizing Weak Groups 380 Is there any reason to include a weak group in the list of groups? 381 Most DHE-capable peers can already handle 1024-bit DHE, and therefore 382 1024-bit DHE does not need to be negotiated. Properly-chosen 383 2432-bit DH groups should be roughly equivalent to 112-bit security. 384 And future implementations should use sizes of at least 3072 bits 385 according to [ENISA]. 387 6.3. Arbitrary Groups 389 This spec currently doesn't indicate any support for groups other 390 than the named groups. Other FFDHE specifications have moved away 391 from staticly-named groups with the explicitly-stated rationale of 392 reducing the incentive for precomputation-driven attacks on any 393 specific group (e.g. section 1 of [RFC4419]). However, arbitrary 394 large groups are expensive to transmit over the network and it is 395 computationally infeasible for the client to verify their structure 396 during a key exchange. If we instead allow the server to propose 397 arbitrary groups, we could make it a MUST that the generated groups 398 use safe prime moduli, while still allowing clients to signal support 399 (and desire) for large groups. This leaves the client in the 400 position of relying on the server to choose a strong modulus, though. 402 Note that in several known attacks against TLS and SSL 403 [SECURE-RESUMPTION] [CROSS-PROTOCOL] [SSL3-ANALYSIS], a malicious 404 server uses a deliberately broken FFDHE group to impersonate the 405 client to a different server. 407 7. Acknowledgements 409 Thanks to Fedor Brunner, Dave Fergemann, Sandy Harris, Watson Ladd, 410 Nikos Mavrogiannopolous, Niels Moeller, Kenny Paterson, Eric 411 Rescorla, Tom Ritter, Martin Thomson, and Sean Turner for their 412 comments and suggestions on this draft. Any mistakes here are not 413 theirs. 415 8. IANA Considerations 417 IANA maintains the registry currently known as EC Named Curves 418 (originally defined in [RFC4492] and updated by [RFC7027]) at [1]. 420 This document expands the semantics of this registry slightly, to 421 include groups based on finite fields in addition to groups based on 422 elliptic curves. 424 This document allocates five codepoints in the registry, as follows: 426 +-------+-------------+---------+-----------------+ 427 | Value | Description | DTLS-OK | Reference | 428 +-------+-------------+---------+-----------------+ 429 | 256 | ffdhe2432 | Y | [this document] | 430 | 257 | ffdhe3072 | Y | [this document] | 431 | 258 | ffdhe4096 | Y | [this document] | 432 | 259 | ffdhe6144 | Y | [this document] | 433 | 260 | ffdhe8192 | Y | [this document] | 434 +-------+-------------+---------+-----------------+ 436 9. Security Considerations 438 9.1. Negotiation resistance to active attacks 440 Because the contents of this extension is hashed in the finished 441 message, an active MITM that tries to filter or omit groups will 442 cause the handshake to fail, but possibly not before getting the peer 443 to do something they would not otherwise have done. 445 An attacker who impersonates the server can try to do any of the 446 following: 448 Pretend that a non-compatible server is actually capable of this 449 extension, and select a group from the client's list, causing the 450 client to select a group it is willing to negotiate. It is 451 unclear how this would be an effective attack. 453 Pretend that a compatible server is actually non-compatible by 454 negotiating a non-DHE ciphersuite. This is no different than MITM 455 ciphersuite filtering. 457 Pretend that a compatible server is actually non-compatible by 458 negotiating a DHE ciphersuite and no extension, with an explicit 459 (perhaps weak) group chosen by the server. [XXX what are the 460 worst consequences in this case? What might the client leak 461 before it notices that the handshake fails? XXX] 463 An attacker who impersonates the client can try to do the following: 465 Pretend that a compatible client is not compliant (e.g. by not 466 offering this extension). This could cause the server to 467 negotiate a weaker DHE group during the handshake, but it would 468 fail to complete during the final check of the Finished message. 470 Pretend that a non-compatible client is compatible. This could 471 cause the server to send what appears to be an extremely odd 472 ServerDHParams (see Section 3.1), and the check in the Finished 473 message would fail. It is not clear how this could be an attack. 475 Change the list of groups offered by the client (e.g. by removing 476 the stronger of the set of groups offered). This could cause the 477 server to negotiate a weaker group than desired, but again should 478 be caught by the check in the Finished message. 480 9.2. DHE only 482 Note that this extension specifically targets only finite field-based 483 Diffie-Hellman ephemeral key exchange mechanisms. It does not cover 484 the non-ephemeral DH key exchange mechanisms, nor does it cover 485 elliptic curve-based DHE key exchange, which has its own list of 486 named groups. 488 9.3. Deprecating weak groups 490 Advances in hardware or in finite field cryptanalysis may cause some 491 of the negotiated groups to not provide the desired security margins, 492 as indicated by the estimated work factor of an adversary to discover 493 the premaster secret (and therefore compromise the confidentiality 494 and integrity of the TLS session). 496 Revisions of this extension or updates should mark known-weak groups 497 as explicitly deprecated for use in TLS, and should update the 498 estimated work factor needed to break the group, if the cryptanalysis 499 has changed. Implementations that require strong confidentiality and 500 integrity guarantees should avoid using deprecated groups and should 501 be updated when the estimated security margins are updated. 503 9.4. Choice of groups 505 Other lists of named finite field Diffie-Hellman groups 506 [STRONGSWAN-IKE] exist. This draft chooses to not reuse them for 507 several reasons: 509 Using the same groups in multiple protocols increases the value 510 for an attacker with the resources to crack any single group. 512 The IKE groups include weak groups like MODP768 which are 513 unacceptable for secure TLS traffic. 515 Mixing group parameters across multiple implementations leaves 516 open the possibility of some sort of cross-protocol attack. This 517 shouldn't be relevant for ephemeral scenarios, and even with non- 518 ephemeral keying, services shouldn't share keys; however, using 519 different groups avoids these failure modes entirely. 521 Other lists of named FF DHE groups are not collected in a single 522 IANA registry, or are mixed with non-FF DHE groups, which makes 523 them inconvenient for re-use in a TLS DHE key exchange context. 525 9.5. Timing attacks 527 Any implementation of finite field Diffie-Hellman key exchange should 528 use constant-time modular-exponentiation implementations. This is 529 particularly true for those implementations that ever re-use DHE 530 secret keys (so-called "semi-static" ephemeral keying) or share DHE 531 secret keys across a multiple machines (e.g. in a load-balancer 532 situation). 534 9.6. Replay attacks from non-negotiated FF DHE 536 [SECURE-RESUMPTION] shows a malicious peer using a bad FF DHE group 537 to maneuver a client into selecting a pre-master secret of the peer's 538 choice, which can be replayed to another server using a non-DHE key 539 exchange, and can then be bootstrapped to replay client 540 authentication. 542 To prevent this attack (barring the fixes proposed in 543 [SESSION-HASH]), a client would need not only to implement this 544 draft, but also to reject non-negotiated FF DHE ciphersuites whose 545 group structure it cannot afford to verify. Such a client would need 546 to abort the initial handshake and reconnect to the server in 547 question without listing any FF DHE ciphersuites on the subsequent 548 connection. 550 This tradeoff may be too costly for most TLS clients today, but may 551 be a reasonable choice for clients performing client certificate 552 authentication, or who have other reason to be concerned about 553 server-controlled pre-master secrets. 555 10. Privacy Considerations 557 10.1. Client fingerprinting 559 This extension provides a few additional bits of information to 560 distinguish between classes of TLS clients (see e.g. 561 [PANOPTICLICK]). To minimize this sort of fingerprinting, clients 562 SHOULD support all named groups at or above their minimum security 563 threshhold. New named groups SHOULD NOT be added to the registry 564 without consideration of the cost of browser fingerprinting. 566 11. References 568 11.1. Normative References 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, March 1997. 573 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 574 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 575 for Transport Layer Security (TLS)", RFC 4492, May 2006. 577 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 578 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 580 11.2. Informative References 582 [CROSS-PROTOCOL] 583 Mavrogiannopolous, N., Vercauteren, F., Velichkov, V., and 584 B. Preneel, "A Cross-Protocol Attack on the TLS Protocol", 585 October 2012, 586 . 589 [ECRYPTII] 590 European Network of Excellence in Cryptology II, "ECRYPT 591 II Yearly Report on Algorithms and Keysizes (2011-2012)", 592 September 2012, 593 . 595 [ENISA] European Union Agency for Network and Information Security 596 Agency, "Algorithms, Key Sizes and Parameters Report, 597 version 1.0", October 2013, 598 . 602 [PANOPTICLICK] 603 Electronic Frontier Foundation, "Panopticlick: How Unique 604 - and Trackable - Is Your Browser?", 2010, 605 . 607 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 608 Diffie-Hellman groups for Internet Key Exchange (IKE)", 609 RFC 3526, May 2003. 611 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 612 Group Exchange for the Secure Shell (SSH) Transport Layer 613 Protocol", RFC 4419, March 2006. 615 [RFC7027] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography 616 (ECC) Brainpool Curves for Transport Layer Security 617 (TLS)", RFC 7027, October 2013. 619 [SECURE-RESUMPTION] 620 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 621 "Triple Handshakes Considered Harmful: Breaking and Fixing 622 Authentication over TLS", March 2014, . 625 [SESSION-HASH] 626 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 627 A., and M. Ray, "Triple Handshakes Considered Harmful: 628 Breaking and Fixing Authentication over TLS", March 2014, 629 . 632 [SSL3-ANALYSIS] 633 Schneier, B. and D. Wagner, "Analysis of the SSL 3.0 634 protocol", 1996, . 636 [STRONGSWAN-IKE] 637 Brunner, T. and A. Steffen, "Diffie Hellman Groups in 638 IKEv2 Cipher Suites", October 2013, 639 . 642 11.3. URIs 644 [1] https://www.iana.org/assignments/tls-parameters/tls- 645 parameters.xhtml#tls-parameters-8 647 Appendix A. Named Group Registry 649 Each description below indicates the group itself, its derivation, 650 its expected strength (estimated roughly from guidelines in 651 [ECRYPTII]), and whether it is recommended for use in TLS key 652 exchange at the given security level. It is not recommended to add 653 furtherw finite field groups to the NamedCurves registry; any attempt 654 to do so should consider Section 10.1. 656 The primes in these finite field groups are all safe primes, that is, 657 a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is 658 the base of the natural logarithm, and square brackets denote the 659 floor operation, the groups which initially populate this registry 660 are derived for a given bitlength b by finding the lowest positive 661 integer X that creates a safe prime p where: 663 p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1 665 New additions to this registry may use this same derivation (e.g. 666 with different bitlengths) or may choose their parameters in a 667 different way, but must be clear about how the parameters were 668 derived. 670 A.1. ffdhe2432 672 The 2432-bit group has registry value 256, and is calcluated from the 673 following formula: 675 The modulus is: p = 2^2432 - 2^2368 + {[2^2302 * e] + 2111044} * 2^64 676 - 1 678 The hexadecimal representation of p is: 680 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 681 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 682 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 683 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 684 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 685 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 686 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 687 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 688 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 689 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 690 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 691 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 692 AEFE1309 8533C8B3 FFFFFFFF FFFFFFFF 694 The generator is: g = 2 696 The group size is: q = (p-1)/2 698 The hexadecimal representation of q is: 700 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 701 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 702 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 703 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 704 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 705 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 706 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 707 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 708 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 709 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 710 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 711 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 712 577F0984 C299E459 FFFFFFFF FFFFFFFF 714 The estimated symmetric-equivalent strength of this group is 112 715 bits. 717 Peers using ffdhe2432 that want to optimize their key exchange with a 718 short exponent (Section 4.2) should choose a secret key of at least 719 224 bits. 721 A.2. ffdhe3072 723 The 3072-bit prime has registry value 257, and is calcluated from the 724 following formula: 726 p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 -1 728 The hexadecimal representation of p is: 730 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 731 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 732 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 733 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 734 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 735 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 736 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 737 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 738 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 739 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 740 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 741 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 742 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 743 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 744 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 745 3C1B20EE 3FD59D7C 25E41D2B 66C62E37 FFFFFFFF FFFFFFFF 747 The generator is: g = 2 748 The group size is: q = (p-1)/2 750 The hexadecimal representation of q is: 752 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 753 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 754 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 755 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 756 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 757 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 758 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 759 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 760 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 761 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 762 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 763 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 764 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 765 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 766 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 767 9E0D9077 1FEACEBE 12F20E95 B363171B FFFFFFFF FFFFFFFF 769 The estimated symmetric-equivalent strength of this group is 125 770 bits. 772 Peers using ffdhe3072 that want to optimize their key exchange with a 773 short exponent (Section 4.2) should choose a secret key of at least 774 250 bits. 776 A.3. ffdhe4096 778 The 4096-bit group has registry value 258, and is calcluated from the 779 following formula: 781 The modulus is: p = 2^4096 - 2^4032 + {[2^3966 * e] + 5736041} * 2^64 782 - 1 784 The hexadecimal representation of p is: 786 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 787 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 788 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 789 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 790 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 791 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 792 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 793 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 794 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 795 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 796 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 797 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 798 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 799 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 800 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 801 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 802 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 803 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 804 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 805 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 806 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E655F6A 807 FFFFFFFF FFFFFFFF 809 The generator is: g = 2 811 The group size is: q = (p-1)/2 813 The hexadecimal representation of q is: 815 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 816 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 817 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 818 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 819 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 820 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 821 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 822 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 823 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 824 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 825 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 826 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 827 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 828 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 829 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 830 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D 831 BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 832 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 833 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 834 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 835 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F32AFB5 836 7FFFFFFF FFFFFFFF 838 The estimated symmetric-equivalent strength of this group is 150 839 bits. 841 Peers using ffdhe4096 that want to optimize their key exchange with a 842 short exponent (Section 4.2) should choose a secret key of at least 843 300 bits. 845 A.4. ffdhe6144 847 The 6144-bit group has registry value 259, and is calcluated from the 848 following formula: 850 The modulus is: p = 2^6144 - 2^6080 + {[2^6014 * e] + 15705020} * 851 2^64 - 1 853 The hexadecimal representation of p is: 855 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 856 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 857 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 858 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 859 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 860 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 861 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 862 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 863 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 864 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 865 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 866 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 867 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 868 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 869 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 870 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 871 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 872 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 873 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 874 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 875 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 876 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 877 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A 878 CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 879 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 880 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 881 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 882 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C 883 D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A 884 E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 885 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 886 A41D570D 7938DAD4 A40E329C D0E40E65 FFFFFFFF FFFFFFFF 888 The generator is: g = 2 890 The group size is: q = (p-1)/2 892 The hexadecimal representation of q is: 894 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 895 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 896 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 897 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 898 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 899 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 900 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 901 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 902 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 903 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 904 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 905 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 906 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 907 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 908 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 909 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D 910 BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 911 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 912 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 913 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 914 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 915 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 916 1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 917 66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B 918 D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1 919 855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA 920 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 921 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6 922 6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5 923 724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582 924 2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0 925 D20EAB86 BC9C6D6A 5207194E 68720732 FFFFFFFF FFFFFFFF 927 The estimated symmetric-equivalent strength of this group is 175 928 bits. 930 Peers using ffdhe6144 that want to optimize their key exchange with a 931 short exponent (Section 4.2) should choose a secret key of at least 932 350 bits. 934 A.5. ffdhe8192 936 The 8192-bit group has registry value 260, and is calcluated from the 937 following formula: 939 The modulus is: p = 2^8192 - 2^8128 + {[2^8062 * e] + 10965728} * 940 2^64 - 1 941 The hexadecimal representation of p is: 943 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 944 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 945 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 946 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 947 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 948 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 949 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 950 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 951 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 952 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 953 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 954 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 955 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 956 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 957 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 958 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 959 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 960 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 961 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 962 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 963 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 964 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 965 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A 966 CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 967 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 968 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 969 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 970 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C 971 D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A 972 E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 973 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 974 A41D570D 7938DAD4 A40E329C CFF46AAA 36AD004C F600C838 975 1E425A31 D951AE64 FDB23FCE C9509D43 687FEB69 EDD1CC5E 976 0B8CC3BD F64B10EF 86B63142 A3AB8829 555B2F74 7C932665 977 CB2C0F1C C01BD702 29388839 D2AF05E4 54504AC7 8B758282 978 2846C0BA 35C35F5C 59160CC0 46FD8251 541FC68C 9C86B022 979 BB709987 6A460E74 51A8A931 09703FEE 1C217E6C 3826E52C 980 51AA691E 0E423CFC 99E9E316 50C1217B 624816CD AD9A95F9 981 D5B80194 88D9C0A0 A1FE3075 A577E231 83F81D4A 3F2FA457 982 1EFC8CE0 BA8A4FE8 B6855DFE 72B0A66E DED2FBAB FBE58A30 983 FAFABE1C 5D71A87E 2F741EF8 C1FE86FE A6BBFDE5 30677F0D 984 97D11D49 F7A8443D 0822E506 A9F4614E 011E2A94 838FF88C 985 D68C8BB7 C5C6424C FFFFFFFF FFFFFFFF 987 The generator is: g = 2 988 The group size is: q = (p-1)/2 990 The hexadecimal representation of q is: 992 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 993 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 994 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 995 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 996 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 997 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 998 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 999 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 1000 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 1001 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 1002 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 1003 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 1004 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 1005 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 1006 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 1007 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D 1008 BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 1009 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 1010 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 1011 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 1012 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 1013 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 1014 1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 1015 66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B 1016 D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1 1017 855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA 1018 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 1019 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6 1020 6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5 1021 724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582 1022 2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0 1023 D20EAB86 BC9C6D6A 5207194E 67FA3555 1B568026 7B00641C 1024 0F212D18 ECA8D732 7ED91FE7 64A84EA1 B43FF5B4 F6E8E62F 1025 05C661DE FB258877 C35B18A1 51D5C414 AAAD97BA 3E499332 1026 E596078E 600DEB81 149C441C E95782F2 2A282563 C5BAC141 1027 1423605D 1AE1AFAE 2C8B0660 237EC128 AA0FE346 4E435811 1028 5DB84CC3 B523073A 28D45498 84B81FF7 0E10BF36 1C137296 1029 28D5348F 07211E7E 4CF4F18B 286090BD B1240B66 D6CD4AFC 1030 EADC00CA 446CE050 50FF183A D2BBF118 C1FC0EA5 1F97D22B 1031 8F7E4670 5D4527F4 5B42AEFF 39585337 6F697DD5 FDF2C518 1032 7D7D5F0E 2EB8D43F 17BA0F7C 60FF437F 535DFEF2 9833BF86 1033 CBE88EA4 FBD4221E 84117283 54FA30A7 008F154A 41C7FC46 1034 6B4645DB E2E32126 7FFFFFFF FFFFFFFF 1036 The estimated symmetric-equivalent strength of this group is 192 1037 bits. 1039 Peers using ffdhe8192 that want to optimize their key exchange with a 1040 short exponent (Section 4.2) should choose a secret key of at least 1041 384 bits. 1043 Author's Address 1045 Daniel Kahn Gillmor 1046 ACLU 1047 125 Broad Street, 18th Floor 1048 New York, NY 10004 1049 USA 1051 Email: dkg@fifthhorseman.net