One document matched: draft-ietf-tls-negotiated-ff-dhe-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml2rfc.ietf.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://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3526 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3526.xml">
<!ENTITY RFC4419 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4419.xml">
<!ENTITY RFC5226 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5246 SYSTEM "http://xml2rfc.ietf.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://xml2rfc.ietf.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-ietf-tls-negotiated-ff-dhe-01" 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-FF-DHE-for-TLS">Negotiated Finite Field 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 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, Finite Field, 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 finite-field-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 DH parameters with insufficient
knowledge.</t>
<t>Additionally, the DH parameters chosen by the server may have
a known structure which renders them secure against a 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 title="Vocabulary">
<t>
The term "DHE" is used in this document to refer to the
finite-field-based Diffie-Hellman ephemeral key
exchange mechanism in TLS. TLS also supports
elliptic-curve-based Diffie-Hellman (ECDHE) ephemeral key exchanges,
but this document does not discuss their use. Mentions of
DHE here refer strictly to finite-field-based DHE, and not
to ECDHE.
</t>
</section>
</section>
<section anchor="client" title="Client Behavior">
<t>A TLS client that is capable of using strong finite field
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_ff_dhe_groups" in the ClientHello, indicating a
list of known finite field Diffie-Hellman groups, ordered from
most preferred to least preferred.</t>
<t>The "extension_data" field of this extension SHALL contain
"FiniteFieldDHEGroups" where:</t>
<figure>
<artwork><![CDATA[
enum {
ffdhe2432(0), ffdhe3072(1), ffdhe4096(2),
ffdhe6144(3), ffdhe8192(4), (255)
} FiniteFieldDHEGroup;
struct {
FiniteFieldDHEGroup finite_field_dhe_group_list<1..2^8-1>;
} FiniteFieldDHEGroups;
]]></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 FiniteFieldDHEGroup registry
are listed in <xref target="named_group_registry"/>. These are
all safe primes derived from the base of the natural logarithm
("e"), with the high and low 64 bits set to 1 for efficient
Montgomery or Barrett reduction.
</t>
<t>
The use of the base of the natural logarithm here is as a
"nothing-up-my-sleeve" number. The goal is to guarantee that
the bits in the middle of the modulus are
effectively random, while avoiding any suspicion that the
primes have secretly been selected to be weak according to
some secret criteria. <xref target="RFC3526"/> used pi for
this value. See <xref target="choice-of-groups"/> for reasons
that this draft does not reuse pi.
</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_ff_dhe_groups" extension.
The "extension_data" field of this extension on the server side
should be a single one-byte value FiniteFieldDHEGroup.
</t>
<t>A TLS server MUST NOT select a named group that was not
offered by the client.
</t>
<t>
If a non-anonymous DHE ciphersuite is chosen, and the TLS
client has used this extension to offer a DHE group of
comparable or greater strength than the server's public key,
the server SHOULD select a DHE group at least as strong as the
server's public key. For example, if the server has a
3072-bit RSA key, and the client offers only ffdhe2432 and
ffdhe4096, the server SHOULD select ffdhe4096.
</t>
<section anchor="ServerDHParams" title="ServerDHParams changes">
<t>
When the server sends the "negotiated_ff_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 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>
<section anchor="optimizations" title="Optimizations">
<t>In a successfully negotiated finite field 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 three 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 the factors of p-1, and test both the generator g and Y
against each factor to avoid small subgroup attacks.
</t>
</section>
<section anchor="short-exponents" title="Short Exponents">
<t>
Traditional Finite Field 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*2432 multiplications for a ffdhe2432
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 suggested 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 several known attacks against TLS and SSL <xref
target="SECURE-RESUMPTION"/> <xref target="CROSS-PROTOCOL"/>
<xref target="SSL3-ANALYSIS"/>, a malicious server uses a
deliberately broken finite field 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 Fedor Brunner, Dave Fergemann, Sandy Harris, Watson
Ladd, Nikos Mavrogiannopolous, Niels Möller, Kenny
Paterson, and Tom Ritter for their comments and suggestions on
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>
<xref target="named_group_registry" /> defines a TLS Finite
Field DHE Named Group Registry. Each entry in this registry
indicates the group itself, its derivation, its expected
strength (estimated roughly from guidelines in <xref
target="ECRYPTII"/>), and whether it is recommended for use in
TLS key exchange at the given security level. This registry
may be updated by the addition of new finite field groups, and
by reassessments of the security level or utility to TLS of
any already present group. Updates are made by <xref
target="RFC5226">IETF Review</xref>, and should consider <xref
target="Client-Fingerprinting"/>.
</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 any of
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.
This could cause the server to send what appears to be
an extremely odd ServerDHParams (see <xref target="ServerDHParams"/>),
and the check in the Finished message would fail. 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 finite
field-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="Deprecating weak groups">
<t>
Advances in hardware or in finite field cryptanalysis may
cause some of the negotiated groups to not provide the
desired security margins, as indicated by the estimated work
factor of an adversary to discover the premaster secret (and
therefore compromise the confidentiality and integrity of
the TLS session).
</t>
<t>
Revisions of this extension or updates should mark
known-weak groups as explicitly deprecated for use in TLS,
and should update the estimated work factor needed to break
the group, if the cryptanalysis has changed.
Implementations that require strong confidentiality and
integrity guarantees should avoid using deprecated groups
and should be updated when the estimated security margins
are updated.
</t>
</section>
<section anchor="choice-of-groups" title="Choice of groups">
<t>
<xref target="STRONGSWAN-IKE">Other lists of named finite
field 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>
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 share keys; however, using different
groups avoids these failure modes entirely.
</t>
<t>
Other lists of named FF DHE groups are not collected in
a single IANA registry, or are mixed with non-FF DHE
groups, which makes them inconvenient for re-use in a
TLS DHE key exchange context.
</t>
</list>
</t>
</section>
<section title="Timing attacks">
<t>
Any implementation of finite field Diffie-Hellman key
exchange should use constant-time modular-exponentiation
implementations. This is particularly true for those
implementations that ever re-use DHE secret keys (so-called
"semi-static" ephemeral keying) or share DHE secret keys
across a multiple machines (e.g. in a load-balancer
situation).
</t>
</section>
<section title="Replay attacks from non-negotiated FF DHE">
<t>
<xref target="SECURE-RESUMPTION" /> shows a malicious
peer using a bad FF 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 FF 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 FF
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>
<section anchor="Privacy" title="Privacy Considerations">
<section anchor="Client-Fingerprinting" 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>
</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://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
&RFC3526;
&RFC4419;
&RFC5226;
&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="ECRYPTII"
target="http://www.ecrypt.eu.org/documents/D.SPA.20.pdf">
<front>
<title>ECRYPT II Yearly Report on Algorithms and Keysizes (2011-2012)</title>
<author>
<organization>European Network of Excellence in Cryptology II</organization>
</author>
<date month="September" year="2012" />
</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="CROSS-PROTOCOL"
target="http://www.cosic.esat.kuleuven.be/publications/article-2216.pdf">
<front>
<title>A Cross-Protocol Attack on the TLS Protocol</title>
<author initials="N." surname="Mavrogiannopolous" fullname="Nikos Mavrogiannopoulos">
<organization>KU Lueven</organization>
</author>
<author initials="F." surname="Vercauteren" fullname="Frederik Vercauteren">
<organization>KU Lueven</organization>
</author>
<author initials="V." surname="Velichkov" fullname="Vesselin Velichkov">
<organization>University of Luxembourg</organization>
</author>
<author initials="B." surname="Preneel" fullname="Bart Preneel">
<organization>KU Lueven</organization>
</author>
<date month="October" year="2012" />
</front>
</reference>
<reference anchor="SSL3-ANALYSIS"
target="https://www.schneier.com/paper-ssl.pdf">
<front>
<title>Analysis of the SSL 3.0 protocol</title>
<author initials="B." surname="Schneier" fullname="Bruce Schneier">
<organization>Counterpane Systems</organization>
</author>
<author initials="D." surname="Wagner" fullname="David Wagner">
<organization>University of California, Berkeley</organization>
</author>
<date year="1996" />
</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">
<t>
The primes in these finite field groups are all safe primes,
that is, a prime p is a safe prime when q = (p-1)/2 is also
prime. Where e is the base of the natural logarithm, and
square brackets denote the floor operation, the groups which
initially populate this registry are derived for a given
bitlength b by finding the lowest positive integer X that
creates a safe prime p where:
</t>
<figure>
<artwork><![CDATA[
p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1
]]></artwork>
</figure>
<t>
New additions to this registry may use this same derivation
(e.g. with different bitlengths) or may choose their
parameters in a different way, but must be clear about how the
parameters were derived.
</t>
<section anchor="ffdhe2432" title="ffdhe2432">
<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 + {[2^2302 * e] + 2111044} * 2^64 - 1</t>
<t>The hexadecimal representation of p is:</t>
<figure>
<artwork><![CDATA[
FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1
D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9
7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561
2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935
984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735
30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB
B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19
0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61
9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73
3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA
886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238
61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C
AEFE1309 8533C8B3 FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The generator is: g = 2</t>
<t>The group size is: q = (p-1)/2</t>
<t>The hexadecimal representation of q is:</t>
<figure>
<artwork><![CDATA[
7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78
EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C
BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0
9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A
CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A
98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD
DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C
8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0
C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9
9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD
4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C
30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E
577F0984 C299E459 FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The estimated symmetric-equivalent strength of this group is 112 bits.</t>
<t>Peers using ffdhe2432 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="ffdhe3072" title="ffdhe3072">
<t>The 3072-bit prime has registry value 1, and is calcluated
from the following formula:</t>
<t>p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 -1</t>
<t>The hexadecimal representation of p is:</t>
<figure>
<artwork><![CDATA[
FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1
D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9
7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561
2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935
984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735
30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB
B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19
0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61
9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73
3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA
886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238
61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C
AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3
64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D
ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF
3C1B20EE 3FD59D7C 25E41D2B 66C62E37 FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The generator is: g = 2</t>
<t>The group size is: q = (p-1)/2</t>
<t>The hexadecimal representation of q is:</t>
<figure>
<artwork><![CDATA[
7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78
EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C
BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0
9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A
CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A
98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD
DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C
8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0
C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9
9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD
4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C
30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E
577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9
B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06
D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7
9E0D9077 1FEACEBE 12F20E95 B363171B FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The estimated symmetric-equivalent strength of this group is 125 bits.</t>
<t>Peers using ffdhe3072 that want to optimize their key
exchange with a <xref target="short-exponents">short
exponent</xref> should choose a secret key of at least 250
bits.</t>
</section>
<section anchor="ffdhe4096" title="ffdhe4096">
<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 + {[2^3966 * e] + 5736041} * 2^64 - 1</t>
<t>The hexadecimal representation of p is:</t>
<figure>
<artwork><![CDATA[
FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1
D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9
7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561
2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935
984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735
30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB
B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19
0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61
9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73
3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA
886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238
61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C
AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3
64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D
ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF
3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB
7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004
87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832
A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A
1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF
8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E655F6A
FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The generator is: g = 2</t>
<t>The group size is: q = (p-1)/2</t>
<t>The hexadecimal representation of q is:</t>
<figure>
<artwork><![CDATA[
7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78
EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C
BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0
9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A
CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A
98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD
DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C
8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0
C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9
9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD
4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C
30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E
577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9
B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06
D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7
9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D
BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002
43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419
5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD
0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7
C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F32AFB5
7FFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The estimated symmetric-equivalent strength of this group
is 150 bits.</t>
<t>Peers using ffdhe4096 that want to optimize their key
exchange with a <xref target="short-exponents">short
exponent</xref> should choose a secret key of at least 300
bits.</t>
</section>
<section anchor="ffdhe6144" title="ffdhe6144">
<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 + {[2^6014 * e] + 15705020} * 2^64 - 1</t>
<t>The hexadecimal representation of p is:</t>
<figure>
<artwork><![CDATA[
FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1
D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9
7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561
2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935
984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735
30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB
B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19
0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61
9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73
3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA
886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238
61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C
AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3
64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D
ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF
3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB
7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004
87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832
A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A
1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF
8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902
0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6
3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A
CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477
A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3
0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4
763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6
B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C
D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A
E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04
5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1
A41D570D 7938DAD4 A40E329C D0E40E65 FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The generator is: g = 2</t>
<t>The group size is: q = (p-1)/2</t>
<t>The hexadecimal representation of q is:</t>
<figure>
<artwork><![CDATA[
7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78
EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C
BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0
9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A
CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A
98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD
DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C
8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0
C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9
9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD
4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C
30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E
577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9
B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06
D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7
9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D
BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002
43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419
5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD
0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7
C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81
05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53
1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D
66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B
D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1
855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA
3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB
59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6
6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5
724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582
2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0
D20EAB86 BC9C6D6A 5207194E 68720732 FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The estimated symmetric-equivalent strength of this group
is 175 bits.</t>
<t>Peers using ffdhe6144 that want to optimize their key
exchange with a <xref target="short-exponents">short
exponent</xref> should choose a secret key of at least 350
bits.</t>
</section>
<section anchor="ffdhe8192" title="ffdhe8192">
<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 + {[2^8062 * e] + 10965728} * 2^64 - 1</t>
<t>The hexadecimal representation of p is:</t>
<figure>
<artwork><![CDATA[
FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1
D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9
7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561
2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935
984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735
30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB
B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19
0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61
9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73
3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA
886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238
61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C
AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3
64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D
ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF
3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB
7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004
87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832
A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A
1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF
8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902
0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6
3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A
CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477
A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3
0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4
763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6
B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C
D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A
E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04
5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1
A41D570D 7938DAD4 A40E329C CFF46AAA 36AD004C F600C838
1E425A31 D951AE64 FDB23FCE C9509D43 687FEB69 EDD1CC5E
0B8CC3BD F64B10EF 86B63142 A3AB8829 555B2F74 7C932665
CB2C0F1C C01BD702 29388839 D2AF05E4 54504AC7 8B758282
2846C0BA 35C35F5C 59160CC0 46FD8251 541FC68C 9C86B022
BB709987 6A460E74 51A8A931 09703FEE 1C217E6C 3826E52C
51AA691E 0E423CFC 99E9E316 50C1217B 624816CD AD9A95F9
D5B80194 88D9C0A0 A1FE3075 A577E231 83F81D4A 3F2FA457
1EFC8CE0 BA8A4FE8 B6855DFE 72B0A66E DED2FBAB FBE58A30
FAFABE1C 5D71A87E 2F741EF8 C1FE86FE A6BBFDE5 30677F0D
97D11D49 F7A8443D 0822E506 A9F4614E 011E2A94 838FF88C
D68C8BB7 C5C6424C FFFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The generator is: g = 2</t>
<t>The group size is: q = (p-1)/2</t>
<t>The hexadecimal representation of q is:</t>
<figure>
<artwork><![CDATA[
7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78
EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C
BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0
9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A
CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A
98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD
DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C
8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0
C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9
9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD
4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C
30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E
577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9
B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06
D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7
9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D
BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002
43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419
5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD
0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7
C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81
05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53
1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D
66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B
D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1
855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA
3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB
59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6
6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5
724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582
2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0
D20EAB86 BC9C6D6A 5207194E 67FA3555 1B568026 7B00641C
0F212D18 ECA8D732 7ED91FE7 64A84EA1 B43FF5B4 F6E8E62F
05C661DE FB258877 C35B18A1 51D5C414 AAAD97BA 3E499332
E596078E 600DEB81 149C441C E95782F2 2A282563 C5BAC141
1423605D 1AE1AFAE 2C8B0660 237EC128 AA0FE346 4E435811
5DB84CC3 B523073A 28D45498 84B81FF7 0E10BF36 1C137296
28D5348F 07211E7E 4CF4F18B 286090BD B1240B66 D6CD4AFC
EADC00CA 446CE050 50FF183A D2BBF118 C1FC0EA5 1F97D22B
8F7E4670 5D4527F4 5B42AEFF 39585337 6F697DD5 FDF2C518
7D7D5F0E 2EB8D43F 17BA0F7C 60FF437F 535DFEF2 9833BF86
CBE88EA4 FBD4221E 84117283 54FA30A7 008F154A 41C7FC46
6B4645DB E2E32126 7FFFFFFF FFFFFFFF
]]></artwork>
</figure>
<t>The estimated symmetric-equivalent strength of this group
is 192 bits.</t>
<t>Peers using ffdhe8192 that want to optimize their key
exchange with a <xref target="short-exponents">short
exponent</xref> should choose a secret key of at least 384
bits.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:59:40 |