draft-ietf-smime-password-05.txt   draft-ietf-smime-password-06.txt 
Internet Draft Editor: Peter Gutmann Internet Draft Editor: Peter Gutmann
draft-ietf-smime-password-05.txt University of Auckland draft-ietf-smime-password-06.txt University of Auckland
August 26, 2001 October 16, 2001
Expires February 2002 Expires April 2002
Password-based Encryption for CMS Password-based Encryption for CMS
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 29 skipping to change at line 29
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption. This document
provides a method of encrypting data using user-supplied passwords and,
by extension, any form of variable-length keying material which isn't
necessarily an algorithm-specific fixed-format key.
1. Introduction 1. Introduction
This document describes a password-based content encryption mechanism This document describes a password-based content encryption mechanism
for CMS. This is implemented as a new RecipientInfo type and is an for CMS. This is implemented as a new RecipientInfo type and is an
extension to the RecipientInfo types currently defined in RFC 2630 extension to the RecipientInfo types currently defined in RFC 2630
[RFC2630]. [RFC2630].
The format of the messages are described in ASN.1 [ASN1]. The format of the messages are described in ASN.1 [ASN1].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
skipping to change at line 115 skipping to change at line 123
Password-based key wrapping is a two-stage process, a first stage in Password-based key wrapping is a two-stage process, a first stage in
which a user-supplied password is converted into a KEK if required, and which a user-supplied password is converted into a KEK if required, and
a second stage in which the KEK is used to encrypt a CEK. These two a second stage in which the KEK is used to encrypt a CEK. These two
stages are identified by the two algorithm identifiers. Although the stages are identified by the two algorithm identifiers. Although the
PKCS #5v2 standard [RFC2898] goes one step further to wrap these up PKCS #5v2 standard [RFC2898] goes one step further to wrap these up
into a single algorithm identifier, this design is particular to that into a single algorithm identifier, this design is particular to that
standard and may not be applicable for other key wrapping mechanisms. standard and may not be applicable for other key wrapping mechanisms.
For this reason the two steps are specified separately. For this reason the two steps are specified separately.
The current format doesn't provide any means of differentiating between The current format doesn't provide any means of differentiating between
multiple password recipient info's, which would occur for example if multiple password recipient infos, which would occur for example if
two passwords are used to encrypt the same data. Unfortunately there two passwords are used to encrypt the same data. Unfortunately there
is a lack of existing practice in this area, since typical applications is a lack of existing practice in this area, since typical applications
follow the model of encrypting data such as a file with a single follow the model of encrypting data such as a file with a single
password obtained from the user. Two possible options would be to use password obtained from the user. Without any clear requirements, an
an OCTET STRING hole or a SEQUENCE OF everything-imaginable OPTIONAL, appropriate multiple password mechanism would be difficult
however without any clear indication of what's required it's probable
that every implementation will choose to interpret the field
differently, leading to non-interoperability between applications.
Given this incompleteness, an appropriate mechanism would be difficult
(perhaps impossible) to define at this time. If sufficient demand (perhaps impossible) to define at this time. If sufficient demand
emerges then this may be addressed in a future version of this emerges then this may be addressed in a future version of this
document, for example by adding an optional identification field of an document, for example by adding an optional identification field of an
appropriate form. appropriate form.
2 Supported Algorithms 2 Supported Algorithms
This section lists the algorithms that must be implemented. Additional This section lists the algorithms that must be implemented. Additional
algorithms that should be implemented are also included. algorithms that should be implemented are also included.
skipping to change at line 290 skipping to change at line 294
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 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 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. 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 CEKs 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 CEKs. 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 CEKs. 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
applied to the inner layer of encryption, even wrapping the same CEK applied to the inner layer of encryption, even wrapping the same CEK
with the same KEK will result in a completely different wrapped key with the same KEK will result in a completely different wrapped key
each time. each time.
An additional feature of the double wrapping is that it doens't require An additional feature of the double wrapping is that it doens't require
the use of any extra algorithms such as hash algorithms in addition to the use of any extra algorithms such as hash algorithms in addition to
the wrapping algorithm itself, allowing it to be implemented in devices the wrapping algorithm itself, allowing it to be implemented in devices
 End of changes. 

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