draft-ietf-smime-x942-05.txt | draft-ietf-smime-x942-06.txt | |||
---|---|---|---|---|

E. Rescorla | E. Rescorla | |||

INTERNET-DRAFT RTFM Inc. | INTERNET-DRAFT RTFM Inc. | |||

<draft-ietf-smime-x942-05.txt> January 1999 (Expires July 1999) | <draft-ietf-smime-x942-06.txt> March 1999 (Expires September 1999) | |||

Diffie-Hellman Key Agreement Method | Diffie-Hellman Key Agreement Method | |||

Status of this Memo | Status of this Memo | |||

This document is an Internet-Draft. Internet-Drafts are working | This document is an Internet-Draft and is in full conformance with | |||

all provisions of Section 10 of RFC2026. Internet-Drafts are working | ||||

documents of the Internet Engineering Task Force (IETF), its areas, | documents of the Internet Engineering Task Force (IETF), its areas, | |||

and its working groups. Note that other groups may also distribute | and its working groups. Note that other groups may also distribute | |||

working documents as Internet-Drafts. | working documents as Internet-Drafts. | |||

Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||

and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||

time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||

material or to cite them other than as ``work in progress.'' | material or to cite them other than as ``work in progress.'' | |||

To learn the current status of any Internet-Draft, please check the | To learn the current status of any Internet-Draft, please check the | |||

skipping to change at line 104 | skipping to change at line 105 | |||

ya is party a's public key; ya = g ^ xa mod p | ya is party a's public key; ya = g ^ xa mod p | |||

yb is party b's public key; yb = g ^ xb mod p | yb is party b's public key; yb = g ^ xb mod p | |||

xa is party a's private key | xa is party a's private key | |||

Rescorla [Page 2]Internet-Draft Diffie-Hellman Key Agreement Method | Rescorla [Page 2]Internet-Draft Diffie-Hellman Key Agreement Method | |||

xb is party b's private key | xb is party b's private key | |||

p is a large prime | p is a large prime | |||

q is a large prime | q is a large prime | |||

