draft-ietf-smime-password-01.txt   draft-ietf-smime-password-02.txt 
Internet Draft Editor: Peter Gutmann Internet Draft Editor: Peter Gutmann
draft-ietf-smime-password-01.txt University of Auckland draft-ietf-smime-password-02.txt University of Auckland
November 20, 1999 March 2, 2000
Expires May 2000 Expires September 2000
Password-based Encryption for S/MIME Password-based Encryption for S/MIME
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at line 179 skipping to change at line 179
content-encryption or wrapping algorithms, relying only on the use of a content-encryption or wrapping algorithms, relying only on the use of a
block cipher to perform the wrapping. block cipher to perform the wrapping.
2.3.1 Key Wrap 2.3.1 Key Wrap
The key wrap algorithm encrypts a CEK with a KEK in a manner which The key wrap algorithm encrypts a CEK with a KEK in a manner which
ensures that every bit of plaintext effects every bit of ciphertext. ensures that every bit of plaintext effects every bit of ciphertext.
This makes it equivalent in function to the package transform [PACKAGE] This makes it equivalent in function to the package transform [PACKAGE]
without requiring additional mechanisms or resources such as hash without requiring additional mechanisms or resources such as hash
functions or cryptographically strong random numbers. The key wrap functions or cryptographically strong random numbers. The key wrap
algorithm is as follows: algorithm is performed in two phases, a first phase which formats the
CEK into a form suitable for encryption by the KEK, and a second phase
which wraps the formatted CEK using the KEK.
1. Pad the key out to a multiple of the KEK cipher block size using Key formatting: Create a formatted CEK block consisting of the
random data so that the total data size is at least two KEK cipher following:
blocks long. The padding data does not have to be
cryptographically strong, although unpredictability helps.
2. Encrypt the padded key using the KEK. 1. A one-byte count of the number of bytes in the CEK.
3. Without resetting the IV (that is, using the last ciphertext block 2. A check value containing the bitwise complement of the first three
bytes of the CEK.
3. The CEK.
4. Enough random padding data to make the CEK data block at least two
KEK cipher blocks long (the fact that 32 bits of count+check value
are used means that even with a 40-bit CEK, the resulting data
size will always be at least two (64-bit) cipher blocks long).
The padding data does not have to be cryptographically strong,
although unpredictability helps.
The formatted CEK block then looks as follows:
CEK byte count || check value || CEK || padding (if required)
Key wrapping:
1. Encrypt the padded key using the KEK.
2. Without resetting the IV (that is, using the last ciphertext block
as the IV), encrypt the encrypted padded key a second time. as the IV), encrypt the encrypted padded key a second time.
The resulting double-encrypted data is the EncryptedKey. The resulting double-encrypted data is the EncryptedKey.
2.3.2 Key Unwrap 2.3.2 Key Unwrap
Key unwrapping:
1. Using the n-1'th ciphertext block as the IV, decrypt the n'th 1. Using the n-1'th ciphertext block as the IV, decrypt the n'th
ciphertext block. ciphertext block.
2. Using the decrypted n'th ciphertext block as the IV, decrypt the 2. Using the decrypted n'th ciphertext block as the IV, decrypt the
1st ... n-1'th ciphertext blocks. This strips the outer layer of 1st ... n-1'th ciphertext blocks. This strips the outer layer of
encryption. encryption.
3. Decrypt the inner layer of encryption using the KEK. 3. Decrypt the inner layer of encryption using the KEK.
The size of the key in the padded data is determined by the algorithm Key format verification:
specified in the ContentEncryptionAlgorithmIdentifier.
1a.If the CEK byte count is less than the minimum allowed key size
(usually 5 bytes for 40-bit keys) or greater than the wrapped CEK
length or not valid for the CEK algorithm (eg not 16 or 24 bytes
for triple DES), the KEK was invalid.
1b.If the bitwise complement of the key check value doesn't match
the first three bytes of the key, the KEK was invalid.
2.3.3 Example 2.3.3 Example
Given a content-encryption algorithm of Skipjack and a KEK algorithm of Given a content-encryption algorithm of Skipjack and a KEK algorithm of
Triple-DES, the wrap steps are as follows: Triple-DES, the wrap steps are as follows:
1. Pad the 80-bit (10-byte) Skipjack CEK to 16 bytes (two triple-DES 1. Set the first 4 bytes of the CEK block to the Skipjack key size
blocks) using 6 bytes of random data. (10 bytes) and the bitwise complement of the first three bytes of
the CEK.
2. Append the 80-bit (10-byte) Skipjack CEK and pad the total to 16
bytes (two triple-DES blocks) using 2 bytes of random data.
2. Using the IV given in the KeyEncryptionAlgorithmIdentifer, 2. Using the IV given in the KeyEncryptionAlgorithmIdentifer,
encrypted the padded Skipjack key. encrypted the padded Skipjack key.
3. Without resetting the IV, encrypt the encrypted padded key a 3. Without resetting the IV, encrypt the encrypted padded key a
second time. second time.
The unwrap steps are as follows: The unwrap steps are as follows:
1. Using the first 8 bytes of the double-encrypted key as the IV, 1. Using the first 8 bytes of the double-encrypted key as the IV,
decrypt the second 8 bytes. decrypt the second 8 bytes.
2. Without resetting the IV, decrypt the first 8 bytes. 2. Without resetting the IV, decrypt the first 8 bytes.
3. Decrypt the inner layer of encryption using the the IV given in 3. Decrypt the inner layer of encryption using the the IV given in
the KeyEncryptionAlgorithmIdentifer to recover the padded Skipjack the KeyEncryptionAlgorithmIdentifer to recover the padded Skipjack
key. key.
4. If the length byte isn't equal to the Skipjack key size (80 bits
or 10 bytes) or the bitwise complement of the check bytes doesn't
match the first three bytes of the CEK, the KEK was invalid.
2.3.4 Rationale for the Double Wrapping 2.3.4 Rationale for the Double Wrapping
If many CEK's are encrypted in a standard way with the same KEK and the If many CEK's are encrypted in a standard way with the same KEK and the
KEK has a 64-bit block size then after about 2^32 encryptions there is KEK has a 64-bit block size then after about 2^32 encryptions there is
a high probability of a collision between different blocks of encrypted a high probability of a collision between different blocks of encrypted
CEK's. If an opponent manages to obtain a CEK, they may be able to CEK's. If an opponent manages to obtain a CEK, they may be able to
solve for other CEK's. The double-encryption wrapping process, which solve for other CEK's. The double-encryption wrapping process, which
makes every bit of ciphertext dependent on every bit of the CEK, makes every bit of ciphertext dependent on every bit of the CEK,
eliminates this collision problem (as well as preventing other eliminates this collision problem (as well as preventing other
potential problems such as bit-flipping attacks). Since the IV is potential problems such as bit-flipping attacks). Since the IV is
skipping to change at line 306 skipping to change at line 342
} }
This allows arbitrary actual and effective key sizes to be specified This allows arbitrary actual and effective key sizes to be specified
for compatibility with existing usage. Although implementations SHOULD for compatibility with existing usage. Although implementations SHOULD
NOT use this alternative (using instead the one in section 2.4.1) NOT use this alternative (using instead the one in section 2.4.1)
experience has shown that implementors will continue to use oddball RC2 experience has shown that implementors will continue to use oddball RC2
parameters anyway, so new implementations should be prepared to parameters anyway, so new implementations should be prepared to
encounter and handle actual and effective key sizes ranging from 40 up encounter and handle actual and effective key sizes ranging from 40 up
to around 200 bits. to around 200 bits.
[It has been suggested that there may be yet another parameter which
needs to be specified, the actual (rather than effective) key size
of a wrapped RC2 CEK. This can be added as a third integer
parameter if necessary]
2.4.3 Rationale 2.4.3 Rationale
The reason for providing for the handling of oddball key sizes is The reason for providing for the handling of oddball key sizes is
compatibility with existing applications, for example a mailing-list compatibility with existing applications, for example a mailing-list
exploder or mail gateway may take an RSA-wrapped CEK generated by a exploder or mail gateway may take an RSA-wrapped CEK generated by a
current application and repackage it with a KEK, so we need a mechanism current application and repackage it with a KEK, so we need a mechanism
for handling strange key lengths in a manner which is compatible with for handling strange key lengths in a manner which is compatible with
existing usage. The alternative RC2 AlgorithmIdentifier, although not existing usage. The alternative RC2 AlgorithmIdentifier, although not
recommended, provides a means of ensuring this compatibility. recommended, provides a means of ensuring this compatibility.
3. Security Considerations 3. Test Vectors
The following values are obtained when wrapping a 256-bit Blowfish-CFB
key using a triple DES-CBC key derived from the passphrase "All
n-entities must communicate with other n-entities via n-1
entiteeheehees" with salt { 12 34 56 78 78 56 34 12 } using 500
iterations of PBKDF2.
PKCS #5v2 values:
input 41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D
passphrase: 75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20
77 69 74 68 20 6F 74 68 65 72 20 6E 2d 65 6E 74
69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E
74 69 74 65 65 68 65 65 68 65 65 73
"All n-entities must communicate with other "
"n-entities via n-1 entiteeheehees"
input
salt: 12 34 56 78 78 56 34 12
iterations: 500
output 6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86
3DES key: 07 12 63 80 CC 47 AB 2D
CEK formatting phase:
length byte: 20
key check: 73 9C 82
CEK: 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5
D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B
padding: FA 06 0A 45
complete 20 93 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB
CEK block: 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03
C7 1B AF 3B FA 06 0A 45
Key wrap phase (wrap CEK block using 3DES key):
IV: BA F1 CA 79 31 21 3C 4E
first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD
pass output: 27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80
96 9E 65 27 9E 12 6A EB
second encr. C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55
pass output: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9
EC 74 E6 CA D7 DB 26 0C
ASN.1 encoded PasswordRecipientInfo:
0 A3 96: [3] {
2 02 1: INTEGER 0
5 A0 27: [0] {
7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
18 30 14: SEQUENCE {
20 04 8: OCTET STRING
: 12 34 56 78 78 56 34 12
30 02 2: INTEGER 500
: }
: }
34 30 20: SEQUENCE {
36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
46 04 8: OCTET STRING
: BA F1 CA 79 31 21 3C 4E
: }
56 04 40: OCTET STRING
: C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55
: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9
: EC 74 E6 CA D7 DB 26 0C
: }
4. Security Considerations
The security of this recipient information type rests on the security The security of this recipient information type rests on the security
of the underlying mechanisms employed, for which further information of the underlying mechanisms employed, for which further information
can be found in RFC 2640 and PKCS5v2. More importantly, however, when can be found in RFC 2640 and PKCS5v2. More importantly, however, when
used with a password the security of this information type rests on the used with a password the security of this information type rests on the
entropy of the user-selected password, which is typically quite low. entropy of the user-selected password, which is typically quite low.
Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED, Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED,
although it should be recognized that even with pass phrases it will be although it should be recognized that even with pass phrases it will be
difficult to use this recipient information type to derive a KEK with difficult to use this recipient information type to derive a KEK with
sufficient entropy to properly protect a 128-bit (or higher) CEK. sufficient entropy to properly protect a 128-bit (or higher) CEK.
5. Changes Since the Last Version
- Added length count due to concerns over odd-length RC2 keys
- Added check value to allow better error reporting and balance
out the single-byte length value
- Included test vectors
Author Address Author Address
Peter Gutmann Peter Gutmann
University of Auckland University of Auckland
Private Bag 92019 Private Bag 92019
Auckland, New Zealand Auckland, New Zealand
pgut001@cs.auckland.ac.nz pgut001@cs.auckland.ac.nz
References References
 End of changes. 

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