[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 rfc3211                                  
Internet Draft                                      Editor: Peter Gutmann
draft-ietf-smime-password-01.txt                    University of Auckland
November 20, 1999
Expires May 2000

                   Password-based Encryption for S/MIME

Status of this memo

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, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at


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.

This draft is being discussed on the "ietf-smime" mailing list.  To
join the list, send a message to <ietf-smime-request@imc.org> with the
single word "subscribe" in the body of the message.  Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime>.

1. Introduction

This document describes a password-based content encryption mechanism
for S/MIME.  This is implemented as a new RecipientInfo type and is an
extension to the RecipientInfo types currently defined in RFC 2640

The format of the messages are described in ASN.1:1994 [ASN1].

"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].

1.1 Password-based Content Encryption

CMS currently defined three recipient information types for public-key
key wrapping (KeyTransRecipientInfo), conventional key wrapping
(KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo).  The
recipient information described here adds a fourth type,
PasswordRecipientInfo, which provides for password-based key wrapping.

1.2 RecipientInfo Types

The new recipient information type is an extension to the RecipientInfo
type defined in section 6.2 of CMS, extending the types to:

    RecipientInfo ::= CHOICE {
      ktri KeyTransRecipientInfo,
      kari [1] KeyAgreeRecipientInfo,
      kekri [2] KEKRecipientInfo,
      pwri [3] PasswordRecipientinfo   -- New RecipientInfo type

Although the recipient information generation process is described in
terms of a password-based operation (since this will be its most common
use), the transformation employed is a general-purpose key derivation
one which allows any type of keying material to be converted into a key
specific to a particular content-encryption algorithm.  Since the most
common use for password-based encryption is to encrypt files which are
stored locally (rather than being transmitted across a network), the
term "recipient" is somewhat misleading, but is used here because the
other key transport mechanisms have always been described in similar

1.2.1  PasswordRecipientInfo Type

Recipient information using a user-supplied password or previously
agreed-upon key is represented in the type PasswordRecipientInfo.  Each
instance of PasswordRecipientInfo will transfer the content-encryption
key (CEK) to one or more recipients who have the previously agreed-upon
password or key-encryption key (KEK).

    PasswordRecipientInfo ::= SEQUENCE {
      version CMSVersion,   -- Always set to 0
                        [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
      keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
      encryptedKey EncryptedKey }

The fields of type PasswordRecipientInfo have the following meanings:

  version is the syntax version number.  It shall always be 0.

  keyDerivationAlgorithm identifies the key-derivation algorithm, and
  any associated parameters, used to derive the KEK from the
  user-supplied password.  If this field is absent, the KEK is supplied
  from an external source, for example a crypto token such as a smart

  keyEncryptionAlgorithm identifies the content-encryption algorithm,
  and any associated parameters, used to encrypt the CEK with the KEK.

  encryptedKey is the result of encrypting the content-encryption key
  with the KEK.

1.2.2 Rationale

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
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
PKCS #5 standard goes one step further to wrap these up into a single
algorithm identifier, this design is particular to that standard and
may not be applicable for other key wrapping mechanisms.  For this
reason the two steps are specified separately.

2 Supported Algorithms

This section lists the algorithms that must be implemented.  Additional
algorithms that should be implemented are also included.

2.1 Key Derivation Algorithms

These algorithms are used to convert the password into a KEK.  The key
derivation algorithms are:

    KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {

CMS implementations MUST include PBKDF2 [PKCS5v2].

2.2 Key Encryption Algorithms

These algorithms are used to encrypt the content (the key) using the
derived KEK.  The content encryption algorithms are:

    KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs

CMS implementations MUST include Triple-DES in CBC mode, SHOULD include
RC2 in CBC mode, and MAY include other algorithms such as CAST-128,
RC5, IDEA, Skipjack, and encryption modes as required.  CMS
implementations SHOULD NOT include any KSG ciphers such as RC4 or a
block cipher in OFB mode, and SHOULD NOT include a block cipher in ECB
mode.  The use of RC2 has special requirements, see section 2.4 for

2.3 Symmetric Key Encryption Algorithms

The key wrap algorithm is used to wrap the CEK with the KEK.  There is
no requirement that the content-encryption algorithm match the KEK
algorithm, although care should be taken to ensure that, if different
algorithms are used, they offer an equivalent level of security (for
example wrapping a Triple-DES key with an RC2/40 key leads to a severe
impedance mismatch in encryption strength).

The key wrap algorithm specified below is independent of the
content-encryption or wrapping algorithms, relying only on the use of a
block cipher to perform the wrapping.

2.3.1 Key Wrap

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.
This makes it equivalent in function to the package transform [PACKAGE]
without requiring additional mechanisms or resources such as hash
functions or cryptographically strong random numbers.  The key wrap
algorithm is as follows:

  1. Pad the key out to a multiple of the KEK cipher block size using
     random data so that the total data size is at least two KEK cipher
     blocks long.  The padding data does not have to be
     cryptographically strong, although unpredictability helps.

  2. Encrypt the padded key using the KEK.

  3. Without resetting the IV (that is, using the last ciphertext block
     as the IV), encrypt the encrypted padded key a second time.

The resulting double-encrypted data is the EncryptedKey.

2.3.2 Key Unwrap

  1. Using the n-1'th ciphertext block as the IV, decrypt the n'th
     ciphertext block.

  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

  3. Decrypt the inner layer of encryption using the KEK.

The size of the key in the padded data is determined by the algorithm
specified in the ContentEncryptionAlgorithmIdentifier.

2.3.3 Example

Given a content-encryption algorithm of Skipjack and a KEK algorithm of
Triple-DES, the wrap steps are as follows:

  1. Pad the 80-bit (10-byte) Skipjack CEK to 16 bytes (two triple-DES
     blocks) using 6 bytes of random data.

  2. Using the IV given in the KeyEncryptionAlgorithmIdentifer,
     encrypted the padded Skipjack key.

  3. Without resetting the IV, encrypt the encrypted padded key a
     second time.

The unwrap steps are as follows:

  1. Using the first 8 bytes of the double-encrypted key as the IV,
     decrypt the second 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
     the KeyEncryptionAlgorithmIdentifer to recover the padded Skipjack

2.3.4 Rationale for the Double Wrapping

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
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
solve for other CEK's.  The double-encryption wrapping process, which
makes every bit of ciphertext dependent on every bit of the CEK,
eliminates this collision problem (as well as preventing other
potential problems such as bit-flipping attacks).  Since the IV is
applied to the inner layer of encryption, even wrapping the same CEK
with the same KEK will result in a completely different wrapped key
each time.

2.4 Special Handling for RC2 Keys

For a variety of historical, political, and software-peculiarity
reasons which are beyond the scope of this document, the handling of
keys for the RC2 algorithm [RFC2268] by different implementations is
somewhat arbitrary.  In particular, the choice of actual vs effective
key bits used in the algorithm is often unclear.  The standard RC2
AlgorithmIdentifier only allows the effective key bits to be specified,
leaving the actual key bits to be communicated via out-of-band means,
which in some cases means hardcoding them into applications.  Solving
this problem requires two things, a precise definition of how keys
represented with the standard RC2 AlgorithmIdentifier are handled, and
a new RC2 AlgorithmIdentifier which allows keys currently in use by
different applications to be handled.

2.4.1 Handling of RC2 with RFC 2268 AlgorithmIdentifier

RFC 2268 defines the following AlgorithmIdentifier for RC2:

    rc2CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) US(840)
                        rsadsi(113549) encryptionAlgorithm(3) 2}

    RC2-CBCParameter ::= CHOICE {
      iv IV,
      params SEQUENCE {
        version INTEGER,
        iv OCTET STRING

where the version field encodes the effective key size in a complex
manner specified in the RFC.  Where this algorithm identifier is used,
the actual key size shall be the same size as the effective key size as
given by the version field.  When RC2 is to be used, implementations
should use this AlgorithmIdentifier and parameters, and when this
AlgorithmIdentifier is used the actual key size MUST NOT be a value
other than the effective key size (to use a different size, see section

2.4.2 Handling of RC2 with Other Key Sizes

If the use of an actual key size of other than the effective key size
is required, implementations MUST use the following

    rc2CBC OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 666 13}
    RC2-CBCParameter ::= SEQUENCE {
      actualKeySize INTEGER,        -- Actual key size in bits
      effectiveKeySize INTEGER,     -- Effective key size in bits

This allows arbitrary actual and effective key sizes to be specified
for compatibility with existing usage.  Although implementations SHOULD
NOT use this alternative (using instead the one in section 2.4.1)
experience has shown that implementors will continue to use oddball RC2
parameters anyway, so new implementations should be prepared to
encounter and handle actual and effective key sizes ranging from 40 up
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

The reason for providing for the handling of oddball key sizes is
compatibility with existing applications, for example a mailing-list
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
for handling strange key lengths in a manner which is compatible with
existing usage.  The alternative RC2 AlgorithmIdentifier, although not
recommended, provides a means of ensuring this compatibility.

3. Security Considerations

The security of this recipient information type rests on the security
of the underlying mechanisms employed, for which further information
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
entropy of the user-selected password, which is typically quite low.
Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED,
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
sufficient entropy to properly protect a 128-bit (or higher) CEK.

Author Address

Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand


  ASN1  Recommendation X.680: Specification of Abstract Syntax Notation
        One (ASN.1), 1994.

  PKCS5v2 PKCS #5 v2.0: Password-Based Cryptography Standard, RSA
        Laboratories, 25 March 1999.

  RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels,
        S.Bradner, March 1997.

  RFC2268 A Description of the RC2(r) Encryption Algorithm, R.Rivest,
        March 1998.

  RFC2640 Cryptographic Message Syntax, draft-ietf-smime-cms-11.txt, Russ
        Housley, April 1999.

  PACKAGE All-or-Nothing Encryption and the Package Transform,
        R.Rivest, Proceedings of Fast Software Encryption '97, Haifa,
        Israel, January 1997.

Appendix A: ASN.1 Module

    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) modules(0) pwri(n+1) }



  FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
               pkcs-5(5) }
    PBKDF2-params, PBES2-Encs;

PasswordRecipientInfo ::= SEQUENCE {
  version CMSVersion,       -- Always set to 0
                    [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }

KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {

KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs


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