g = h^{(p-1)/q} mod p, where | 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 | 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) | (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 | j a large integer such that p=qj + 1 | |||

(See Section 2.2 for criteria for keys and parameters) | (See Section 2.2 for criteria for keys and parameters) | |||

In [CMS], the recipient's key is identified by the CMS RecipientIden- | In [CMS], the recipient's key is identified by the CMS RecipientIden- | |||

tifier, which points to the recipient's certificate. The sender's | tifier, which points to the recipient's certificate. The sender's | |||

key is identified using the OriginatorIdentifierOrKey field, either | key is identified using the OriginatorIdentifierOrKey field, either | |||

by reference to the sender's certificate or by inline inclusion of a | by reference to the sender's certificate or by inline inclusion of a | |||

key. | key. | |||

skipping to change at line 139 | skipping to change at line 140 | |||

OtherInfo ::= SEQUENCE { | OtherInfo ::= SEQUENCE { | |||

keyInfo KeySpecificInfo, | keyInfo KeySpecificInfo, | |||

partyAInfo [0] OCTET STRING OPTIONAL, | partyAInfo [0] OCTET STRING OPTIONAL, | |||

suppPubInfo [2] OCTET STRING | suppPubInfo [2] OCTET STRING | |||

} | } | |||

KeySpecificInfo ::= SEQUENCE { | KeySpecificInfo ::= SEQUENCE { | |||

algorithm OBJECT IDENTIFIER, | algorithm OBJECT IDENTIFIER, | |||

counter OCTET STRING SIZE (4..4) } | counter OCTET STRING SIZE (4..4) } | |||

algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which | algorithm is the ASN.1 algorithm OID of the MEK wrapping algorithm with which | |||

this KEK will be used. Note that this is NOT an AlgorithmIdentifier, | this KEK will be used. Note that this is NOT an AlgorithmIdentifier, | |||

but simply the OBJECT IDENTIFIER. No parameters are used. | but simply the OBJECT IDENTIFIER. No parameters are used. | |||

counter is a 32 bit number, represented in network byte order. Its | 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 | 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 | (hex), and it is incremented by one every time the above key generation | |||

function is run for a given KEK. | function is run for a given KEK. | |||

partyAInfo is a random string provided by the sender. In CMS, it is provided as | 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 | a parameter in the UserKeyingMaterial field (encoded as an OCTET STRING). If | |||

Rescorla [Page 3]Internet-Draft Diffie-Hellman Key Agreement Method | Rescorla [Page 3]Internet-Draft Diffie-Hellman Key Agreement Method | |||

skipping to change at line 166 | skipping to change at line 167 | |||

Note that these ASN.1 definitions use EXPLICIT tagging. (In ASN.1, | Note that these ASN.1 definitions use EXPLICIT tagging. (In ASN.1, | |||

EXPLICIT tagging is implicit unless IMPLICIT is explicitly speci- | EXPLICIT tagging is implicit unless IMPLICIT is explicitly speci- | |||

fied.) | fied.) | |||

To generate a KEK, one generates one or more KM blocks (incrementing | To generate a KEK, one generates one or more KM blocks (incrementing | |||

counter appropriately) until enough material has been generated. The | counter appropriately) until enough material has been generated. The | |||

KM blocks are concatenated left to right in the obvious order. I.e. | KM blocks are concatenated left to right in the obvious order. I.e. | |||

KM(counter=1) || KM(counter=2)... | KM(counter=1) || KM(counter=2)... | |||

Note that the only source of secret entropy in this computation is | Note that the only source of secret entropy in this computation is | |||

ZZ, so the security of this data is limited to the size of p and q, | ZZ. Even if a string longer than ZZ is generated, the effective key | |||

even if a string longer than ZZ is generated. However, if partyAInfo | space of the KEK is limited by the size of ZZ, in addition to any | |||

is different for each message, a different KEK will be generated for | security level considerations imposed by the parameters p and | |||

each message. Note that partyAInfo MUST be used in Static-Static | q.However, if partyAInfo is different for each message, a different | |||

mode, but MAY appear in Ephemeral-Static mode. | 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 | 2.1.3. KEK Computation | |||

Each key encryption algorithm requires a specific size key (n). The | 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. | 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 | 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', | 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 | K2', and the first 32 bits of K3') and once with a counter value of 2 | |||

(to generate the last 32 bits of K3). K1',K2' and K3' are then parity | (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, which | 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 | 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 con- | a counter value of 1, and the left-most 128 bits are directly con- | |||

verted to an RC2 key. | verted 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 | 2.1.4. Keylengths for common algorithms | |||

Some common key encryption algorithms have KEKs of the following | Some common key encryption algorithms have KEKs of the following | |||

lengths. | lengths. | |||

3DES-EDE-ECB 192 bits | 3DES-EDE-ECB 192 bits | |||

RC2 (all) 128 bits | RC2-128 128 bits | |||

RC2-40 40 bits | ||||

RC2 effective key lengths are equal to RC2 real key lengths. | ||||

Rescorla [Page 4]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

2.1.5. Public Key Validation | 2.1.5. Public Key Validation | |||

The following algorithm MAY be used to validate a received public key | The following algorithm MAY be used to validate a received public key | |||

y. | y. | |||

Rescorla [Page 4]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

1. Verify that y lies within the interval [2,p-1]. If it does not, | 1. Verify that y lies within the interval [2,p-1]. If it does not, | |||

the key is invalid. | the key is invalid. | |||

2. Compute y^q mod p. If the result == 1, the key is valid. | 2. Compute y^q mod p. If the result == 1, the key is valid. | |||

Otherwise the key is invalid. | Otherwise the key is invalid. | |||

The primary purpose of public key validation is to prevent a small | The primary purpose of public key validation is to prevent a small | |||

subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static | 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 | mode is used, this check may not be necessary. See also [P1363] for | |||

more information on Public Key validation. | more information on Public Key validation. | |||

Note that this procedure may be subject to pending patents. | Note that this procedure may be subject to pending patents. | |||

2.1.6. Example 1 | 2.1.6. Example 1 | |||

ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 | 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 | 0a 0b 0c 0d 0e 0f 10 11 12 13 | |||

The key encryption algorithm is 3DES-EDE. | The key wrap algorithm is 3DES-EDE wrap. | |||

No partyAInfo is used | No partyAInfo is used | |||

Consequently, the input to the first invocation of SHA-1 is: | 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 | 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ | |||

30 1a | 30 1d | |||

30 10 | 30 13 | |||

06 08 2a 86 48 86 f7 0d 03 07 ; 3DES OID | 06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 ; 3DES wrap OID | |||

04 04 | 04 04 | |||

00 00 00 01 ; Counter | 00 00 00 01 ; Counter | |||

a2 06 | a2 06 | |||

04 04 | 04 04 | |||

00 00 00 c0 ; key length | 00 00 00 c0 ; key length | |||

And the output is the 20 bytes: | And the output is the 20 bytes: | |||

b4 85 32 07 a9 da b2 9a 23 5a a8 a5 3f ed cd 65 92 26 0a 4a | 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: | 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 | 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ | |||

30 1a | 30 1d | |||

30 10 | ||||

06 08 2a 86 48 86 f7 0d 03 07 ; 3DES OID | ||||

04 04 | ||||

00 00 00 02 ; Counter | ||||

Rescorla [Page 5]Internet-Draft Diffie-Hellman Key Agreement Method | Rescorla [Page 5]Internet-Draft Diffie-Hellman Key Agreement Method | |||

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 | a2 06 | |||

04 04 | 04 04 | |||

00 00 00 c0 ; key length | 00 00 00 c0 ; key length | |||

And the output is the 20 bytes: | And the output is the 20 bytes: | |||

9d 95 43 57 15 e9 c8 31 ce 8a 64 fe e4 c8 d6 0c bf 50 a6 e1 | f6 3e b5 fb 5f 56 d9 b6 a8 34 03 91 c2 d3 45 34 93 2e 11 30 | |||

Consequently, | Consequently, | |||

K1'=b4 85 32 07 a9 da b2 9a | K1'=a0 96 61 39 23 76 f7 04 | |||

K2'=23 5a a8 a5 3f ed cd 65 | K2'=4d 90 52 a3 97 88 32 46 | |||

K3'=92 26 0a 4a 9d 95 43 57 | K3'=b6 7f 5f 1e f6 3e b5 fb | |||

Note: These keys are not parity adjusted | Note: These keys are not parity adjusted | |||

2.1.7. Example 2 | 2.1.7. Example 2 | |||

ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09 | 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 | 0a 0b 0c 0d 0e 0f 10 11 12 13 | |||

The key encryption algorithm is RC2 | 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 | 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 | |||

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 | 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 | |||

Consequently, the input to SHA-1 is: | 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 | 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ | |||

30 5e | 30 61 | |||

30 10 | 30 13 | |||

06 08 2a 86 48 86 f7 0d 03 02 ; RC2 OID | 06 0b 2a 86 48 86 f7 0d 01 09 10 03 07 ; RC2 wrap OID | |||

04 04 | 04 04 | |||

00 00 00 01 ; Counter | 00 00 00 01 ; Counter | |||

a0 42 | a0 42 | |||

04 40 | 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 ; 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 | 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 | |||

Rescorla [Page 6]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

a2 06 | a2 06 | |||

04 04 | 04 04 | |||

00 00 00 80 ; key length | 00 00 00 80 ; key length | |||

And the output is the 20 bytes: | And the output is the 20 bytes: | |||

Rescorla [Page 6]Internet-Draft Diffie-Hellman Key Agreement Method | 48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0 3e 7b 5d e9 | |||

52 45 e1 6d 27 57 be d6 8e 20 53 6b 38 b7 63 47 63 13 1d fd | ||||

Consequently, | Consequently, | |||

K=52 45 e1 6d 27 57 be d6 8e 20 53 6b 38 b7 63 47 | K=48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0 | |||

2.2. Key and Parameter Requirements | 2.2. Key and Parameter Requirements | |||

X9.42 requires that the group parameters be of the form p=jq + 1 | 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 gen- | where q is a large prime of length m and j>=2. An algorithm for gen- | |||

erating primes of this form (derived from the algorithms in FIPS PUB | erating primes of this form (derived from the algorithms in FIPS PUB | |||

186-1[DSS], and [X942]can be found in appendix A. | 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 - | 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 com- | 2)]. x should be randomly generated in this interval. y is then com- | |||

puted by calculating g^x mod p. To comply with this draft, m MUST be | puted by calculating g^x mod p. To comply with this draft, m MUST be | |||

>=160, (consequently, q MUST each be at least 160 bits long). When | >=160 bits in length, (consequently, q MUST be at least 160 bits | |||

symmetric ciphers stronger than DES are to be used, a larger m may be | long). When symmetric ciphers stronger than DES are to be used, a | |||

advisable. p must be a minimum of 160 bits long. | larger m may be advisable. p must be a minimum of 512 bits long. | |||

2.2.1. Group Parameter Generation | 2.2.1. Group Parameter Generation | |||

Agents SHOULD generate domain parameters (g,p,q) using the following | Agents SHOULD generate domain parameters (g,p,q) using the following | |||

algorithm, derived from [FIPS-186] and [X942]. When this algorithm is | algorithm, derived from [FIPS-186] and [X942]. When this algorithm is | |||

used, the correctness of the generation procedure can be verified by | used, the correctness of the generation procedure can be verified by | |||

a third party by the algorithm of 2.2.2. | a third party by the algorithm of 2.2.2. | |||

2.2.1.1. Generation of p, q | 2.2.1.1. Generation of p, q | |||

skipping to change at line 341 | skipping to change at line 350 | |||

0 <= b < 160. | 0 <= b < 160. | |||

1. Choose an arbitrary sequence of at least m bits and call it SEED. | 1. Choose an arbitrary sequence of at least m bits and call it SEED. | |||

Let g be the length of SEED in bits. | Let g be the length of SEED in bits. | |||

2. Set U = 0 | 2. Set U = 0 | |||

3. Set m' = m / 160, where / represents integer division, | 3. Set m' = m / 160, where / represents integer division, | |||

consequently, if m = 200, m' = 1. | consequently, if m = 200, m' = 1. | |||

Rescorla [Page 7]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

4. for i = 0 to m' - 1 | 4. for i = 0 to m' - 1 | |||

U = U + SHA[SEED + i] XOR SHA[(SEED + m' + i) mod 2^160] * 2^(160 * i) | U = U + SHA[SEED + i] XOR SHA[(SEED + m' + i) mod 2^160] * 2^(160 * i) | |||

Note that for m=160, this reduces to the algorithm of [FIPS186] | Note that for m=160, this reduces to the algorithm of [FIPS-186] | |||

Rescorla [Page 7]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

U = SHA[SEED] XOR SHA[(SEED+1) mod 2^160 ]. | U = SHA[SEED] XOR SHA[(SEED+1) mod 2^160 ]. | |||

5. Form q from U by setting the most significant bit (the 2^(m-1) bit) | 5. Form q from U by setting the most significant bit (the 2^(m-1) bit) | |||

and the least significant bit to 1. In terms of boolean operations, | 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 | 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. | 6. Use a robust primality algorithm to test whether q is prime. | |||

7. If q is not prime then go to 1. | 7. If q is not prime then go to 1. | |||

skipping to change at line 391 | skipping to change at line 400 | |||

14. If p passes the test performed in step 13 go to step 17. | 14. If p passes the test performed in step 13 go to step 17. | |||

15. Let counter = counter + 1 and offset = offset + n + 1. | 15. Let counter = counter + 1 and offset = offset + n + 1. | |||

16. If counter >= 4096 go to step 1. Otherwise go to step 9. | 16. If counter >= 4096 go to step 1. Otherwise go to step 9. | |||

17. Save the value of SEED and the value of counter for use | 17. Save the value of SEED and the value of counter for use | |||

in certifying the proper generation of p and q. | in certifying the proper generation of p and q. | |||

Note: A robust primality test is one where the probability of | Note: A robust primality test is one where the probability of | |||

Rescorla [Page 8]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

a non-prime number passing the test is at most 2^-80. [FIPS-186] | a non-prime number passing the test is at most 2^-80. [FIPS-186] | |||

provides a suitable algorithm, as does [X9.42]. | provides a suitable algorithm, as does [X9.42]. | |||

2.2.1.2. Generation of g | 2.2.1.2. Generation of g | |||

This section gives an algorithm (derived from [FIPS186]) for | This section gives an algorithm (derived from [FIPS-186]) for gen- | |||

erating g. | ||||

Rescorla [Page 8]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

generating g. | ||||

1. Let j = (p - 1)/q. | 1. Let j = (p - 1)/q. | |||

2. Set h = any integer, where 1 < h < p - 1 and h differs | 2. Set h = any integer, where 1 < h < p - 1 and h differs | |||

from any value previously tried. | from any value previously tried. | |||

3. Set g = h^j mod p | 3. Set g = h^j mod p | |||

4. If g = 1 go to step 2 | 4. If g = 1 go to step 2 | |||

2.2.2. Group Parameter Validation | 2.2.2. Group Parameter Validation | |||

skipping to change at line 440 | skipping to change at line 449 | |||

and sends it using the originatorKey production. If the sender's key | and sends it using the originatorKey production. If the sender's key | |||

is freshly generated for each message, the shared secret ZZ will be | is freshly generated for each message, the shared secret ZZ will be | |||

similarly different for each message and partyAInfo MAY be omitted, | similarly different for each message and partyAInfo MAY be omitted, | |||

since it serves merely to decouple multiple KEKs generated by the | since it serves merely to decouple multiple KEKs generated by the | |||

same set of pairwise keys. If, however, the same ephemeral sender key | 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 | is used for multiple messages (e.g. it is cached as a performance | |||

optimization) then a separate partyAInfo MUST be used for each mes- | optimization) then a separate partyAInfo MUST be used for each mes- | |||

