One document matched: draft-gillmor-tls-negotiated-dl-dhe-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3526 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3526.xml">
<!ENTITY RFC4419 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4419.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-gillmor-tls-negotiated-dl-dhe-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Negotiated-DL-DHE-for-TLS">Negotiated Discrete Log Diffie-Hellman Ephemeral Parameters for TLS</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Daniel Kahn Gillmor" initials="D." surname="Gillmor">
<organization>ACLU</organization>
<address>
<postal>
<street>125 Broad Street, 18th Floor</street>
<city>New York</city>
<region>NY</region>
<code>10004</code>
<country>USA</country>
</postal>
<phone></phone>
<email>dkg@fifthhorseman.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="March" year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Diffie-Hellman, Discrete Logarithm, Transport Layer Security, TLS, Negotiation, Extensions</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Traditional discrete logarithm-based Diffie-Hellman (DH) key
exchange during the TLS handshake suffers from a number of
security, interoperability, and efficiency shortcomings. These
shortcomings arise from lack of clarity about which DH group
parameters TLS servers should offer and clients should accept.
This document offers a solution to these shortcomings for
compatible peers by establishing a registry of DH parameters
with known structure and a mechanism for peers to indicate
support for these groups.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Traditional <xref target="RFC5246">TLS</xref> offers a
Diffie-Hellman ephemeral (DHE) key exchange mode which provides
Perfect Forward Secrecy for the connection. The client offers a
ciphersuite in the ClientHello that includes DHE, and the server
offers the client group parameters g and p. If the client does
not consider the group strong enough (e.g. if p is too small, or
if p is not prime, or there are small subgroups), or if it is
unable to process it for other reasons, it has no recourse but
to terminate the connection.</t>
<t>Conversely, when a TLS server receives a suggestion for a DHE
ciphersuite from a client, it has no way of knowing what kinds
of DH groups the client is capable of handling, or what the
client's security requirements are for this key exchange
session. Some widely-distributed TLS clients are not capable of
DH groups where p > 1024. Other TLS clients may by policy wish
to use DHE only if the server can offer a stronger group (and
are willing to use a non-PFS key-exchange mechanism otherwise).
The server has no way of knowing which type of client is
connecting, but must select DHE parameters with insufficient
knowledge.</t>
<t>Additionally, the DH parameters chosen by the server may have
a known structure which renders them secure against small
subgroup attack, but a client receiving an arbitrary p has no
efficient way to verify that the structure of a new group is
reasonable for use.</t>
<t>This extension solves these problems with a registry of
groups of known reasonable structure, an extension for clients
to advertise support for them and servers to select them, and
guidance for compliant peers to take advantage of the additional
security, availability, and efficiency offered.</t>
<t>The use of this extension by one compliant peer when
interacting with a non-compliant peer should have no detrimental
effects.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</section>
</section>
<section anchor="client" title="Client Behavior">
<t>A TLS client that is capable of using strong discrete log
Diffie-Hellman groups can advertise its capabilities and its
preferences for stronger key exchange by using this
mechanism.</t>
<t>The client SHOULD send an extension of type
"negotiated_dl_dhe_groups" in the ClientHello, indicating an
list of known discrete log Diffie-Hellman groups, ordered from
most preferred to least preferred.</t>
<t>The "extension_data" field of this extension SHALL contain
"DiscreteLogDHEGroups" where:</t>
<figure>
<artwork><![CDATA[
enum {
dldhe2432(0), dldhe3072(1), dldhe4096(2),
dldhe6144(3), dldhe8192(4), (255)
} DiscreteLogDHEGroup;
struct {
DiscreteLogDHEGroup discrete_log_dhe_group_list<1..2^8-1>;
} DiscreteLogDHEGroups;
]]></artwork>
</figure>
<t>A client that offers this extension SHOULD include at least
one DHE-key-exchange ciphersuite in the Client Hello.</t>
<t>The known groups defined by the DiscreteLogDHEGroup registry
are listed in <xref target="named_group_registry"/>. These are
all safe primes, designed to be sparse, and with the high and
low 64 bits set to 1 for efficient Montgomery or Barrett reduction.
</t>
<t>A client who offers a group MUST be able and willing to
perform a DH key exchange using that group.</t>
</section>
<section anchor="server" title="Server Behavior">
<t>A TLS server MUST NOT send the NegotiatedDHParams extension
to a client that does not offer it first.
</t>
<t>A compatible TLS server that receives this extension from a
client SHOULD NOT select a DHE ciphersuite if it is unwilling to
use one of the DH groups named by the client. In this case, it
SHOULD select an acceptable non-DHE ciphersuite from the
client's offered list. If the extension is present, none of the
client's offered groups are acceptable by the server, and none
of the client's proposed non-DHE ciphersuites are acceptable to
the server, the server SHOULD end the connection with a fatal
TLS alert of type insufficient_security.
</t>
<t>A compatible TLS server that receives this extension from a
client and selects a DHE-key-exchange ciphersuite selects one of
the offered groups and indicates it to the client in the
ServerHello by sending a "negotiated_dl_dhe_groups" extension.
The "extension_data" field of this extension on the server side
should be a single one-byte value DiscreteLogDHEGroup.
</t>
<t>A TLS server MUST NOT select a named group that was not
offered by the client.
</t>
<t>When the server sends the "negotiated_dl_dhe_groups"
extension in the ServerHello, the ServerDHParams member of the
subsequent ServerKeyExchange message should indicate a one-byte
zero value (0) in place of dh_g and the identifier of the named
group in place of dh_p, represented as a one-byte value. dh_Ys
must be transmitted as normal.
</t>
<t>This re-purposing of dh_p and dh_g is unambiguous: there are
no groups with a generator of 0, and no implementation should
accept a modulus of size < 9 bits. This change serves two
purposes:
<list>
<t>The size of the handshake is is reduced (significantly, in
the case of a large prime modulus).</t>
<t>The signed struct should not be re-playable in a subsequent
key exchange that does not indicate named DH groups.</t>
</list>
</t>
</section>
<section anchor="optimizations" title="Optimizations">
<t>In a successfully negotiated discrete log DH group key
exchange, both peers know that the group in question uses a safe
prime as a modulus, and that the group in use is of size p-1 or
(p-1)/2. This allows at least two optimizations that can be
used to improve performance.
</t>
<section anchor="peercheck" title="Checking the Peer's Public Key">
<t>Peers should validate the each other's public key Y
(dh_Ys offered by the server or DH_Yc offered by the client) by
ensuring that 1 < Y < p-1. This simple check ensures that
the remote peer is properly behaved and isn't forcing the local
system into a small subgroup.</t>
<t>To reach the same assurance with an unknown group, the
client would need to verify the primality of the modulus,
learn its factors, and test Y against each of its factors.
</t>
</section>
<section anchor="short-exponents" title="Short Exponents">
<t>
Traditional Discrete Log Diffie-Hellman has each peer choose
their secret exponent from the range [2,p-2]. Using
exponentiation by squaring, this means each peer must do
roughly 2*log_2(p) multiplications, twice (once for the
generator and once for the peer's public key).
</t>
<t>
Peers concerned with performance may also prefer to choose
their secret exponent from a smaller range, doing fewer
multiplications, while retaining the same level of overall
security. Each named group indicates its approximate
security level, and provides a lower-bound on the range of
secret exponents that should preserve it. For example,
rather than doing 2*2*2048 multiplications for a dldhe2048
handshake, each peer can choose to do 2*2*224
multiplications by choosing their secret exponent in the
range [2,2^224] and still keep the approximate 112-bit
security level.
</t>
<t>
A similar short-exponent approach is used in SSH's
Diffie-Hellman key exchange (See section 6.2 of <xref
target="RFC4419"/>).
</t>
</section>
<section anchor="tableacceleration" title="Table Acceleration">
<t>
Peers wishing to further accelerate DHE key exchange can
also pre-compute a table of powers of the generator of a
known group. This is a memory vs. time tradeoff, and it
only accelerates the first exponentiation of the ephemeral
DH exchange (the exponentiation using the peer's public
exponent as a base still needs to be done as normal).
</t>
</section>
</section>
<section anchor="questions" title="Open Questions">
<t>[This section should be removed, and questions resolved,
before any formalization of this draft]
</t>
<section title="Server Indication of support">
<t>Some servers will support this extension, but for whatever
reason decide to not negotiate a ciphersuite with DHE key
exchange at all. Some possible reasons include:
<list>
<t>The client indicated that a server-supported non-DHE
ciphersuite was preferred over all DHE ciphersuites, and the
server honors that preference.</t>
<t>The server prefers a client-supported non-DHE ciphersuite
over all DHE ciphersuites, and selects it unilaterally.</t>
<t>The server would have chosen a DHE ciphersuite, but none
of the client's offered groups are acceptable to the
server,</t>
</list>
Clients will not know that such a server
supports the extension.</t>
<t>Should we offer a way for a server to indicate its support
for this extension to a compatible client in this case?</t>
<t>Should the server have a way to advertise that it supports
this extension even if the client does not offer it?</t>
</section>
<section title="Normalizing Weak Groups">
<t>Is there any reason to include a weak group in the list of
groups? Most DHE-capable peers can already handle 1024-bit
DHE, and therefore 1024-bit DHE does not need to be
negotiated. Properly-chosen 2432-bit DH groups should be
roughly equivalent to 112-bit security. And future
implementations should use sizes of at least 3072 bits
according to <xref target="ENISA"/>.
</t>
</section>
<section title="Arbitrary Groups">
<t>
This spec currently doesn't indicate any support for groups
other than the named groups. Other DHE specifications have
moved away from staticly-named groups with the
explicitly-stated rationale of reducing the incentive for
precomputation-driven attacks on any specific group
(e.g. section 1 of <xref target="RFC4419"/>). However,
arbitrary large groups are expensive to transmit over the
network and it is computationally infeasible for the client
to verify their structure during a key exchange. If we
instead allow the server to propose arbitrary groups, we
could make it a MUST that the generated groups use safe
prime moduli, while still allowing clients to signal support
(and desire) for large groups. This leaves the client in
the position of relying on the server to choose a strong
modulus, though.
</t>
<t>
Note that in at least one known attack against TLS <xref
target="SECURE-RESUMPTION"/>, a malicious server uses a
deliberately broken discrete log DHE group to impersonate
the client to a different server.
</t>
</section>
</section>
<!--
guidance to servers for which named group to choose (choose based on
trying to "balance" with other selected mechanisms, like server host
pubkey and cipher and MAC?)
guidance to clients for what to offer (offer based on acceptable
cryptographic levels?)
-->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Thanks to Tom Ritter and Nikos Mavrogiannopolous and Niels
Möller and Kenny Paterson for their comments and
suggestions on the idea for this draft. Any mistakes here are
not theirs.
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>
This document defines a new TLS extension,
"negotiated_dh_group", assigned a value of XXX from the TLS
ExtensionType registry defined in section 12 of <xref
target="RFC5246"/>. This value is used as the extension
number for the extensions in both the client hello message and
the server hello message.
</t>
<t>
This extension also defines a registry of TLS named Discrete
Log DH groups, derived initially from some of the <xref
target="RFC3526">IKE DH groups</xref>, indicating the advised
strength of each group and whether it is recommended for use
in TLS. These recommendations may be updated by future
revisions.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<section title="Negotiation resistance to active attacks">
<t>
Because the contents of this extension is hashed in the
finished message, an active MITM that tries to filter or
omit groups will cause the handshake to fail, but possibly
not before getting the peer to do something they would not
otherwise have done.
</t>
<t>
An attacker who impersonates the server can try to do the
following:
<list>
<t>
Pretend that a non-compatible server is actually capable
of this extension, and select a group from the client's
list, causing the client to select a group it is willing
to negotiate. It is unclear how this would be an
effective attack.
</t>
<t>
Pretend that a compatible server is actually
non-compatible by negotiating a non-DHE ciphersuite. This
is no different than MITM ciphersuite filtering.
</t>
<t>
Pretend that a compatible server is actually
non-compatible by negotiating a DHE ciphersuite and no
extension, with an explicit (perhaps weak) group chosen
by the server. [XXX what are the worst consequences in
this case? What might the client leak before it notices
that the handshake fails? XXX]
</t>
</list>
</t>
<t>
An attacker who impersonates the client can try to do the
following:
<list>
<t>
Pretend that a compatible client is not compliant (e.g. by
not offering this extension). This could cause the server
to negotiate a weaker DHE group during the handshake, but
it would fail to complete during the final check of the
Finished message.
</t>
<t>
Pretend that a non-compatible client is compatible. It is
not clear how this could be an attack.
</t>
<t>
Change the list of groups offered by the client (e.g. by
removing the stronger of the set of groups offered). This
could cause the server to negotiate a weaker group than
desired, but again should be caught by the check in the
Finished message.
</t>
</list>
</t>
</section>
<section title="DHE only">
<t>
Note that this extension specifically targets only discrete
log-based Diffie-Hellman ephemeral key exchange mechanisms.
It does not cover the non-ephemeral DH key exchange
mechanisms, nor does it cover elliptic curve-based DHE key
exchange, which has its own list of named groups.
</t>
</section>
<section title="Client fingerprinting">
<t>
This extension provides a few additional bits of information
to distinguish between classes of TLS clients (see e.g.
<xref target="PANOPTICLICK"/>). To minimize this sort of
fingerprinting, clients SHOULD support all named groups at
or above their minimum security threshhold. New named
groups SHOULD NOT be added to the registry without
consideration of the cost of browser fingerprinting.
</t>
</section>
<section title="Deprecating weak groups">
<t>
Advances in hardware or in discrete log cryptanalysis may
cause some of the negotiated groups to not provide the
desired security margins, as indicated by number of years to
protect the premaster secret (and therefore the
confidentiality and integrity of the TLS session) against a
powerful adversary.
</t>
<t>
Revisions of this extension or updates should mark
known-weak groups as explicitly deprecated, and
implementations that require strong confidentiality and
integrity guarantees should avoid using any deprecated
groups.
</t>
</section>
<section title="Choice of groups">
<t>
<xref target="STRONGSWAN-IKE">Other lists of named discrete
log Diffie-Hellman groups</xref> exist. This draft chooses
to not reuse them for several reasons:
<list>
<t>
Using the same groups in multiple protocols increases
the value for an attacker with the resources to crack
any single group.
</t>
<t>
The IKE groups include weak groups like MODP768 which
are unacceptable for secure TLS traffic.
</t>
<t>
The IKE groups do not have sparse moduli, which makes
modular exponentiation less efficient.
</t>
<t>
Mixing group parameters across multiple implementations
leaves open the possibility of some sort of
cross-protocol attack. This shouldn't be relevant for
ephemeral scenarios, and even with non-ephemeral keying,
services shouldn't reuse keys; however, using different
groups avoids these failure modes entirely.
</t>
<t>
The DL DHE groups are not collected in a single IANA
registry, or are mixed with non-DL DHE groups, which makes
them inconvenient for re-use in TLS.
</t>
</list>
</t>
</section>
<section title="Timing attacks">
<t>
Any implementation of discrete log Diffie-Hellman key
exchange should use constant-time modular-exponentiation
implementations. This is particularly true for those
implementations that ever re-use DHE parameters (so-called
"semi-static" ephemeral keying).
</t>
</section>
<section title="Replay attacks from non-negotiated DL DHE">
<t>
<xref target="SECURE-RESUMPTION" /> shows a malicious
peer using a bad DL DHE group to maneuver a client into
selecting a pre-master secret of the peer's choice, which
can be replayed to another server using a non-DHE key
exchange, and can then be bootstrapped to replay client
authentication.
</t>
<t>
To prevent this attack (barring the fixes proposed in <xref
target="SESSION-HASH"/>), a client would need not only to implement this
draft, but also to reject non-negotiated DL DHE ciphersuites
whose group structure it cannot afford to verify. Such a
client would need to abort the initial handshake and
reconnect to the server in question without listing any DL
DHE ciphersuites on the subsequent connection.
</t>
<t>
This tradeoff may be too costly for most TLS clients today,
but may be a reasonable choice for clients performing client
certificate authentication, or who have other reason to be
concerned about server-controlled pre-master secrets.
</t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
&RFC3526;
&RFC4419;
&RFC5246;
<reference anchor="ENISA"
target="http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report">
<front>
<title>Algorithms, Key Sizes and Parameters Report, version 1.0</title>
<author>
<organization>European Union Agency for Network and Information Security Agency</organization>
</author>
<date month="October" year="2013" />
</front>
</reference>
<reference anchor="STRONGSWAN-IKE"
target="https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites#Diffie-Hellman-Groups">
<front>
<title>Diffie Hellman Groups in IKEv2 Cipher Suites</title>
<author initials="T." surname="Brunner" fullname="Tobias Brunner">
<organization>Strongswan</organization>
</author>
<author initials="A." surname="Steffen" fullname="Andreas Steffen">
<organization>Strongswan</organization>
</author>
<date month="October" year="2013" />
</front>
</reference>
<reference anchor="SECURE-RESUMPTION"
target="https://secure-resumption.com/">
<front>
<title>Triple Handshakes Considered Harmful: Breaking and Fixing Authentication over TLS</title>
<author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud">
<organization>INRIA</organization>
</author>
<author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
<organization>INRIA</organization>
</author>
<author initials="A." surname="Pironti" fullname="Alfredo Pironti">
<organization>INRIA</organization>
</author>
<date month="March" year="2014" />
</front>
</reference>
<reference anchor="SESSION-HASH"
target="https://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt">
<front>
<title>Triple Handshakes Considered Harmful: Breaking and Fixing Authentication over TLS</title>
<author initials="K." surname="Bhargavan" fullname="Karthikeyan Bhargavan">
<organization>INRIA</organization>
</author>
<author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud">
<organization>INRIA</organization>
</author>
<author initials="A." surname="Pironti" fullname="Alfredo Pironti">
<organization>INRIA</organization>
</author>
<author initials="A." surname="Langley" fullname="Adam Langley">
<organization>Google</organization>
</author>
<author initials="M." surname="Ray" fullname="Marsh Ray">
<organization>Microsoft</organization>
</author>
<date month="March" year="2014" />
</front>
</reference>
<reference anchor="PANOPTICLICK"
target="https://panopticlick.eff.org/">
<front>
<title>Panopticlick: How Unique - and Trackable - Is Your Browser?</title>
<author>
<organization>Electronic Frontier Foundation</organization>
</author>
<date year="2010" />
</front>
</reference>
</references>
<section anchor="named_group_registry" title="Named Group Registry">
<section anchor="dldhe2432" title="dldhe2432">
<t>The 2432-bit group has registry value 0, and is calcluated
from the following formula:</t>
<t>The modulus is: p = 2^2432 - 2^2368 + 2332920 * 2^64 - 1</t>
<t>Its hexadecimal representation is:</t>
<figure>
<artwork><![CDATA[
FFFFFFFF FFFFFFFF 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 002398F7 FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The generator is: g = 2</t>
<t>The group size is (p-1)/2</t>
<t>Peers using dldhe2432 that want to optimize their key
exchange with a <xref target="short-exponents">short
exponent</xref> should choose a secret key of at least 224
bits.</t>
</section>
<section anchor="dldhe3072" title="dldhe3072">
<t>The 3072-bit prime has registry value 1, and is calcluated
from the following formula:</t>
<t>p = 2^3072 - 2^3008 + 425754 * 2^64 -1</t>
<t>Its hexadecimal representation is:</t>
<figure>
<artwork><![CDATA[
FFFFFFFF FFFFFFFF 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00067F19 FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The generator is: g = 2</t>
<t>The group size is: (p-1)/2</t>
<t>Peers using dldhe3072 that want to optimize their key
exchange with a <xref target="short-exponents">short
exponent</xref> should choose a secret key of at least 256
bits.</t>
</section>
<section anchor="dldhe4096" title="dldhe4096">
<t>The 4096-bit group has registry value 2, and is calcluated
from the following formula:</t>
<t>The modulus is: p = 2^4096 - 2^4032 + 341664 * 2^64 - 1</t>
<t>Its hexadecimal representation is:</t>
<figure>
<artwork><![CDATA[
FFFFFFFF FFFFFFFF 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 0005369F
FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The base is: g = 2</t>
<t>The group size is: (p-1)/2</t>
<t>Peers using dldhe4096 that want to optimize their key
exchange with a <xref target="short-exponents">short
exponent</xref> should choose a secret key of at least XXX
bits.</t>
</section>
<section anchor="dldhe6144" title="dldhe6144">
<t>The 6144-bit group has registry value 3, and is calcluated
from the following formula:</t>
<t>The modulus is: p = 2^6144 - 2^6080 + XXX * 2^64 - 1</t>
<t>Its hexadecimal representation is:</t>
<figure>
<artwork><![CDATA[
XXX ...still calculating... XXX
]]></artwork>
</figure>
<t>The generator is: 2</t>
<t>Peers using dldhe6144 that want to optimize their key
exchange with a <xref target="short-exponents">short
exponent</xref> should choose a secret key of at least XXX
bits.</t>
</section>
<section anchor="dldhe8192" title="dldhe8192">
<t>The 8192-bit group has registry value 4, and is calcluated
from the following formula:</t>
<t>The modulus is: p = 2^8192 - 2^8128 + XXX * 2^64 - 1</t>
<t>Its hexadecimal representation is:</t>
<figure>
<artwork><![CDATA[
XXX ...still calculating... XXX
]]></artwork>
</figure>
<t>The base is: g = 2</t>
<t>Peers using dldhe8192 that want to optimize their key
exchange with a <xref target="short-exponents">short
exponent</xref> should choose a secret key of at least XXX
bits.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 00:43:56 |