idnits 2.17.1 draft-gillmor-tls-negotiated-dl-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 (April 28, 2014) is 3645 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 April 28, 2014 5 Expires: October 30, 2014 7 Negotiated Discrete Log Diffie-Hellman Ephemeral Parameters for TLS 8 draft-gillmor-tls-negotiated-dl-dhe-02 10 Abstract 12 Traditional discrete logarithm-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 October 30, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Server Indication of support . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . 9 76 8.5. Timing attacks . . . . . . . . . . . . . . . . . . . . . 10 77 8.6. Replay attacks from non-negotiated DL 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. dldhe2432 . . . . . . . . . . . . . . . . . . . . . . . . 12 85 A.2. dldhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 13 86 A.3. dldhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 14 87 A.4. dldhe6144 . . . . . . . . . . . . . . . . . . . . . . . . 15 88 A.5. dldhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 16 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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 discrete- 136 logarithm-based Diffie-Hellman ephemeral key exchange mechanism in 137 TLS. TLS also supports elliptic-curve-based Diffie Hellman ephemeral 138 key exchanges, but this document does not discuss their use. 139 Mentions of DHE here refer strictly to discrete-log-based DHE, and 140 not to ECDHE. 142 2. Client Behavior 143 A TLS client that is capable of using strong discrete log 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_dl_dhe_groups" in the ClientHello, indicating a list of 149 known discrete log Diffie-Hellman groups, ordered from most preferred 150 to least preferred. 152 The "extension_data" field of this extension SHALL contain 153 "DiscreteLogDHEGroups" where: 155 enum { 156 dldhe2432(0), dldhe3072(1), dldhe4096(2), 157 dldhe6144(3), dldhe8192(4), (255) 158 } DiscreteLogDHEGroup; 160 struct { 161 DiscreteLogDHEGroup discrete_log_dhe_group_list<1..2^8-1>; 162 } DiscreteLogDHEGroups; 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 DiscreteLogDHEGroup 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_dl_dhe_groups" extension. The "extension_data" field of 201 this extension on the server side should be a single one-byte value 202 DiscreteLogDHEGroup. 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 dldhe2432 and dldhe4096, the server SHOULD select dldhe4096. 214 3.1. ServerDHParams changes 216 When the server sends the "negotiated_dl_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 discrete log 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 Discrete Log 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 dldhe2432 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 287 Some servers will support this extension, but for whatever reason 288 decide to not negotiate a ciphersuite with DHE key exchange at all. 289 Some possible reasons include: 291 The client indicated that a server-supported non-DHE ciphersuite 292 was preferred over all DHE ciphersuites, and the server honors 293 that preference. 295 The server prefers a client-supported non-DHE ciphersuite over all 296 DHE ciphersuites, and selects it unilaterally. 298 The server would have chosen a DHE ciphersuite, but none of the 299 client's offered groups are acceptable to the server, 301 Clients will not know that such a server supports the extension. 303 Should we offer a way for a server to indicate its support for this 304 extension to a compatible client in this case? 306 Should the server have a way to advertise that it supports this 307 extension even if the client does not offer it? 309 5.2. Normalizing Weak Groups 311 Is there any reason to include a weak group in the list of groups? 312 Most DHE-capable peers can already handle 1024-bit DHE, and therefore 313 1024-bit DHE does not need to be negotiated. Properly-chosen 314 2432-bit DH groups should be roughly equivalent to 112-bit security. 315 And future implementations should use sizes of at least 3072 bits 316 according to [ENISA]. 318 5.3. Arbitrary Groups 320 This spec currently doesn't indicate any support for groups other 321 than the named groups. Other DHE specifications have moved away from 322 staticly-named groups with the explicitly-stated rationale of 323 reducing the incentive for precomputation-driven attacks on any 324 specific group (e.g. section 1 of [RFC4419]). However, arbitrary 325 large groups are expensive to transmit over the network and it is 326 computationally infeasible for the client to verify their structure 327 during a key exchange. If we instead allow the server to propose 328 arbitrary groups, we could make it a MUST that the generated groups 329 use safe prime moduli, while still allowing clients to signal support 330 (and desire) for large groups. This leaves the client in the 331 position of relying on the server to choose a strong modulus, though. 333 Note that in at least one known attack against TLS 334 [SECURE-RESUMPTION], a malicious server uses a deliberately broken 335 discrete log DHE group to impersonate the client to a different 336 server. 338 6. Acknowledgements 340 Thanks to Fedor Brunner, Dave Fergemann, Sandy Harris, Watson Ladd, 341 Nikos Mavrogiannopolous, Niels Moeller, Kenny Paterson, and Tom 342 Ritter for their comments and suggestions on this draft. Any 343 mistakes here are not theirs. 345 7. IANA Considerations 347 This document defines a new TLS extension, "negotiated_dh_group", 348 assigned a value of XXX from the TLS ExtensionType registry defined 349 in section 12 of [RFC5246]. This value is used as the extension 350 number for the extensions in both the client hello message and the 351 server hello message. 353 Appendix A defines a TLS Discrete Log DHE Named Group Registry. Each 354 entry in this registry indicates the group itself, its derivation, 355 its expected strength (estimated roughly from guidelines in 356 [ECRYPTII]), and whether it is recommended for use in TLS key 357 exchange at the given security level. This registry may be updated 358 by the addition of new discrete log groups, and by reassessments of 359 the security level or utility to TLS of any already present group. 360 Updates are made by IETF Review [RFC5226], and should consider 361 Section 9.1. 363 8. Security Considerations 365 8.1. Negotiation resistance to active attacks 367 Because the contents of this extension is hashed in the finished 368 message, an active MITM that tries to filter or omit groups will 369 cause the handshake to fail, but possibly not before getting the peer 370 to do something they would not otherwise have done. 372 An attacker who impersonates the server can try to do any of the 373 following: 375 Pretend that a non-compatible server is actually capable of this 376 extension, and select a group from the client's list, causing the 377 client to select a group it is willing to negotiate. It is 378 unclear how this would be an effective attack. 380 Pretend that a compatible server is actually non-compatible by 381 negotiating a non-DHE ciphersuite. This is no different than MITM 382 ciphersuite filtering. 384 Pretend that a compatible server is actually non-compatible by 385 negotiating a DHE ciphersuite and no extension, with an explicit 386 (perhaps weak) group chosen by the server. [XXX what are the 387 worst consequences in this case? What might the client leak 388 before it notices that the handshake fails? XXX] 390 An attacker who impersonates the client can try to do the following: 392 Pretend that a compatible client is not compliant (e.g. by not 393 offering this extension). This could cause the server to 394 negotiate a weaker DHE group during the handshake, but it would 395 fail to complete during the final check of the Finished message. 397 Pretend that a non-compatible client is compatible. This could 398 cause the server to send what appears to be an extremely odd 399 ServerDHParams (see Section 3.1), and the check in the Finished 400 message would fail. It is not clear how this could be an attack. 402 Change the list of groups offered by the client (e.g. by removing 403 the stronger of the set of groups offered). This could cause the 404 server to negotiate a weaker group than desired, but again should 405 be caught by the check in the Finished message. 407 8.2. DHE only 409 Note that this extension specifically targets only discrete log-based 410 Diffie-Hellman ephemeral key exchange mechanisms. It does not cover 411 the non-ephemeral DH key exchange mechanisms, nor does it cover 412 elliptic curve-based DHE key exchange, which has its own list of 413 named groups. 415 8.3. Deprecating weak groups 417 Advances in hardware or in discrete log cryptanalysis may cause some 418 of the negotiated groups to not provide the desired security margins, 419 as indicated by the estimated work factor of an adversary to discover 420 the premaster secret (and therefore compromise the confidentiality 421 and integrity of the TLS session). 423 Revisions of this extension or updates should mark known-weak groups 424 as explicitly deprecated for use in TLS, and should update the 425 estimated work factor needed to break the group, if the cryptanalysis 426 has changed. Implementations that require strong confidentiality and 427 integrity guarantees should avoid using deprecated groups and should 428 be updated when the estimated security margins are updated. 430 8.4. Choice of groups 431 Other lists of named discrete log Diffie-Hellman groups 432 [STRONGSWAN-IKE] exist. This draft chooses to not reuse them for 433 several reasons: 435 Using the same groups in multiple protocols increases the value 436 for an attacker with the resources to crack any single group. 438 The IKE groups include weak groups like MODP768 which are 439 unacceptable for secure TLS traffic. 441 Mixing group parameters across multiple implementations leaves 442 open the possibility of some sort of cross-protocol attack. This 443 shouldn't be relevant for ephemeral scenarios, and even with non- 444 ephemeral keying, services shouldn't share keys; however, using 445 different groups avoids these failure modes entirely. 447 Other lists of named DL DHE groups are not collected in a single 448 IANA registry, or are mixed with non-DL DHE groups, which makes 449 them inconvenient for re-use in a TLS DHE key exchange context. 451 8.5. Timing attacks 453 Any implementation of discrete log Diffie-Hellman key exchange should 454 use constant-time modular-exponentiation implementations. This is 455 particularly true for those implementations that ever re-use DHE 456 secret keys (so-called "semi-static" ephemeral keying) or share DHE 457 secret keys across a multiple machines (e.g. in a load-balancer 458 situation). 460 8.6. Replay attacks from non-negotiated DL DHE 462 [SECURE-RESUMPTION] shows a malicious peer using a bad DL DHE group 463 to maneuver a client into selecting a pre-master secret of the peer's 464 choice, which can be replayed to another server using a non-DHE key 465 exchange, and can then be bootstrapped to replay client 466 authentication. 468 To prevent this attack (barring the fixes proposed in 469 [SESSION-HASH]), a client would need not only to implement this 470 draft, but also to reject non-negotiated DL DHE ciphersuites whose 471 group structure it cannot afford to verify. Such a client would need 472 to abort the initial handshake and reconnect to the server in 473 question without listing any DL DHE ciphersuites on the subsequent 474 connection. 476 This tradeoff may be too costly for most TLS clients today, but may 477 be a reasonable choice for clients performing client certificate 478 authentication, or who have other reason to be concerned about 479 server-controlled pre-master secrets. 481 9. Privacy Considerations 483 9.1. Client fingerprinting 485 This extension provides a few additional bits of information to 486 distinguish between classes of TLS clients (see e.g. 487 [PANOPTICLICK]). To minimize this sort of fingerprinting, clients 488 SHOULD support all named groups at or above their minimum security 489 threshhold. New named groups SHOULD NOT be added to the registry 490 without consideration of the cost of browser fingerprinting. 492 10. References 494 10.1. Normative References 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 10.2. Informative References 501 [ECRYPTII] 502 European Network of Excellence in Cryptology II, "ECRYPT 503 II Yearly Report on Algorithms and Keysizes (2011-2012)", 504 September 2012, 505 . 507 [ENISA] European Union Agency for Network and Information Security 508 Agency, "Algorithms, Key Sizes and Parameters Report, 509 version 1.0", October 2013, . 513 [PANOPTICLICK] 514 Electronic Frontier Foundation, "Panopticlick: How Unique 515 - and Trackable - Is Your Browser?", 2010, . 518 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 519 Diffie-Hellman groups for Internet Key Exchange (IKE)", 520 RFC 3526, May 2003. 522 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 523 Group Exchange for the Secure Shell (SSH) Transport Layer 524 Protocol", RFC 4419, March 2006. 526 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 527 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 528 May 2008. 530 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 531 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 533 [SECURE-RESUMPTION] 534 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 535 "Triple Handshakes Considered Harmful: Breaking and Fixing 536 Authentication over TLS", March 2014, . 539 [SESSION-HASH] 540 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 541 A., and M. Ray, "Triple Handshakes Considered Harmful: 542 Breaking and Fixing Authentication over TLS", March 2014, 543 . 546 [STRONGSWAN-IKE] 547 Brunner, T. and A. Steffen, "Diffie Hellman Groups in 548 IKEv2 Cipher Suites", October 2013, . 552 Appendix A. Named Group Registry 554 The primes in these discrete log groups are all safe primes, that is, 555 a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is 556 the base of the natural logarithm, and square brackets denote the 557 floor operation, the groups which initially populate this registry 558 are derived for a given bitlength b by finding the lowest positive 559 integer X that creates a safe prime p where: 561 p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1 563 New additions to this registry may use this same derivation (e.g. 564 with different bitlengths) or may choose their parameters in a 565 different way, but must be clear about how the parameters were 566 derived. 568 A.1. dldhe2432 569 The 2432-bit group has registry value 0, and is calcluated from the 570 following formula: 572 The modulus is: p = 2^2432 - 2^2368 + {[2^2302 * e] + 2111044} * 2^64 573 - 1 575 Its hexadecimal representation is: 577 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 578 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 579 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 580 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 581 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 582 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 583 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 584 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 585 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 586 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 587 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 588 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 589 AEFE1309 8533C8B3 FFFFFFFF FFFFFFFF 591 The generator is: g = 2 593 The group size is (p-1)/2 595 The estimated symmetric-equivalent strength of this group is 112 596 bits. 598 Peers using dldhe2432 that want to optimize their key exchange with a 599 short exponent (Section 4.2) should choose a secret key of at least 600 224 bits. 602 A.2. dldhe3072 604 The 3072-bit prime has registry value 1, and is calcluated from the 605 following formula: 607 p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 -1 609 Its hexadecimal representation is: 611 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 612 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 613 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 614 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 615 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 616 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 617 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 618 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 619 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 620 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 621 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 622 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 623 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 624 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 625 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 626 3C1B20EE 3FD59D7C 25E41D2B 66C62E37 FFFFFFFF FFFFFFFF 628 The generator is: g = 2 630 The group size is: (p-1)/2 632 The estimated symmetric-equivalent strength of this group is 125 633 bits. 635 Peers using dldhe3072 that want to optimize their key exchange with a 636 short exponent (Section 4.2) should choose a secret key of at least 637 250 bits. 639 A.3. dldhe4096 641 The 4096-bit group has registry value 2, and is calcluated from the 642 following formula: 644 The modulus is: p = 2^4096 - 2^4032 + {[2^3966 * e] + 5736041} * 2^64 645 - 1 647 Its hexadecimal representation is: 649 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 650 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 651 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 652 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 653 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 654 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 655 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 656 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 657 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 658 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 659 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 660 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 661 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 662 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 663 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 664 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 665 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 666 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 667 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 668 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 669 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E655F6A 670 FFFFFFFF FFFFFFFF 672 The base is: g = 2 674 The group size is: (p-1)/2 676 The estimated symmetric-equivalent strength of this group is 150 677 bits. 679 Peers using dldhe4096 that want to optimize their key exchange with a 680 short exponent (Section 4.2) should choose a secret key of at least 681 300 bits. 683 A.4. dldhe6144 685 The 6144-bit group has registry value 3, and is calcluated from the 686 following formula: 688 The modulus is: p = 2^6144 - 2^6080 + {[2^6014 * e] + 15705020} * 689 2^64 - 1 691 Its hexadecimal representation is: 693 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 694 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 695 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 696 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 697 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 698 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 699 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 700 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 701 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 702 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 703 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 704 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 705 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 706 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 707 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 708 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 709 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 710 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 711 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 712 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 713 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 714 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 715 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A 716 CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 717 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 718 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 719 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 720 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C 721 D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A 722 E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 723 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 724 A41D570D 7938DAD4 A40E329C D0E40E65 FFFFFFFF FFFFFFFF 726 The generator is: 2 728 The group size is: (p-1)/2 730 The estimated symmetric-equivalent strength of this group is 175 731 bits. 733 Peers using dldhe6144 that want to optimize their key exchange with a 734 short exponent (Section 4.2) should choose a secret key of at least 735 350 bits. 737 A.5. dldhe8192 739 The 8192-bit group has registry value 4, and is calcluated from the 740 following formula: 742 The modulus is: p = 2^8192 - 2^8128 + {[2^8062 * e] + 10965728} * 743 2^64 - 1 745 Its hexadecimal representation is: 747 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 748 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 749 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 750 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 751 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 752 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 753 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 754 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 755 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 756 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 757 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 758 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 759 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 760 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 761 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 762 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 763 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 764 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 765 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 766 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 767 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 768 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 769 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A 770 CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 771 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 772 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 773 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 774 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C 775 D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A 776 E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 777 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 778 A41D570D 7938DAD4 A40E329C CFF46AAA 36AD004C F600C838 779 1E425A31 D951AE64 FDB23FCE C9509D43 687FEB69 EDD1CC5E 780 0B8CC3BD F64B10EF 86B63142 A3AB8829 555B2F74 7C932665 781 CB2C0F1C C01BD702 29388839 D2AF05E4 54504AC7 8B758282 782 2846C0BA 35C35F5C 59160CC0 46FD8251 541FC68C 9C86B022 783 BB709987 6A460E74 51A8A931 09703FEE 1C217E6C 3826E52C 784 51AA691E 0E423CFC 99E9E316 50C1217B 624816CD AD9A95F9 785 D5B80194 88D9C0A0 A1FE3075 A577E231 83F81D4A 3F2FA457 786 1EFC8CE0 BA8A4FE8 B6855DFE 72B0A66E DED2FBAB FBE58A30 787 FAFABE1C 5D71A87E 2F741EF8 C1FE86FE A6BBFDE5 30677F0D 788 97D11D49 F7A8443D 0822E506 A9F4614E 011E2A94 838FF88C 789 D68C8BB7 C5C6424C FFFFFFFF FFFFFFFF 791 The base is: g = 2 793 The group size is: (p-1)/2 795 The estimated symmetric-equivalent strength of this group is 192 796 bits. 798 Peers using dldhe8192 that want to optimize their key exchange with a 799 short exponent (Section 4.2) should choose a secret key of at least 800 384 bits. 802 Author's Address 803 Daniel Kahn Gillmor 804 ACLU 805 125 Broad Street, 18th Floor 806 New York, NY 10004 807 USA 809 Email: dkg@fifthhorseman.net