idnits 2.17.1 draft-ietf-tls-negotiated-ff-dhe-01.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 (August 27, 2014) is 3530 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 August 27, 2014 5 Expires: February 28, 2015 7 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS 8 draft-ietf-tls-negotiated-ff-dhe-01 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 February 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 13 84 A.1. ffdhe2432 . . . . . . . . . . . . . . . . . . . . . . . . 13 85 A.2. ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 14 86 A.3. ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 16 87 A.4. ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . . 17 88 A.5. ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 19 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 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 DH 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 a 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 (ECDHE) ephemeral 138 key exchanges, but this document does not discuss their use. 139 Mentions of DHE here refer strictly to finite-field-based DHE, and 140 not to ECDHE. 142 2. Client Behavior 144 A TLS client that is capable of using strong finite field Diffie- 145 Hellman groups can advertise its capabilities and its preferences for 146 stronger key exchange by using this mechanism. 148 The client SHOULD send an extension of type 149 "negotiated_ff_dhe_groups" in the ClientHello, indicating a list of 150 known finite field Diffie-Hellman groups, ordered from most preferred 151 to least preferred. 153 The "extension_data" field of this extension SHALL contain 154 "FiniteFieldDHEGroups" where: 156 enum { 157 ffdhe2432(0), ffdhe3072(1), ffdhe4096(2), 158 ffdhe6144(3), ffdhe8192(4), (255) 159 } FiniteFieldDHEGroup; 161 struct { 162 FiniteFieldDHEGroup finite_field_dhe_group_list<1..2^8-1>; 163 } FiniteFieldDHEGroups; 165 A client that offers this extension SHOULD include at least one DHE- 166 key-exchange ciphersuite in the Client Hello. 168 The known groups defined by the FiniteFieldDHEGroup registry are 169 listed in Appendix A. These are all safe primes derived from the 170 base of the natural logarithm ("e"), with the high and low 64 bits 171 set to 1 for efficient Montgomery or Barrett reduction. 173 The use of the base of the natural logarithm here is as a "nothing- 174 up-my-sleeve" number. The goal is to guarantee that the bits in the 175 middle of the modulus are effectively random, while avoiding any 176 suspicion that the primes have secretly been selected to be weak 177 according to some secret criteria. [RFC3526] used pi for this value. 178 See Section 8.4 for reasons that this draft does not 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 both the generator g and Y against each factor to avoid 250 small subgroup attacks. 252 4.2. Short Exponents 254 Traditional Finite Field Diffie-Hellman has each peer choose their 255 secret exponent from the range [2,p-2]. Using exponentiation by 256 squaring, this means each peer must do roughly 2*log_2(p) 257 multiplications, twice (once for the generator and once for the 258 peer's public key). 260 Peers concerned with performance may also prefer to choose their 261 secret exponent from a smaller range, doing fewer multiplications, 262 while retaining the same level of overall security. Each named group 263 indicates its approximate security level, and provides a lower-bound 264 on the range of secret exponents that should preserve it. For 265 example, rather than doing 2*2*2432 multiplications for a ffdhe2432 266 handshake, each peer can choose to do 2*2*224 multiplications by 267 choosing their secret exponent in the range [2,2^224] and still keep 268 the approximate 112-bit security level. 270 A similar short-exponent approach is suggested in SSH's Diffie- 271 Hellman key exchange (See section 6.2 of [RFC4419]). 273 4.3. Table Acceleration 275 Peers wishing to further accelerate DHE key exchange can also pre- 276 compute a table of powers of the generator of a known group. This is 277 a memory vs. time tradeoff, and it only accelerates the first 278 exponentiation of the ephemeral DH exchange (the exponentiation using 279 the peer's public exponent as a base still needs to be done as 280 normal). 282 5. Open Questions 284 [This section should be removed, and questions resolved, before any 285 formalization of this draft] 287 5.1. Server Indication of support 289 Some servers will support this extension, but for whatever reason 290 decide to not negotiate a ciphersuite with DHE key exchange at all. 291 Some possible reasons include: 293 The client indicated that a server-supported non-DHE ciphersuite 294 was preferred over all DHE ciphersuites, and the server honors 295 that preference. 297 The server prefers a client-supported non-DHE ciphersuite over all 298 DHE ciphersuites, and selects it unilaterally. 300 The server would have chosen a DHE ciphersuite, but none of the 301 client's offered groups are acceptable to the server, 303 Clients will not know that such a server supports the extension. 305 Should we offer a way for a server to indicate its support for this 306 extension to a compatible client in this case? 308 Should the server have a way to advertise that it supports this 309 extension even if the client does not offer it? 311 5.2. Normalizing Weak Groups 313 Is there any reason to include a weak group in the list of groups? 314 Most DHE-capable peers can already handle 1024-bit DHE, and therefore 315 1024-bit DHE does not need to be negotiated. Properly-chosen 316 2432-bit DH groups should be roughly equivalent to 112-bit security. 317 And future implementations should use sizes of at least 3072 bits 318 according to [ENISA]. 320 5.3. Arbitrary Groups 322 This spec currently doesn't indicate any support for groups other 323 than the named groups. Other DHE specifications have moved away from 324 staticly-named groups with the explicitly-stated rationale of 325 reducing the incentive for precomputation-driven attacks on any 326 specific group (e.g. section 1 of [RFC4419]). However, arbitrary 327 large groups are expensive to transmit over the network and it is 328 computationally infeasible for the client to verify their structure 329 during a key exchange. If we instead allow the server to propose 330 arbitrary groups, we could make it a MUST that the generated groups 331 use safe prime moduli, while still allowing clients to signal support 332 (and desire) for large groups. This leaves the client in the 333 position of relying on the server to choose a strong modulus, though. 335 Note that in several known attacks against TLS and SSL 336 [SECURE-RESUMPTION] [CROSS-PROTOCOL] [SSL3-ANALYSIS], a malicious 337 server uses a deliberately broken finite field DHE group to 338 impersonate the client to a different server. 340 6. Acknowledgements 342 Thanks to Fedor Brunner, Dave Fergemann, Sandy Harris, Watson Ladd, 343 Nikos Mavrogiannopolous, Niels Moeller, Kenny Paterson, and Tom 344 Ritter for their comments and suggestions on this draft. Any 345 mistakes here are not theirs. 347 7. IANA Considerations 349 This document defines a new TLS extension, "negotiated_dh_group", 350 assigned a value of XXX from the TLS ExtensionType registry defined 351 in section 12 of [RFC5246]. This value is used as the extension 352 number for the extensions in both the client hello message and the 353 server hello message. 355 Appendix A defines a TLS Finite Field DHE Named Group Registry. Each 356 entry in this registry indicates the group itself, its derivation, 357 its expected strength (estimated roughly from guidelines in 358 [ECRYPTII]), and whether it is recommended for use in TLS key 359 exchange at the given security level. This registry may be updated 360 by the addition of new finite field groups, and by reassessments of 361 the security level or utility to TLS of any already present group. 362 Updates are made by IETF Review [RFC5226], and should consider 363 Section 9.1. 365 8. Security Considerations 367 8.1. Negotiation resistance to active attacks 369 Because the contents of this extension is hashed in the finished 370 message, an active MITM that tries to filter or omit groups will 371 cause the handshake to fail, but possibly not before getting the peer 372 to do something they would not otherwise have done. 374 An attacker who impersonates the server can try to do any of the 375 following: 377 Pretend that a non-compatible server is actually capable of this 378 extension, and select a group from the client's list, causing the 379 client to select a group it is willing to negotiate. It is 380 unclear how this would be an effective attack. 382 Pretend that a compatible server is actually non-compatible by 383 negotiating a non-DHE ciphersuite. This is no different than MITM 384 ciphersuite filtering. 386 Pretend that a compatible server is actually non-compatible by 387 negotiating a DHE ciphersuite and no extension, with an explicit 388 (perhaps weak) group chosen by the server. [XXX what are the 389 worst consequences in this case? What might the client leak 390 before it notices that the handshake fails? XXX] 392 An attacker who impersonates the client can try to do the following: 394 Pretend that a compatible client is not compliant (e.g. by not 395 offering this extension). This could cause the server to 396 negotiate a weaker DHE group during the handshake, but it would 397 fail to complete during the final check of the Finished message. 399 Pretend that a non-compatible client is compatible. This could 400 cause the server to send what appears to be an extremely odd 401 ServerDHParams (see Section 3.1), and the check in the Finished 402 message would fail. It is not clear how this could be an attack. 404 Change the list of groups offered by the client (e.g. by removing 405 the stronger of the set of groups offered). This could cause the 406 server to negotiate a weaker group than desired, but again should 407 be caught by the check in the Finished message. 409 8.2. DHE only 411 Note that this extension specifically targets only finite field-based 412 Diffie-Hellman ephemeral key exchange mechanisms. It does not cover 413 the non-ephemeral DH key exchange mechanisms, nor does it cover 414 elliptic curve-based DHE key exchange, which has its own list of 415 named groups. 417 8.3. Deprecating weak groups 419 Advances in hardware or in finite field cryptanalysis may cause some 420 of the negotiated groups to not provide the desired security margins, 421 as indicated by the estimated work factor of an adversary to discover 422 the premaster secret (and therefore compromise the confidentiality 423 and integrity of the TLS session). 425 Revisions of this extension or updates should mark known-weak groups 426 as explicitly deprecated for use in TLS, and should update the 427 estimated work factor needed to break the group, if the cryptanalysis 428 has changed. Implementations that require strong confidentiality and 429 integrity guarantees should avoid using deprecated groups and should 430 be updated when the estimated security margins are updated. 432 8.4. Choice of groups 434 Other lists of named finite field Diffie-Hellman groups 435 [STRONGSWAN-IKE] exist. This draft chooses to not reuse them for 436 several reasons: 438 Using the same groups in multiple protocols increases the value 439 for an attacker with the resources to crack any single group. 441 The IKE groups include weak groups like MODP768 which are 442 unacceptable for secure TLS traffic. 444 Mixing group parameters across multiple implementations leaves 445 open the possibility of some sort of cross-protocol attack. This 446 shouldn't be relevant for ephemeral scenarios, and even with non- 447 ephemeral keying, services shouldn't share keys; however, using 448 different groups avoids these failure modes entirely. 450 Other lists of named FF DHE groups are not collected in a single 451 IANA registry, or are mixed with non-FF DHE groups, which makes 452 them inconvenient for re-use in a TLS DHE key exchange context. 454 8.5. Timing attacks 456 Any implementation of finite field Diffie-Hellman key exchange should 457 use constant-time modular-exponentiation implementations. This is 458 particularly true for those implementations that ever re-use DHE 459 secret keys (so-called "semi-static" ephemeral keying) or share DHE 460 secret keys across a multiple machines (e.g. in a load-balancer 461 situation). 463 8.6. Replay attacks from non-negotiated FF DHE 465 [SECURE-RESUMPTION] shows a malicious peer using a bad FF DHE group 466 to maneuver a client into selecting a pre-master secret of the peer's 467 choice, which can be replayed to another server using a non-DHE key 468 exchange, and can then be bootstrapped to replay client 469 authentication. 471 To prevent this attack (barring the fixes proposed in 472 [SESSION-HASH]), a client would need not only to implement this 473 draft, but also to reject non-negotiated FF DHE ciphersuites whose 474 group structure it cannot afford to verify. Such a client would need 475 to abort the initial handshake and reconnect to the server in 476 question without listing any FF DHE ciphersuites on the subsequent 477 connection. 479 This tradeoff may be too costly for most TLS clients today, but may 480 be a reasonable choice for clients performing client certificate 481 authentication, or who have other reason to be concerned about 482 server-controlled pre-master secrets. 484 9. Privacy Considerations 486 9.1. Client fingerprinting 488 This extension provides a few additional bits of information to 489 distinguish between classes of TLS clients (see e.g. 490 [PANOPTICLICK]). To minimize this sort of fingerprinting, clients 491 SHOULD support all named groups at or above their minimum security 492 threshhold. New named groups SHOULD NOT be added to the registry 493 without consideration of the cost of browser fingerprinting. 495 10. References 497 10.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 10.2. Informative References 504 [CROSS-PROTOCOL] 505 Mavrogiannopolous, N., Vercauteren, F., Velichkov, V., and 506 B. Preneel, "A Cross-Protocol Attack on the TLS Protocol", 507 October 2012, 508 . 511 [ECRYPTII] 512 European Network of Excellence in Cryptology II, "ECRYPT 513 II Yearly Report on Algorithms and Keysizes (2011-2012)", 514 September 2012, 515 . 517 [ENISA] European Union Agency for Network and Information Security 518 Agency, "Algorithms, Key Sizes and Parameters Report, 519 version 1.0", October 2013, 520 . 524 [PANOPTICLICK] 525 Electronic Frontier Foundation, "Panopticlick: How Unique 526 - and Trackable - Is Your Browser?", 2010, 527 . 529 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 530 Diffie-Hellman groups for Internet Key Exchange (IKE)", 531 RFC 3526, May 2003. 533 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 534 Group Exchange for the Secure Shell (SSH) Transport Layer 535 Protocol", RFC 4419, March 2006. 537 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 538 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 539 May 2008. 541 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 542 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 544 [SECURE-RESUMPTION] 545 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 546 "Triple Handshakes Considered Harmful: Breaking and Fixing 547 Authentication over TLS", March 2014, . 550 [SESSION-HASH] 551 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 552 A., and M. Ray, "Triple Handshakes Considered Harmful: 553 Breaking and Fixing Authentication over TLS", March 2014, 554 . 557 [SSL3-ANALYSIS] 558 Schneier, B. and D. Wagner, "Analysis of the SSL 3.0 559 protocol", 1996, . 561 [STRONGSWAN-IKE] 562 Brunner, T. and A. Steffen, "Diffie Hellman Groups in 563 IKEv2 Cipher Suites", October 2013, 564 . 567 Appendix A. Named Group Registry 569 The primes in these finite field groups are all safe primes, that is, 570 a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is 571 the base of the natural logarithm, and square brackets denote the 572 floor operation, the groups which initially populate this registry 573 are derived for a given bitlength b by finding the lowest positive 574 integer X that creates a safe prime p where: 576 p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1 578 New additions to this registry may use this same derivation (e.g. 579 with different bitlengths) or may choose their parameters in a 580 different way, but must be clear about how the parameters were 581 derived. 583 A.1. ffdhe2432 585 The 2432-bit group has registry value 0, and is calcluated from the 586 following formula: 588 The modulus is: p = 2^2432 - 2^2368 + {[2^2302 * e] + 2111044} * 2^64 589 - 1 591 The hexadecimal representation of p is: 593 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 594 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 595 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 596 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 597 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 598 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 599 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 600 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 601 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 602 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 603 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 604 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 605 AEFE1309 8533C8B3 FFFFFFFF FFFFFFFF 607 The generator is: g = 2 608 The group size is: q = (p-1)/2 610 The hexadecimal representation of q is: 612 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 613 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 614 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 615 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 616 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 617 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 618 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 619 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 620 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 621 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 622 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 623 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 624 577F0984 C299E459 FFFFFFFF FFFFFFFF 626 The estimated symmetric-equivalent strength of this group is 112 627 bits. 629 Peers using ffdhe2432 that want to optimize their key exchange with a 630 short exponent (Section 4.2) should choose a secret key of at least 631 224 bits. 633 A.2. ffdhe3072 635 The 3072-bit prime has registry value 1, and is calcluated from the 636 following formula: 638 p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 -1 640 The hexadecimal representation of p is: 642 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 643 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 644 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 645 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 646 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 647 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 648 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 649 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 650 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 651 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 652 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 653 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 654 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 655 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 656 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 657 3C1B20EE 3FD59D7C 25E41D2B 66C62E37 FFFFFFFF FFFFFFFF 659 The generator is: g = 2 661 The group size is: q = (p-1)/2 663 The hexadecimal representation of q is: 665 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 666 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 667 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 668 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 669 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 670 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 671 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 672 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 673 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 674 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 675 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 676 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 677 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 678 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 679 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 680 9E0D9077 1FEACEBE 12F20E95 B363171B FFFFFFFF FFFFFFFF 682 The estimated symmetric-equivalent strength of this group is 125 683 bits. 685 Peers using ffdhe3072 that want to optimize their key exchange with a 686 short exponent (Section 4.2) should choose a secret key of at least 687 250 bits. 689 A.3. ffdhe4096 691 The 4096-bit group has registry value 2, and is calcluated from the 692 following formula: 694 The modulus is: p = 2^4096 - 2^4032 + {[2^3966 * e] + 5736041} * 2^64 695 - 1 697 The hexadecimal representation of p is: 699 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 700 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 701 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 702 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 703 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 704 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 705 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 706 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 707 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 708 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 709 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 710 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 711 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 712 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 713 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 714 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 715 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 716 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 717 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 718 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 719 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E655F6A 720 FFFFFFFF FFFFFFFF 722 The generator is: g = 2 724 The group size is: q = (p-1)/2 726 The hexadecimal representation of q is: 728 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 729 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 730 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 731 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 732 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 733 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 734 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 735 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 736 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 737 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 738 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 739 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 740 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 741 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 742 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 743 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D 744 BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 745 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 746 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 747 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 748 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F32AFB5 749 7FFFFFFF FFFFFFFF 751 The estimated symmetric-equivalent strength of this group is 150 752 bits. 754 Peers using ffdhe4096 that want to optimize their key exchange with a 755 short exponent (Section 4.2) should choose a secret key of at least 756 300 bits. 758 A.4. ffdhe6144 760 The 6144-bit group has registry value 3, and is calcluated from the 761 following formula: 763 The modulus is: p = 2^6144 - 2^6080 + {[2^6014 * e] + 15705020} * 764 2^64 - 1 766 The hexadecimal representation of p is: 768 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 769 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 770 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 771 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 772 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 773 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 774 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 775 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 776 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 777 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 778 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 779 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 780 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 781 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 782 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 783 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 784 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 785 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 786 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 787 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 788 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 789 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 790 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A 791 CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 792 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 793 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 794 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 795 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C 796 D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A 797 E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 798 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 799 A41D570D 7938DAD4 A40E329C D0E40E65 FFFFFFFF FFFFFFFF 801 The generator is: g = 2 803 The group size is: q = (p-1)/2 805 The hexadecimal representation of q is: 807 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 808 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 809 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 810 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 811 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 812 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 813 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 814 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 815 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 816 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 817 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 818 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 819 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 820 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 821 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 822 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D 823 BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 824 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 825 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 826 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 827 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 828 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 829 1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 830 66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B 831 D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1 832 855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA 833 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 834 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6 835 6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5 836 724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582 837 2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0 838 D20EAB86 BC9C6D6A 5207194E 68720732 FFFFFFFF FFFFFFFF 840 The estimated symmetric-equivalent strength of this group is 175 841 bits. 843 Peers using ffdhe6144 that want to optimize their key exchange with a 844 short exponent (Section 4.2) should choose a secret key of at least 845 350 bits. 847 A.5. ffdhe8192 849 The 8192-bit group has registry value 4, and is calcluated from the 850 following formula: 852 The modulus is: p = 2^8192 - 2^8128 + {[2^8062 * e] + 10965728} * 853 2^64 - 1 854 The hexadecimal representation of p is: 856 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 857 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 858 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 859 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 860 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 861 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 862 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 863 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 864 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 865 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 866 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 867 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 868 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 869 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 870 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 871 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 872 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 873 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 874 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 875 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 876 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 877 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 878 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A 879 CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 880 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 881 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 882 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 883 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C 884 D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A 885 E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 886 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 887 A41D570D 7938DAD4 A40E329C CFF46AAA 36AD004C F600C838 888 1E425A31 D951AE64 FDB23FCE C9509D43 687FEB69 EDD1CC5E 889 0B8CC3BD F64B10EF 86B63142 A3AB8829 555B2F74 7C932665 890 CB2C0F1C C01BD702 29388839 D2AF05E4 54504AC7 8B758282 891 2846C0BA 35C35F5C 59160CC0 46FD8251 541FC68C 9C86B022 892 BB709987 6A460E74 51A8A931 09703FEE 1C217E6C 3826E52C 893 51AA691E 0E423CFC 99E9E316 50C1217B 624816CD AD9A95F9 894 D5B80194 88D9C0A0 A1FE3075 A577E231 83F81D4A 3F2FA457 895 1EFC8CE0 BA8A4FE8 B6855DFE 72B0A66E DED2FBAB FBE58A30 896 FAFABE1C 5D71A87E 2F741EF8 C1FE86FE A6BBFDE5 30677F0D 897 97D11D49 F7A8443D 0822E506 A9F4614E 011E2A94 838FF88C 898 D68C8BB7 C5C6424C FFFFFFFF FFFFFFFF 900 The generator is: g = 2 901 The group size is: q = (p-1)/2 903 The hexadecimal representation of q is: 905 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 906 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 907 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 908 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 909 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 910 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 911 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 912 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 913 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 914 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 915 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 916 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 917 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 918 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 919 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 920 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D 921 BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 922 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 923 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 924 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 925 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 926 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 927 1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 928 66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B 929 D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1 930 855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA 931 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 932 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6 933 6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5 934 724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582 935 2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0 936 D20EAB86 BC9C6D6A 5207194E 67FA3555 1B568026 7B00641C 937 0F212D18 ECA8D732 7ED91FE7 64A84EA1 B43FF5B4 F6E8E62F 938 05C661DE FB258877 C35B18A1 51D5C414 AAAD97BA 3E499332 939 E596078E 600DEB81 149C441C E95782F2 2A282563 C5BAC141 940 1423605D 1AE1AFAE 2C8B0660 237EC128 AA0FE346 4E435811 941 5DB84CC3 B523073A 28D45498 84B81FF7 0E10BF36 1C137296 942 28D5348F 07211E7E 4CF4F18B 286090BD B1240B66 D6CD4AFC 943 EADC00CA 446CE050 50FF183A D2BBF118 C1FC0EA5 1F97D22B 944 8F7E4670 5D4527F4 5B42AEFF 39585337 6F697DD5 FDF2C518 945 7D7D5F0E 2EB8D43F 17BA0F7C 60FF437F 535DFEF2 9833BF86 946 CBE88EA4 FBD4221E 84117283 54FA30A7 008F154A 41C7FC46 947 6B4645DB E2E32126 7FFFFFFF FFFFFFFF 949 The estimated symmetric-equivalent strength of this group is 192 950 bits. 952 Peers using ffdhe8192 that want to optimize their key exchange with a 953 short exponent (Section 4.2) should choose a secret key of at least 954 384 bits. 956 Author's Address 958 Daniel Kahn Gillmor 959 ACLU 960 125 Broad Street, 18th Floor 961 New York, NY 10004 962 USA 964 Email: dkg@fifthhorseman.net