sage. All implementations of this standard MUST implement Ephemeral- | sage. All implementations of this standard MUST implement Ephemeral- | |||

Static mode. | Static mode. | |||

In order to resist small subgroup attacks, the recipient SHOULD per- | In order to resist small subgroup attacks, the recipient SHOULD | |||

form 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. | ||||

Rescorla [Page 9]Internet-Draft Diffie-Hellman Key Agreement Method | Rescorla [Page 9]Internet-Draft Diffie-Hellman Key Agreement Method | |||

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 | 2.4. Static-Static Mode | |||

In Static-Static mode, both the sender and the recipient have a | In Static-Static mode, both the sender and the recipient have a | |||

static (and certified) key pair. Since the sender's and recipient's | 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 | 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 | each message. Thus, partyAInfo MUST be used (and different for each | |||

message) in order to ensure that different messages use different | message) in order to ensure that different messages use different | |||

KEKs. Implementations MAY implement Static-Static mode. | KEKs. Implementations MAY implement Static-Static mode. | |||

In order to prevent small subgroup attacks, both originator and reci- | In order to prevent small subgroup attacks, both originator and reci- | |||

pient SHOULD either perform the validation step described in S 2.1.5 | pient SHOULD either perform the validation step described in Section | |||

or verify that the CA has properly verified the validity of the key. | 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 | Acknowledgements | |||

