added rfc on DH key exchange

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/protocol/rfc2631.txt b/doc/protocol/rfc2631.txt
new file mode 100644
index 0000000000..ef73821517
--- /dev/null
+++ b/doc/protocol/rfc2631.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                       E. Rescorla
+Request for Comments: 2631                                    RTFM Inc.
+Category: Standards Track                                     June 1999
+
+
+                  Diffie-Hellman Key Agreement Method
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   This document standardizes one particular Diffie-Hellman variant,
+   based on the ANSI X9.42 draft, developed by the ANSI X9F1 working
+   group. Diffie-Hellman is a key agreement algorithm used by two
+   parties to agree on a shared secret. An algorithm for converting the
+   shared secret into an arbitrary amount of keying material is
+   provided. The resulting keying material is used as a symmetric
+   encryption key.  The Diffie-Hellman variant described requires the
+   recipient to have a certificate, but the originator may have a static
+   key pair (with the public key placed in a certificate) or an
+   ephemeral key pair.
+
+Table of Contents
+
+   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . .   2
+   1.1. Requirements Terminology  . . . . . . . . . . . . . . . .   2
+   2. Overview Of Method  . . . . . . . . . . . . . . . . . . . .   2
+   2.1. Key Agreement . . . . . . . . . . . . . . . . . . . . . .   2
+   2.1.1. Generation of ZZ  . . . . . . . . . . . . . . . . . . .   3
+   2.1.2. Generation of Keying Material . . . . . . . . . . . . .   3
+   2.1.3. KEK Computation . . . . . . . . . . . . . . . . . . . .   4
+   2.1.4. Keylengths for common algorithms  . . . . . . . . . . .   5
+   2.1.5. Public Key Validation . . . . . . . . . . . . . . . . .   5
+   2.1.6. Example 1 . . . . . . . . . . . . . . . . . . . . . . .   5
+   2.1.7. Example 2 . . . . . . . . . . . . . . . . . . . . . . .   6
+   2.2. Key and Parameter Requirements  . . . . . . . . . . . . .   7
+   2.2.1. Group Parameter Generation  . . . . . . . . . . . . . .   7
+   2.2.1.1. Generation of p, q  . . . . . . . . . . . . . . . . .   8
+
+
+
+Rescorla                    Standards Track                     [Page 1]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+   2.2.1.2. Generation of g . . . . . . . . . . . . . . . . . . .   9
+   2.2.2. Group Parameter Validation  . . . . . . . . . . . . . .   9
+   2.3. Ephemeral-Static Mode . . . . . . . . . . . . . . . . . .  10
+   2.4. Static-Static Mode  . . . . . . . . . . . . . . . . . . .  10
+   2.4. Acknowledgements  . . . . . . . . . . . . . . . . . . . .  10
+   2.4. References  . . . . . . . . . . . . . . . . . . . . . . .  11
+   Security Considerations  . . . . . . . . . . . . . . . . . . .  12
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . .  12
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . .  13
+
+1.  Introduction
+
+   In [DH76] Diffie and Hellman describe a means for two parties to
+   agree upon a shared secret in such a way that the secret will be
+   unavailable to eavesdroppers. This secret may then be converted into
+   cryptographic keying material for other (symmetric) algorithms.  A
+   large number of minor variants of this process exist. This document
+   describes one such variant, based on the ANSI X9.42 specification.
+
+1.1.  Requirements Terminology
+
+   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
+   "MAY" that appear in this document are to be interpreted as described
+   in [RFC2119].
+
+2.  Overview Of Method
+
+   Diffie-Hellman key agreement requires that both the sender and
+   recipient of a message have key pairs. By combining one's private key
+   and the other party's public key, both parties can compute the same
+   shared secret number. This number can then be converted into
+   cryptographic keying material.  That keying material is typically
+   used as a key-encryption key (KEK) to encrypt (wrap) a content-
+   encryption key (CEK) which is in turn used to encrypt the message
+   data.
+
+2.1.  Key Agreement
+
+   The first stage of the key agreement process is to compute a shared
+   secret number, called ZZ.  When the same originator and recipient
+   public/private key pairs are used, the same ZZ value will result.
+   The ZZ value is then converted into a shared symmetric cryptographic
+   key. When the originator employs a static private/public key pair,
+   the introduction of a public random value ensures that the resulting
+   symmetric key will be different for each key agreement.
+
+
+
+
+
+
+Rescorla                    Standards Track                     [Page 2]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+2.1.1.  Generation of ZZ
+
+   X9.42 defines that the shared secret ZZ is generated as follows:
+
+     ZZ = g ^ (xb * xa) mod p
+
+   Note that the individual parties actually perform the computations:
+
+     ZZ = (yb ^ xa)  mod p  = (ya ^ xb)  mod p
+
+   where ^ denotes exponentiation
+
+         ya is party a's public key; ya = g ^ xa mod p
+         yb is party b's public key; yb = g ^ xb mod p
+         xa is party a's private key
+         xb is party b's private key
+         p is a large prime
+         q is a large prime
+         g = h^{(p-1)/q} mod p, where
+         h is any integer with 1 < h < p-1 such that h{(p-1)/q} mod p > 1
+           (g has order q mod p; i.e. g^q mod p = 1 if g!=1)
+         j a large integer such that p=qj + 1
+         (See Section 2.2 for criteria for keys and parameters)
+
+   In [CMS], the recipient's key is identified by the CMS
+   RecipientIdentifier, which points to the recipient's certificate.
+   The sender's public key is identified using the
+   OriginatorIdentifierOrKey field, either by reference to the sender's
+   certificate or by inline inclusion of a public key.
+
+2.1.2.  Generation of Keying Material
+
+   X9.42 provides an algorithm for generating an essentially arbitrary
+   amount of keying material from ZZ. Our algorithm is derived from that
+   algorithm by mandating some optional fields and omitting others.
+
+     KM = H ( ZZ || OtherInfo)
+
+   H is the message digest function SHA-1 [FIPS-180] ZZ is the shared
+   secret value computed in Section 2.1.1. Leading zeros MUST be
+   preserved, so that ZZ occupies as many octets as p. For instance, if
+   p is 1024 bits, ZZ should be 128 bytes long.  OtherInfo is the DER
+   encoding of the following structure:
+
+     OtherInfo ::= SEQUENCE {
+       keyInfo KeySpecificInfo,
+       partyAInfo [0] OCTET STRING OPTIONAL,
+       suppPubInfo [2] OCTET STRING
+
+
+
+Rescorla                    Standards Track                     [Page 3]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+     }
+
+     KeySpecificInfo ::= SEQUENCE {
+       algorithm OBJECT IDENTIFIER,
+       counter OCTET STRING SIZE (4..4) }
+
+   Note that these ASN.1 definitions use EXPLICIT tagging. (In ASN.1,
+   EXPLICIT tagging is implicit unless IMPLICIT is explicitly
+   specified.)
+
+   algorithm is the ASN.1 algorithm OID of the CEK wrapping algorithm
+     with which this KEK will be used. Note that this is NOT an
+     AlgorithmIdentifier, but simply the OBJECT IDENTIFIER. No
+     parameters are used.
+
+   counter is a 32 bit number, represented in network byte order. Its
+     initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01
+     (hex), and it is incremented by one every time the above key
+     generation function is run for a given KEK.
+
+   partyAInfo is a random string provided by the sender. In CMS, it is
+     provided as a parameter in the UserKeyingMaterial field (encoded as
+     an OCTET STRING). If provided, partyAInfo MUST contain 512 bits.
+
+   suppPubInfo is the length of the generated KEK, in bits, represented
+     as a 32 bit number in network byte order. E.g. for 3DES it would be
+     the byte sequence 00 00 00 C0.
+
+   To generate a KEK, one generates one or more KM blocks (incrementing
+   counter appropriately) until enough material has been generated.  The
+   KM blocks are concatenated left to right I.e. KM(counter=1) ||
+   KM(counter=2)...
+
+   Note that the only source of secret entropy in this computation is
+   ZZ.  Even if a string longer than ZZ is generated, the effective key
+   space of the KEK is limited by the size of ZZ, in addition to any
+   security level considerations imposed by the parameters p and q.
+   However, if partyAInfo is different for each message, a different KEK
+   will be generated for each message. Note that partyAInfo MUST be used
+   in Static-Static mode, but MAY appear in Ephemeral-Static mode.
+
+2.1.3.  KEK Computation
+
+   Each key encryption algorithm requires a specific size key (n). The
+   KEK is generated by mapping the left n-most bytes of KM onto the key.
+   For 3DES, which requires 192 bits of keying material, the algorithm
+   must be run twice, once with a counter value of 1 (to generate K1',
+   K2', and the first 32 bits of K3') and once with a counter value of 2
+
+
+
+Rescorla                    Standards Track                     [Page 4]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+   (to generate the last 32 bits of K3). K1',K2' and K3' are then parity
+   adjusted to generate the 3 DES keys K1,K2 and K3.  For RC2-128, which
+   requires 128 bits of keying material, the algorithm is run once, with
+   a counter value of 1, and the left-most 128 bits are directly
+   converted to an RC2 key. Similarly, for RC2-40, which requires 40
+   bits of keying material, the algorithm is run once, with a counter
+   value of 1, and the leftmost 40 bits are used as the key.
+
+2.1.4.  Keylengths for common algorithms
+
+   Some common key encryption algorithms have KEKs of the following
+   lengths.
+
+     3-key 3DES      192 bits
+     RC2-128        128 bits
+     RC2-40         40 bits
+
+   RC2 effective key lengths are equal to RC2 real key lengths.
+
+2.1.5.  Public Key Validation
+
+   The following algorithm MAY be used to validate a received public key
+   y.
+
+     1. Verify that y lies within the interval [2,p-1]. If it does not,
+        the key is invalid.
+     2. Compute y^q mod p. If the result == 1, the key is valid.
+        Otherwise the key is invalid.
+
+   The primary purpose of public key validation is to prevent a small
+   subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static
+   mode is used, this check may not be necessary. See also [P1363] for
+   more information on Public Key validation.
+
+   Note that this procedure may be subject to pending patents.
+
+2.1.6.  Example 1
+
+   ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
+                      0a 0b 0c 0d 0e 0f 10 11 12 13
+
+   The key wrap algorithm is 3DES-EDE wrap.
+
+   No partyAInfo is used.
+
+   Consequently, the input to the first invocation of SHA-1 is:
+
+   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
+
+
+
+Rescorla                    Standards Track                     [Page 5]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+   30 1d
+      30 13
+         06 0b 2a 86 48 86 f7 0d 01 09 10 03 06          ; 3DES wrap OID
+         04 04
+            00 00 00 01                                        ; Counter
+      a2 06
+         04 04
+         00 00 00 c0                                        ; key length
+
+   And the output is the 20 bytes:
+
+   a0 96 61 39 23 76 f7 04 4d 90 52 a3 97 88 32 46 b6 7f 5f 1e
+
+   The input to the second invocation of SHA-1 is:
+
+   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
+   30 1d
+      30 13
+         06 0b 2a 86 48 86 f7 0d 01 09 10 03 06          ; 3DES wrap OID
+         04 04
+            00 00 00 02                                        ; Counter
+      a2 06
+         04 04
+         00 00 00 c0                                        ; key length
+
+   And the output is the 20 bytes:
+
+   f6 3e b5 fb 5f 56 d9 b6 a8 34 03 91 c2 d3 45 34 93 2e 11 30
+
+   Consequently,
+   K1'=a0 96 61 39 23 76 f7 04
+   K2'=4d 90 52 a3 97 88 32 46
+   K3'=b6 7f 5f 1e f6 3e b5 fb
+
+   Note: These keys are not parity adjusted
+
+2.1.7.  Example 2
+
+   ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
+                      0a 0b 0c 0d 0e 0f 10 11 12 13
+
+   The key wrap algorithm is RC2-128 key wrap, so we need 128 bits (16
+   bytes) of keying material.
+
+   The partyAInfo used is the 64 bytes
+
+   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
+   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
+
+
+
+Rescorla                    Standards Track                     [Page 6]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
+   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
+
+   Consequently, the input to SHA-1 is:
+
+   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
+   30 61
+      30 13
+         06 0b 2a 86 48 86 f7 0d 01 09 10 03 07           ; RC2 wrap OID
+         04 04
+            00 00 00 01                                        ; Counter
+      a0 42
+         04 40
+            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo
+            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
+            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
+            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
+      a2 06
+         04 04
+            00 00 00 80                                     ; key length
+
+   And the output is the 20 bytes:
+
+   48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0 3e 7b 5d e9
+
+   Consequently,
+   K=48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0
+
+2.2.  Key and Parameter Requirements
+
+   X9.42 requires that the group parameters be of the form p=jq + 1
+   where q is a large prime of length m and j>=2. An algorithm for
+   generating primes of this form (derived from the algorithms in FIPS
+   PUB 186-1[FIPS-186] and [X942]can be found in appendix A.
+
+   X9.42 requires that the private key x be in the interval [2, (q -
+   2)].  x should be randomly generated in this interval. y is then
+   computed by calculating g^x mod p.  To comply with this memo, m MUST
+   be >=160 bits in length, (consequently, q MUST be at least 160 bits
+   long). When symmetric ciphers stronger than DES are to be used, a
+   larger m may be advisable. p must be a minimum of 512 bits long.
+
+2.2.1.  Group Parameter Generation
+
+   Agents SHOULD generate domain parameters (g,p,q) using the following
+   algorithm, derived from [FIPS-186] and [X942]. When this algorithm is
+   used, the correctness of the generation procedure can be verified by
+   a third party by the algorithm of 2.2.2.
+
+
+
+Rescorla                    Standards Track                     [Page 7]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+2.2.1.1.  Generation of p, q
+
+   This algorithm generates a p, q pair where q is of length m and p is
+   of length L.
+
+   1. Set m' = m/160 where / represents integer division with rounding
+      upwards. I.e. 200/160 = 2.
+
+   2. Set L'=  L/160
+
+   3. Set N'=  L/1024
+
+   4. Select an arbitrary bit string SEED such that the length of SEED
+      >= m
+
+   5. Set U = 0
+
+   6. For i = 0 to m' - 1
+
+        U = U + (SHA1[SEED + i] XOR SHA1[(SEED + m' + i)) * 2^(160 * i)
+
+   Note that for m=160, this reduces to the algorithm of [FIPS-186]
+
+        U = SHA1[SEED] XOR SHA1[(SEED+1) mod 2^160 ].
+
+   5. Form q from U by computing U mod (2^m) and setting the most
+      significant bit (the 2^(m-1) bit) and the least significant bit to
+      1. In terms of boolean operations, q = U OR 2^(m-1) OR 1. Note
+      that 2^(m-1) < q < 2^m
+
+   6. Use a robust primality algorithm to test whether q is prime.
+
+   7. If q is not prime then go to 4.
+
+   8. Let counter = 0
+
+   9. Set R = seed + 2*m' + (L' * counter)
+
+   10. Set V = 0
+
+   12. For i = 0 to L'-1 do
+
+       V = V + SHA1(R + i) * 2^(160 * i)
+
+   13. Set W = V mod 2^L
+
+   14. Set X = W OR 2^(L-1)
+
+
+
+
+Rescorla                    Standards Track                     [Page 8]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+   Note that 0 <= W < 2^(L-1) and hence X >= 2^(L-1)
+
+   15. Set p = X - (X mod (2*q)) + 1
+
+   6. If p > 2^(L-1) use a robust primality test to test whether p is
+      prime. Else go to 18.
+
+   17. If p is prime output p, q, seed, counter and stop.
+
+   18. Set counter = counter + 1
+
+   19. If counter < (4096 * N) then go to 8.
+
+   20. Output "failure"
+
+   Note: A robust primality test is one where the probability of a non-
+   prime number passing the test is at most 2^-80. [FIPS-186] provides a
+   suitable algorithm, as does [X942].
+
+2.2.1.2.  Generation of g
+
+   This section gives an algorithm (derived from [FIPS-186]) for
+   generating g.
+
+   1. Let j = (p - 1)/q.
+
+   2. Set h = any integer, where 1 < h < p - 1 and h differs
+      from any value previously tried.
+
+   3. Set g = h^j mod p
+
+   4. If g = 1 go to step 2
+
+2.2.2.  Group Parameter Validation
+
+   The ASN.1 for DH keys in [PKIX] includes elements j and validation-
+   Parms which MAY be used by recipients of a key to verify that the
+   group parameters were correctly generated. Two checks are possible:
+
+     1. Verify that p=qj + 1. This demonstrates that the parameters meet
+        the X9.42 parameter criteria.
+     2. Verify that when the p,q generation procedure of [FIPS-186]
+        Appendix 2 is followed with seed 'seed', that p is found when
+        'counter' = pgenCounter.
+
+     This demonstrates that the parameters were randomly chosen and
+     do not have a special form.
+
+
+
+
+Rescorla                    Standards Track                     [Page 9]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+   Whether agents provide validation information in their certificates
+   is a local matter between the agents and their CA.
+
+2.3.  Ephemeral-Static Mode
+
+   In Ephemeral-Static mode, the recipient has a static (and certified)
+   key pair, but the sender generates a new key pair for each message
+   and sends it using the originatorKey production. If the sender's key
+   is freshly generated for each message, the shared secret ZZ will be
+   similarly different for each message and partyAInfo MAY be omitted,
+   since it serves merely to decouple multiple KEKs generated by the
+   same set of pairwise keys. If, however, the same ephemeral sender key
+   is used for multiple messages (e.g. it is cached as a performance
+   optimization) then a separate partyAInfo MUST be used for each
+   message. All implementations of this standard MUST implement
+   Ephemeral-Static mode.
+
+   In order to resist small subgroup attacks, the recipient SHOULD
+   perform the check described in 2.1.5. If an opponent cannot determine
+   success or failure of a decryption operation by the recipient, the
+   recipient MAY choose to omit this check. See also [LL97] for a method
+   of generating keys which are not subject to small subgroup attack.
+
+2.4.  Static-Static Mode
+
+   In Static-Static mode, both the sender and the recipient have a
+   static (and certified) key pair. Since the sender's and recipient's
+   keys are therefore the same for each message, ZZ will be the same for
+   each message. Thus, partyAInfo MUST be used (and different for each
+   message) in order to ensure that different messages use different
+   KEKs. Implementations MAY implement Static-Static mode.
+
+   In order to prevent small subgroup attacks, both originator and
+   recipient SHOULD either perform the validation step described in
+   Section 2.1.5 or verify that the CA has properly verified the
+   validity of the key.  See also [LL97] for a method of generating keys
+   which are not subject to small subgroup attack.
+
+Acknowledgements
+
+   The Key Agreement method described in this document is based on work
+   done by the ANSI X9F1 working group. The author wishes to extend his
+   thanks for their assistance.
+
+   The author also wishes to thank Stephen Henson, Paul Hoffman, Russ
+   Housley, Burt Kaliski, Brian Korver, John Linn, Jim Schaad, Mark
+   Schertler, Peter Yee, and Robert Zuccherato for their expert advice
+   and review.
+
+
+
+Rescorla                    Standards Track                    [Page 10]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+References
+
+   [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 2630,
+               June 1999.
+
+   [FIPS-46-1] Federal Information Processing Standards Publication
+               (FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed
+               1988 January 22 (supersedes FIPS PUB 46, 1977 January
+               15).
+
+   [FIPS-81]   Federal Information Processing Standards Publication
+               (FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
+
+   [FIPS-180]  Federal Information Processing Standards Publication
+               (FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17.
+
+   [FIPS-186]  Federal Information Processing Standards Publication
+               (FIPS PUB) 186, "Digital Signature Standard", 1994 May
+               19.
+
+   [P1363]     "Standard Specifications for Public Key Cryptography",
+               IEEE P1363 working group draft, 1998, Annex D.
+
+   [PKIX]      Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
+               X.509 Public Key Infrastructure Certificate and CRL
+               Profile", RFC 2459, January 1999.
+
+   [LAW98]     L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
+               "An efficient protocol for authenticated key agreement",
+               Technical report CORR 98-05, University of Waterloo,
+               1998.
+
+   [LL97]      C.H. Lim and P.J. Lee, "A key recovery attack on discrete
+               log-based schemes using a prime order subgroup", B.S.
+               Kaliski, Jr., editor, Advances in Cryptology - Crypto
+               '97, Lecture Notes in Computer Science, vol. 1295, 1997,
+               Springer-Verlag, pp. 249-263.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [X942]      "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV
+               Algorithms", ANSI draft, 1998.
+
+
+
+
+
+
+
+
+Rescorla                    Standards Track                    [Page 11]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+Security Considerations
+
+   All the security in this system is provided by the secrecy of the
+   private keying material. If either sender or recipient private keys
+   are disclosed, all messages sent or received using that key are
+   compromised. Similarly, loss of the private key results in an
+   inability to read messages sent using that key.
+
+   Static Diffie-Hellman keys are vulnerable to a small subgroup attack
+   [LAW98]. In practice, this issue arises for both sides in Static-
+   Static mode and for the receiver during Ephemeral-Static mode.
+   Sections 2.3 and 2.4 describe appropriate practices to protect
+   against this attack. Alternatively, it is possible to generate keys
+   in such a fashion that they are resistant to this attack. See [LL97]
+
+   The security level provided by these methods depends on several
+   factors. It depends on the length of the symmetric key (typically, a
+   2^l security level if the length is l bits); the size of the prime q
+   (a 2^{m/2} security level); and the size of the prime p (where the
+   security level grows as a subexponential function of the size in
+   bits).  A good design principle is to have a balanced system, where
+   all three security levels are approximately the same. If many keys
+   are derived from a given pair of primes p and q, it may be prudent to
+   have higher levels for the primes. In any case, the overall security
+   is limited by the lowest of the three levels.
+
+Author's Address
+
+   Eric Rescorla
+   RTFM Inc.
+   30 Newell Road, #16
+   East Palo Alto, CA 94303
+
+   EMail: ekr@rtfm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                    Standards Track                    [Page 12]
+
+RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla                    Standards Track                    [Page 13]
+