idnits 2.17.00 (12 Aug 2021) /tmp/idnits59051/draft-ietf-tls-negotiated-ff-dhe-00.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 (July 22, 2014) is 2859 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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 July 22, 2014 5 Expires: January 23, 2015 7 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS 8 draft-ietf-tls-negotiated-ff-dhe-00 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 establishing 18 a registry of DH parameters with known structure and a mechanism for 19 peers to indicate support for these groups. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 23, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 1.2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. ServerDHParams changes . . . . . . . . . . . . . . . . . 5 61 4. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Checking the Peer's Public Key . . . . . . . . . . . . . 6 63 4.2. Short Exponents . . . . . . . . . . . . . . . . . . . . . 6 64 4.3. Table Acceleration . . . . . . . . . . . . . . . . . . . 6 65 5. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Server Indication of support . . . . . . . . . . . . . . 7 67 5.2. Normalizing Weak Groups . . . . . . . . . . . . . . . . . 7 68 5.3. Arbitrary Groups . . . . . . . . . . . . . . . . . . . . 7 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8.1. Negotiation resistance to active attacks . . . . . . . . 8 73 8.2. DHE only . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.3. Deprecating weak groups . . . . . . . . . . . . . . . . . 9 75 8.4. Choice of groups . . . . . . . . . . . . . . . . . . . . 10 76 8.5. Timing attacks . . . . . . . . . . . . . . . . . . . . . 10 77 8.6. Replay attacks from non-negotiated FF DHE . . . . . . . . 10 78 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 79 9.1. Client fingerprinting . . . . . . . . . . . . . . . . . . 11 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 10.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Appendix A. Named Group Registry . . . . . . . . . . . . . . . . 12 84 A.1. ffdhe2432 . . . . . . . . . . . . . . . . . . . . . . . . 13 85 A.2. ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 13 86 A.3. ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 14 87 A.4. ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . . 15 88 A.5. ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 17 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 Traditional TLS [RFC5246] offers a Diffie-Hellman ephemeral (DHE) key 94 exchange mode which provides Perfect Forward Secrecy for the 95 connection. The client offers a ciphersuite in the ClientHello that 96 includes DHE, and the server offers the client group parameters g and 97 p. If the client does not consider the group strong enough (e.g. if 98 p is too small, or if p is not prime, or there are small subgroups), 99 or if it is unable to process it for other reasons, it has no 100 recourse but to terminate the connection. 102 Conversely, when a TLS server receives a suggestion for a DHE 103 ciphersuite from a client, it has no way of knowing what kinds of DH 104 groups the client is capable of handling, or what the client's 105 security requirements are for this key exchange session. Some 106 widely-distributed TLS clients are not capable of DH groups where p > 107 1024. Other TLS clients may by policy wish to use DHE only if the 108 server can offer a stronger group (and are willing to use a non-PFS 109 key-exchange mechanism otherwise). The server has no way of knowing 110 which type of client is connecting, but must select DHE parameters 111 with insufficient knowledge. 113 Additionally, the DH parameters chosen by the server may have a known 114 structure which renders them secure against small subgroup attack, 115 but a client receiving an arbitrary p has no efficient way to verify 116 that the structure of a new group is reasonable for use. 118 This extension solves these problems with a registry of groups of 119 known reasonable structure, an extension for clients to advertise 120 support for them and servers to select them, and guidance for 121 compliant peers to take advantage of the additional security, 122 availability, and efficiency offered. 124 The use of this extension by one compliant peer when interacting with 125 a non-compliant peer should have no detrimental effects. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 1.2. Vocabulary 135 The term "DHE" is used in this document to refer to the finite-field- 136 based Diffie-Hellman ephemeral key exchange mechanism in TLS. TLS 137 also supports elliptic-curve-based Diffie Hellman ephemeral key 138 exchanges, but this document does not discuss their use. Mentions of 139 DHE here refer strictly to finite-field-based DHE, and not to ECDHE. 141 2. Client Behavior 143 A TLS client that is capable of using strong finite field Diffie- 144 Hellman groups can advertise its capabilities and its preferences for 145 stronger key exchange by using this mechanism. 147 The client SHOULD send an extension of type 148 "negotiated_ff_dhe_groups" in the ClientHello, indicating a list of 149 known finite field Diffie-Hellman groups, ordered from most preferred 150 to least preferred. 152 The "extension_data" field of this extension SHALL contain 153 "FiniteFieldDHEGroups" where: 155 enum { 156 ffdhe2432(0), ffdhe3072(1), ffdhe4096(2), 157 ffdhe6144(3), ffdhe8192(4), (255) 158 } FiniteFieldDHEGroup; 160 struct { 161 FiniteFieldDHEGroup finite_field_dhe_group_list<1..2^8-1>; 162 } FiniteFieldDHEGroups; 164 A client that offers this extension SHOULD include at least one DHE- 165 key-exchange ciphersuite in the Client Hello. 167 The known groups defined by the FiniteFieldDHEGroup registry are 168 listed in Appendix A. These are all safe primes derived from the 169 base of the natural logarithm ("e"), with the high and low 64 bits 170 set to 1 for efficient Montgomery or Barrett reduction. 172 The use of the base of the natural logarithm here is as a "nothing- 173 up-my-sleeve" number. The goal is to guarantee that the bits in the 174 middle of the modulus that they are effectively random, while 175 avoiding any suspicion that the primes have secretly been selected to 176 be weak according to some secret criteria. [RFC3526] used pi for 177 this value. See Section 8.4 for reasons that this draft does not 178 reuse pi. 180 A client who offers a group MUST be able and willing to perform a DH 181 key exchange using that group. 183 3. Server Behavior 185 A TLS server MUST NOT send the NegotiatedDHParams extension to a 186 client that does not offer it first. 188 A compatible TLS server that receives this extension from a client 189 SHOULD NOT select a DHE ciphersuite if it is unwilling to use one of 190 the DH groups named by the client. In this case, it SHOULD select an 191 acceptable non-DHE ciphersuite from the client's offered list. If 192 the extension is present, none of the client's offered groups are 193 acceptable by the server, and none of the client's proposed non-DHE 194 ciphersuites are acceptable to the server, the server SHOULD end the 195 connection with a fatal TLS alert of type insufficient_security. 197 A compatible TLS server that receives this extension from a client 198 and selects a DHE-key-exchange ciphersuite selects one of the offered 199 groups and indicates it to the client in the ServerHello by sending a 200 "negotiated_ff_dhe_groups" extension. The "extension_data" field of 201 this extension on the server side should be a single one-byte value 202 FiniteFieldDHEGroup. 204 A TLS server MUST NOT select a named group that was not offered by 205 the client. 207 If a non-anonymous DHE ciphersuite is chosen, and the TLS client has 208 used this extension to offer a DHE group of comparable or greater 209 strength than the server's public key, the server SHOULD select a DHE 210 group at least as strong as the server's public key. For example, if 211 the server has a 3072-bit RSA key, and the client offers only 212 ffdhe2432 and ffdhe4096, the server SHOULD select ffdhe4096. 214 3.1. ServerDHParams changes 216 When the server sends the "negotiated_ff_dhe_groups" extension in the 217 ServerHello, the ServerDHParams member of the subsequent 218 ServerKeyExchange message should indicate a one-byte zero value (0) 219 in place of dh_g and the identifier of the named group in place of 220 dh_p, represented as a one-byte value. dh_Ys must be transmitted as 221 normal. 223 This re-purposing of dh_p and dh_g is unambiguous: there are no 224 groups with a generator of 0, and no implementation should accept a 225 modulus of size < 9 bits. This change serves two purposes: 227 The size of the handshake is reduced (significantly, in the case 228 of a large prime modulus). 230 The signed struct should not be re-playable in a subsequent key 231 exchange that does not indicate named DH groups. 233 4. Optimizations 235 In a successfully negotiated finite field DH group key exchange, both 236 peers know that the group in question uses a safe prime as a modulus, 237 and that the group in use is of size p-1 or (p-1)/2. This allows at 238 least three optimizations that can be used to improve performance. 240 4.1. Checking the Peer's Public Key 242 Peers should validate the each other's public key Y (dh_Ys offered by 243 the server or DH_Yc offered by the client) by ensuring that 1 < Y < 244 p-1. This simple check ensures that the remote peer is properly 245 behaved and isn't forcing the local system into a small subgroup. 247 To reach the same assurance with an unknown group, the client would 248 need to verify the primality of the modulus, learn the factors of 249 p-1, and test Y against each factor. 251 4.2. Short Exponents 253 Traditional Finite Field Diffie-Hellman has each peer choose their 254 secret exponent from the range [2,p-2]. Using exponentiation by 255 squaring, this means each peer must do roughly 2*log_2(p) 256 multiplications, twice (once for the generator and once for the 257 peer's public key). 259 Peers concerned with performance may also prefer to choose their 260 secret exponent from a smaller range, doing fewer multiplications, 261 while retaining the same level of overall security. Each named group 262 indicates its approximate security level, and provides a lower-bound 263 on the range of secret exponents that should preserve it. For 264 example, rather than doing 2*2*2432 multiplications for a ffdhe2432 265 handshake, each peer can choose to do 2*2*224 multiplications by 266 choosing their secret exponent in the range [2,2^224] and still keep 267 the approximate 112-bit security level. 269 A similar short-exponent approach is suggested in SSH's Diffie- 270 Hellman key exchange (See section 6.2 of [RFC4419]). 272 4.3. Table Acceleration 274 Peers wishing to further accelerate DHE key exchange can also pre- 275 compute a table of powers of the generator of a known group. This is 276 a memory vs. time tradeoff, and it only accelerates the first 277 exponentiation of the ephemeral DH exchange (the exponentiation using 278 the peer's public exponent as a base still needs to be done as 279 normal). 281 5. Open Questions 283 [This section should be removed, and questions resolved, before any 284 formalization of this draft] 286 5.1. Server Indication of support 288 Some servers will support this extension, but for whatever reason 289 decide to not negotiate a ciphersuite with DHE key exchange at all. 290 Some possible reasons include: 292 The client indicated that a server-supported non-DHE ciphersuite 293 was preferred over all DHE ciphersuites, and the server honors 294 that preference. 296 The server prefers a client-supported non-DHE ciphersuite over all 297 DHE ciphersuites, and selects it unilaterally. 299 The server would have chosen a DHE ciphersuite, but none of the 300 client's offered groups are acceptable to the server, 302 Clients will not know that such a server supports the extension. 304 Should we offer a way for a server to indicate its support for this 305 extension to a compatible client in this case? 307 Should the server have a way to advertise that it supports this 308 extension even if the client does not offer it? 310 5.2. Normalizing Weak Groups 312 Is there any reason to include a weak group in the list of groups? 313 Most DHE-capable peers can already handle 1024-bit DHE, and therefore 314 1024-bit DHE does not need to be negotiated. Properly-chosen 315 2432-bit DH groups should be roughly equivalent to 112-bit security. 316 And future implementations should use sizes of at least 3072 bits 317 according to [ENISA]. 319 5.3. Arbitrary Groups 321 This spec currently doesn't indicate any support for groups other 322 than the named groups. Other DHE specifications have moved away from 323 staticly-named groups with the explicitly-stated rationale of 324 reducing the incentive for precomputation-driven attacks on any 325 specific group (e.g. section 1 of [RFC4419]). However, arbitrary 326 large groups are expensive to transmit over the network and it is 327 computationally infeasible for the client to verify their structure 328 during a key exchange. If we instead allow the server to propose 329 arbitrary groups, we could make it a MUST that the generated groups 330 use safe prime moduli, while still allowing clients to signal support 331 (and desire) for large groups. This leaves the client in the 332 position of relying on the server to choose a strong modulus, though. 334 Note that in at least one known attack against TLS 335 [SECURE-RESUMPTION], a malicious server uses a deliberately broken 336 finite field DHE group to impersonate the client to a different 337 server. 339 6. Acknowledgements 341 Thanks to Fedor Brunner, Dave Fergemann, Sandy Harris, Watson Ladd, 342 Nikos Mavrogiannopolous, Niels Moeller, Kenny Paterson, and Tom 343 Ritter for their comments and suggestions on this draft. Any 344 mistakes here are not theirs. 346 7. IANA Considerations 348 This document defines a new TLS extension, "negotiated_dh_group", 349 assigned a value of XXX from the TLS ExtensionType registry defined 350 in section 12 of [RFC5246]. This value is used as the extension 351 number for the extensions in both the client hello message and the 352 server hello message. 354 Appendix A defines a TLS Finite Field DHE Named Group Registry. Each 355 entry in this registry indicates the group itself, its derivation, 356 its expected strength (estimated roughly from guidelines in 357 [ECRYPTII]), and whether it is recommended for use in TLS key 358 exchange at the given security level. This registry may be updated 359 by the addition of new finite field groups, and by reassessments of 360 the security level or utility to TLS of any already present group. 361 Updates are made by IETF Review [RFC5226], and should consider 362 Section 9.1. 364 8. Security Considerations 366 8.1. Negotiation resistance to active attacks 368 Because the contents of this extension is hashed in the finished 369 message, an active MITM that tries to filter or omit groups will 370 cause the handshake to fail, but possibly not before getting the peer 371 to do something they would not otherwise have done. 373 An attacker who impersonates the server can try to do any of the 374 following: 376 Pretend that a non-compatible server is actually capable of this 377 extension, and select a group from the client's list, causing the 378 client to select a group it is willing to negotiate. It is 379 unclear how this would be an effective attack. 381 Pretend that a compatible server is actually non-compatible by 382 negotiating a non-DHE ciphersuite. This is no different than MITM 383 ciphersuite filtering. 385 Pretend that a compatible server is actually non-compatible by 386 negotiating a DHE ciphersuite and no extension, with an explicit 387 (perhaps weak) group chosen by the server. [XXX what are the 388 worst consequences in this case? What might the client leak 389 before it notices that the handshake fails? XXX] 391 An attacker who impersonates the client can try to do the following: 393 Pretend that a compatible client is not compliant (e.g. by not 394 offering this extension). This could cause the server to 395 negotiate a weaker DHE group during the handshake, but it would 396 fail to complete during the final check of the Finished message. 398 Pretend that a non-compatible client is compatible. This could 399 cause the server to send what appears to be an extremely odd 400 ServerDHParams (see Section 3.1), and the check in the Finished 401 message would fail. It is not clear how this could be an attack. 403 Change the list of groups offered by the client (e.g. by removing 404 the stronger of the set of groups offered). This could cause the 405 server to negotiate a weaker group than desired, but again should 406 be caught by the check in the Finished message. 408 8.2. DHE only 410 Note that this extension specifically targets only finite field-based 411 Diffie-Hellman ephemeral key exchange mechanisms. It does not cover 412 the non-ephemeral DH key exchange mechanisms, nor does it cover 413 elliptic curve-based DHE key exchange, which has its own list of 414 named groups. 416 8.3. Deprecating weak groups 418 Advances in hardware or in finite field cryptanalysis may cause some 419 of the negotiated groups to not provide the desired security margins, 420 as indicated by the estimated work factor of an adversary to discover 421 the premaster secret (and therefore compromise the confidentiality 422 and integrity of the TLS session). 424 Revisions of this extension or updates should mark known-weak groups 425 as explicitly deprecated for use in TLS, and should update the 426 estimated work factor needed to break the group, if the cryptanalysis 427 has changed. Implementations that require strong confidentiality and 428 integrity guarantees should avoid using deprecated groups and should 429 be updated when the estimated security margins are updated. 431 8.4. Choice of groups 433 Other lists of named finite field Diffie-Hellman groups 434 [STRONGSWAN-IKE] exist. This draft chooses to not reuse them for 435 several reasons: 437 Using the same groups in multiple protocols increases the value 438 for an attacker with the resources to crack any single group. 440 The IKE groups include weak groups like MODP768 which are 441 unacceptable for secure TLS traffic. 443 Mixing group parameters across multiple implementations leaves 444 open the possibility of some sort of cross-protocol attack. This 445 shouldn't be relevant for ephemeral scenarios, and even with non- 446 ephemeral keying, services shouldn't share keys; however, using 447 different groups avoids these failure modes entirely. 449 Other lists of named FF DHE groups are not collected in a single 450 IANA registry, or are mixed with non-FF DHE groups, which makes 451 them inconvenient for re-use in a TLS DHE key exchange context. 453 8.5. Timing attacks 455 Any implementation of finite field Diffie-Hellman key exchange should 456 use constant-time modular-exponentiation implementations. This is 457 particularly true for those implementations that ever re-use DHE 458 secret keys (so-called "semi-static" ephemeral keying) or share DHE 459 secret keys across a multiple machines (e.g. in a load-balancer 460 situation). 462 8.6. Replay attacks from non-negotiated FF DHE 464 [SECURE-RESUMPTION] shows a malicious peer using a bad FF DHE group 465 to maneuver a client into selecting a pre-master secret of the peer's 466 choice, which can be replayed to another server using a non-DHE key 467 exchange, and can then be bootstrapped to replay client 468 authentication. 470 To prevent this attack (barring the fixes proposed in 471 [SESSION-HASH]), a client would need not only to implement this 472 draft, but also to reject non-negotiated FF DHE ciphersuites whose 473 group structure it cannot afford to verify. Such a client would need 474 to abort the initial handshake and reconnect to the server in 475 question without listing any FF DHE ciphersuites on the subsequent 476 connection. 478 This tradeoff may be too costly for most TLS clients today, but may 479 be a reasonable choice for clients performing client certificate 480 authentication, or who have other reason to be concerned about 481 server-controlled pre-master secrets. 483 9. Privacy Considerations 485 9.1. Client fingerprinting 487 This extension provides a few additional bits of information to 488 distinguish between classes of TLS clients (see e.g. 489 [PANOPTICLICK]). To minimize this sort of fingerprinting, clients 490 SHOULD support all named groups at or above their minimum security 491 threshhold. New named groups SHOULD NOT be added to the registry 492 without consideration of the cost of browser fingerprinting. 494 10. References 496 10.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 10.2. Informative References 503 [ECRYPTII] 504 European Network of Excellence in Cryptology II, "ECRYPT 505 II Yearly Report on Algorithms and Keysizes (2011-2012)", 506 September 2012, 507 . 509 [ENISA] European Union Agency for Network and Information Security 510 Agency, "Algorithms, Key Sizes and Parameters Report, 511 version 1.0", October 2013, 512 . 516 [PANOPTICLICK] 517 Electronic Frontier Foundation, "Panopticlick: How Unique 518 - and Trackable - Is Your Browser?", 2010, 519 . 521 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 522 Diffie-Hellman groups for Internet Key Exchange (IKE)", 523 RFC 3526, May 2003. 525 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 526 Group Exchange for the Secure Shell (SSH) Transport Layer 527 Protocol", RFC 4419, March 2006. 529 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 530 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 531 May 2008. 533 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 534 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 536 [SECURE-RESUMPTION] 537 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 538 "Triple Handshakes Considered Harmful: Breaking and Fixing 539 Authentication over TLS", March 2014, . 542 [SESSION-HASH] 543 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 544 A., and M. Ray, "Triple Handshakes Considered Harmful: 545 Breaking and Fixing Authentication over TLS", March 2014, 546 . 549 [STRONGSWAN-IKE] 550 Brunner, T. and A. Steffen, "Diffie Hellman Groups in 551 IKEv2 Cipher Suites", October 2013, 552 . 555 Appendix A. Named Group Registry 557 The primes in these finite field groups are all safe primes, that is, 558 a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is 559 the base of the natural logarithm, and square brackets denote the 560 floor operation, the groups which initially populate this registry 561 are derived for a given bitlength b by finding the lowest positive 562 integer X that creates a safe prime p where: 564 p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1 566 New additions to this registry may use this same derivation (e.g. 567 with different bitlengths) or may choose their parameters in a 568 different way, but must be clear about how the parameters were 569 derived. 571 A.1. ffdhe2432 573 The 2432-bit group has registry value 0, and is calcluated from the 574 following formula: 576 The modulus is: p = 2^2432 - 2^2368 + {[2^2302 * e] + 2111044} * 2^64 577 - 1 579 Its hexadecimal representation is: 581 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 582 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 583 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 584 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 585 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 586 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 587 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 588 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 589 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 590 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 591 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 592 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 593 AEFE1309 8533C8B3 FFFFFFFF FFFFFFFF 595 The generator is: g = 2 597 The group size is (p-1)/2 599 The estimated symmetric-equivalent strength of this group is 112 600 bits. 602 Peers using ffdhe2432 that want to optimize their key exchange with a 603 short exponent (Section 4.2) should choose a secret key of at least 604 224 bits. 606 A.2. ffdhe3072 608 The 3072-bit prime has registry value 1, and is calcluated from the 609 following formula: 611 p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 -1 613 Its hexadecimal representation is: 615 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 616 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 617 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 618 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 619 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 620 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 621 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 622 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 623 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 624 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 625 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 626 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 627 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 628 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 629 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 630 3C1B20EE 3FD59D7C 25E41D2B 66C62E37 FFFFFFFF FFFFFFFF 632 The generator is: g = 2 634 The group size is: (p-1)/2 636 The estimated symmetric-equivalent strength of this group is 125 637 bits. 639 Peers using ffdhe3072 that want to optimize their key exchange with a 640 short exponent (Section 4.2) should choose a secret key of at least 641 250 bits. 643 A.3. ffdhe4096 645 The 4096-bit group has registry value 2, and is calcluated from the 646 following formula: 648 The modulus is: p = 2^4096 - 2^4032 + {[2^3966 * e] + 5736041} * 2^64 649 - 1 651 Its hexadecimal representation is: 653 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 654 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 655 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 656 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 657 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 658 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 659 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 660 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 661 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 662 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 663 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 664 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 665 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 666 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 667 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 668 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 669 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 670 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 671 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 672 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 673 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E655F6A 674 FFFFFFFF FFFFFFFF 676 The base is: g = 2 678 The group size is: (p-1)/2 680 The estimated symmetric-equivalent strength of this group is 150 681 bits. 683 Peers using ffdhe4096 that want to optimize their key exchange with a 684 short exponent (Section 4.2) should choose a secret key of at least 685 300 bits. 687 A.4. ffdhe6144 689 The 6144-bit group has registry value 3, and is calcluated from the 690 following formula: 692 The modulus is: p = 2^6144 - 2^6080 + {[2^6014 * e] + 15705020} * 693 2^64 - 1 695 Its hexadecimal representation is: 697 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 698 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 699 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 700 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 701 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 702 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 703 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 704 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 705 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 706 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 707 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 708 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 709 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 710 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 711 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 712 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 713 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 714 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 715 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 716 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 717 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 718 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 719 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A 720 CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 721 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 722 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 723 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 724 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C 725 D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A 726 E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 727 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 728 A41D570D 7938DAD4 A40E329C D0E40E65 FFFFFFFF FFFFFFFF 730 The generator is: 2 732 The group size is: (p-1)/2 734 The estimated symmetric-equivalent strength of this group is 175 735 bits. 737 Peers using ffdhe6144 that want to optimize their key exchange with a 738 short exponent (Section 4.2) should choose a secret key of at least 739 350 bits. 741 A.5. ffdhe8192 743 The 8192-bit group has registry value 4, and is calcluated from the 744 following formula: 746 The modulus is: p = 2^8192 - 2^8128 + {[2^8062 * e] + 10965728} * 747 2^64 - 1 749 Its hexadecimal representation is: 751 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 752 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 753 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 754 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 755 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 756 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 757 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 758 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 759 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 760 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 761 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 762 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 763 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 764 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 765 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 766 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 767 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 768 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 769 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 770 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 771 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 772 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 773 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A 774 CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 775 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 776 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 777 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 778 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C 779 D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A 780 E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 781 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 782 A41D570D 7938DAD4 A40E329C CFF46AAA 36AD004C F600C838 783 1E425A31 D951AE64 FDB23FCE C9509D43 687FEB69 EDD1CC5E 784 0B8CC3BD F64B10EF 86B63142 A3AB8829 555B2F74 7C932665 785 CB2C0F1C C01BD702 29388839 D2AF05E4 54504AC7 8B758282 786 2846C0BA 35C35F5C 59160CC0 46FD8251 541FC68C 9C86B022 787 BB709987 6A460E74 51A8A931 09703FEE 1C217E6C 3826E52C 788 51AA691E 0E423CFC 99E9E316 50C1217B 624816CD AD9A95F9 789 D5B80194 88D9C0A0 A1FE3075 A577E231 83F81D4A 3F2FA457 790 1EFC8CE0 BA8A4FE8 B6855DFE 72B0A66E DED2FBAB FBE58A30 791 FAFABE1C 5D71A87E 2F741EF8 C1FE86FE A6BBFDE5 30677F0D 792 97D11D49 F7A8443D 0822E506 A9F4614E 011E2A94 838FF88C 793 D68C8BB7 C5C6424C FFFFFFFF FFFFFFFF 795 The base is: g = 2 797 The group size is: (p-1)/2 798 The estimated symmetric-equivalent strength of this group is 192 799 bits. 801 Peers using ffdhe8192 that want to optimize their key exchange with a 802 short exponent (Section 4.2) should choose a secret key of at least 803 384 bits. 805 Author's Address 807 Daniel Kahn Gillmor 808 ACLU 809 125 Broad Street, 18th Floor 810 New York, NY 10004 811 USA 813 Email: dkg@fifthhorseman.net