The Key Agreement method described in this document is based on work | 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 | done by the ANSI X9F1 working group. The author wishes to extend his | |||

thanks for their assistance. | thanks for their assistance. | |||

The author also wishes to thank Paul Hoffman, Stephen Henson, Russ | The author also wishes to thank Burt Kaliski, Paul Hoffman, Stephen | |||

Housley, Brian Korver, Jim Schaad, Mark Schertler, Peter Yee, and | Henson, Russ Housley, Brian Korver, John Linn, Jim Schaad, Mark | |||

Robert Zuccherato for their expert advice and review. | Schertler, Peter Yee, and Robert Zuccherato for their expert advice | |||

and review. | ||||

References | References | |||

[CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-07.txt. | [CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-07.txt. | |||

[FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) | [FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) | |||

46-1, Data Encryption Standard, Reaffirmed 1988 January 22 | 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 | |||

(supersedes FIPS PUB 46, 1977 January 15). | (supersedes FIPS PUB 46, 1977 January 15). | |||

[FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) | [FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) | |||

81, DES Modes of Operation, 1980 December 2. | 81, DES Modes of Operation, 1980 December 2. | |||

[FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) | [FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) | |||

180-1, "Secure Hash Standard", 1995 April 17. | 180-1, "Secure Hash Standard", 1995 April 17. | |||

[FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) | [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) | |||

186, "Digital Signature Standard", 1994 May 19. | 186, "Digital Signature Standard", 1994 May 19. | |||

[P1363] "Standard Specifications for Public Key Cryptography", IEEE P1363 | [P1363] "Standard Specifications for Public Key Cryptography", IEEE P1363 | |||

Rescorla [Page 10]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

working group draft, 1998, Annex D. | working group draft, 1998, Annex D. | |||

[PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public | [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public | |||

Key Infrastructure Certificate and CRL Profile", RFC-XXXX. | Key Infrastructure Certificate and CRL Profile", RFC-XXXX. | |||

[LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, | [LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, | |||

"An efficient protocol for authenticated key agreement", | "An efficient protocol for authenticated key agreement", | |||

Technical report CORR 98-05, University of Waterloo, 1998. | Technical report CORR 98-05, University of Waterloo, 1998. | |||

Rescorla [Page 10]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

[LL97] C.H. Lim and P.J. Lee, "A key recovery attack on discrete log-based | [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, | schemes using a prime order subgroup", B.S. Kaliski, Jr., editor, | |||

Advances in Cryptology - Crypto '97, Lecture Notes in Computer Science, | Advances in Cryptology - Crypto '97, Lecture Notes in Computer Science, | |||

vol. 1295, 1997, Springer-Verlag, pp. 249-263. | vol. 1295, 1997, Springer-Verlag, pp. 249-263. | |||

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||

Levels." RFC 2119. March 1997. | Levels." RFC 2119. March 1997. | |||

[X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", | [X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", | |||

ANSI draft, 1998. | ANSI draft, 1998. | |||

skipping to change at line 519 | skipping to change at line 534 | |||

Security Considerations | Security Considerations | |||

All the security in this system is provided by the secrecy of the | All the security in this system is provided by the secrecy of the | |||

private keying material. If either sender or recipient private keys | private keying material. If either sender or recipient private keys | |||

are disclosed, all messages sent or received using that key are | are disclosed, all messages sent or received using that key are | |||

compromised. Similarly, loss of the private key results in an inabil- | compromised. Similarly, loss of the private key results in an inabil- | |||

ity to read messages sent using that key. | ity to read messages sent using that key. | |||

Static Diffie-Hellman keys are vulnerable to a small subgroup attack | Static Diffie-Hellman keys are vulnerable to a small subgroup attack | |||

[LAW98]. In practice, this issue arises for both sides in Static- | [LAW98]. In practice, this issue arises for both sides in Static- | |||

Static mode and for the receiver during Ephemeral-Static mode. S 2.3 | Static mode and for the receiver during Ephemeral-Static mode. Sec- | |||

and 2.4 describe appropriate practices to protect against this | tions 2.3 and 2.4 describe appropriate practices to protect against | |||

attack. Alternatively, it is possible to generate keys in such a | this attack. Alternatively, it is possible to generate keys in such a | |||

fashion that they are resistant to this attack. See [LL97] | fashion that they are resistant to this attack. See [LL97] | |||

In order to securely generate a symmetric key of length l, m (the | The security level provided by these methods depends on several fac- | |||

length in bits of q, and hence x) should be at least 2l. m MUST | tors. It depends on the length of the symmetric key (typically, a 2^l | |||

always be >= 160. Consequently, for RC2, m should be >=256 and for | security level if the length is l bits); the size of the prime q (a | |||

3DES, >=224 (the effective length of 3DES keys is 112 bits). | 2^{m/2} security level); and the size of the prime p (where the secu- | |||

rity 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 | Author's Address | |||

Rescorla [Page 11]Internet-Draft Diffie-Hellman Key Agreement Method | ||||

Eric Rescorla <ekr@rtfm.com> | Eric Rescorla <ekr@rtfm.com> | |||

RTFM Inc. | RTFM Inc. | |||

30 Newell Road, #16 | 30 Newell Road, #16 | |||

East Palo Alto, CA 94303 | East Palo Alto, CA 94303 | |||

Rescorla [Page 11]Internet-Draft Diffie-Hellman Key Agreement Method | Rescorla [Page 12]Internet-Draft Diffie-Hellman Key Agreement Method | |||

Table of Contents | Table of Contents | |||

1. Introduction ................................................... 1 | 1. Introduction ................................................... 1 | |||

1.1. Discussion of this Draft ..................................... 2 | 1.1. Discussion of this Draft ..................................... 2 | |||

1.2. Requirements Terminology ..................................... 2 | 1.2. Requirements Terminology ..................................... 2 | |||

2. Overview Of Method ............................................. 2 | 2. Overview Of Method ............................................. 2 | |||

skipping to change at line 558 | skipping to change at line 581 | |||

2.1. Key Agreement ................................................ 2 | 2.1. Key Agreement ................................................ 2 | |||

2.1.1. Generation of ZZ ........................................... 2 | 2.1.1. Generation of ZZ ........................................... 2 | |||

2.1.2. Generation of Keying Material .............................. 3 | 2.1.2. Generation of Keying Material .............................. 3 | |||

2.1.3. KEK Computation ............................................ 4 | 2.1.3. KEK Computation ............................................ 4 | |||

2.1.4. Keylengths for common algorithms ........................... 4 | 2.1.4. Keylengths for common algorithms ........................... 4 | |||

2.1.5. Public Key Validation ...................................... 4 | 2.1.5. Public Key Validation ...................................... 5 | |||

2.1.6. Example 1 .................................................. 5 | 2.1.6. Example 1 .................................................. 5 | |||

2.1.7. Example 2 .................................................. 6 | 2.1.7. Example 2 .................................................. 6 | |||

2.2. Key and Parameter Requirements ............................... 7 | 2.2. Key and Parameter Requirements ............................... 7 | |||

2.2.1. Group Parameter Generation ................................. 7 | 2.2.1. Group Parameter Generation ................................. 7 | |||

2.2.1.1. Generation of p, q ....................................... 7 | 2.2.1.1. Generation of p, q ....................................... 7 | |||

2.2.1.2. Generation of g .......................................... 8 | 2.2.1.2. Generation of g .......................................... 9 | |||

2.2.2. Group Parameter Validation ................................. 9 | 2.2.2. Group Parameter Validation ................................. 9 | |||

2.3. Ephemeral-Static Mode ........................................ 9 | 2.3. Ephemeral-Static Mode ........................................ 9 | |||

2.4. Static-Static Mode ........................................... 10 | 2.4. Static-Static Mode ........................................... 10 | |||

2.4. Acknowledgements ............................................. 10 | 2.4. Acknowledgements ............................................. 10 | |||

Rescorla [Page 12]Internet-Draft Diffie-Hellman Key Agreement Method | Rescorla [Page 13]Internet-Draft Diffie-Hellman Key Agreement Method | |||

2.4. References ................................................... 10 | 2.4. References ................................................... 10 | |||

Security Considerations ........................................... 11 | Security Considerations ........................................... 11 | |||

Author's Address .................................................. 11 | Author's Address .................................................. 11 | |||

End of changes. | ||||

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |