rfc3211.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页

      1. Set the first 4 bytes of the CEK block to the Skipjack key size
         (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,
         encrypted the padded Skipjack key.

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





Gutmann                     Standards Track                     [Page 6]

RFC 3211           Password-based Encryption for CMS       December 2001


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

   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 a high probability of a collision between different blocks
   of encrypted CEKs.  If an opponent manages to obtain a CEK, they may
   be able to solve for other CEKs.  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.

   An additional feature of the double wrapping is that it doesn't
   require the use of any extra algorithms such as hash algorithms in
   addition to the wrapping algorithm itself, allowing it to be
   implemented in devices which only support one type of encryption
   algorithm.  A typical example of such a device is a crypto token such
   as a smart card which often only supports a single block cipher and a
   single public-key algorithm, making it impossible to wrap keys if the
   use of an additional algorithm were required.

3. Test Vectors

   This section contains two sets of test vectors, a very basic set for
   DES which can be used to verify correctness and which uses an
   algorithm which is freely exportable from the US, and a stress-test
   version which uses very long passphrase and key sizes and a mixture
   of algorithms which can be used to verify the behaviour in extreme
   cases.




Gutmann                     Standards Track                     [Page 7]

RFC 3211           Password-based Encryption for CMS       December 2001


   The basic test contains two subtests, a known-answer test for the key
   derivation stage and a full test of the key wrapping.  Both tests use
   a DES-CBC key derived from the password "password" with salt { 12 34
   56 78 78 56 34 12 } using 5 iterations of PBKDF2.  In the known
   answer test the IV is set to all zeroes (equivalent to using ECB) and
   used to encrypt an all-zero data block.

   The following values are obtained for the known-answer test:

   PKCS #5v2 values:

      input         70 61 73 73 77 6f 72 64
      passphrase:   "password"
      input salt:   12 34 56 78 78 56 34 12
      iterations:   5

      output key:   D1 DA A7 86 15 F2 87 E6
      known answer: 9B BD 78 FC 11 A3 A9 08

   The following values are obtained when wrapping a 64-bit (parity-
   adjusted) DES-EBC key:

   PKCS #5v2 values:

      input         70 61 73 73 77 6f 72 64
      passphrase:   "password"
      input salt:   12 34 56 78 78 56 34 12
      iterations:   5

      output key:   D1 DA A7 86 15 F2 87 E6

   CEK formatting phase:

      length byte:  08
      key check:    73 9D 83
      CEK:          8C 62 7C 89 73 23 A2 F8
      padding:      C4 36 F5 41

      complete      08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41
      CEK block:











Gutmann                     Standards Track                     [Page 8]

RFC 3211           Password-based Encryption for CMS       December 2001


   Key wrap phase (wrap CEK block using DES key):

      IV:           EF E5 98 EF 21 B3 3D 6D

      first encr.   06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D4
      pass output:
      second encr.  B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10
      pass output:

   ASN.1 encoded PasswordRecipientInfo:

    0 A3   68: [3] {
    2 02    1:   INTEGER 0
    5 A0   26:   [0] {
    7 06    9:     OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
   18 30   13:     SEQUENCE {
   20 04    8:       OCTET STRING
             :         12 34 56 78 78 56 34 12
   30 02    1:       INTEGER 5
             :       }
             :     }
   34 30   32:   SEQUENCE {
   36 06   11:     OBJECT IDENTIFIER id-alg-PWRI-KEK
             :         (1 2 840 113549 1 9 16 3 9)
   33 30   17:     SEQUENCE {
   35 06    5:       OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7)
   42 04    8:       OCTET STRING
             :         EF E5 98 EF 21 B3 3D 6D
             :       }
             :     }
   68 04   16:   OCTET STRING
             :     B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10
             :   }


















Gutmann                     Standards Track                     [Page 9]

RFC 3211           Password-based Encryption for CMS       December 2001


   The following values are obtained when wrapping a 256-bit key (for
   example one for AES or Blowfish) 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 73 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






Gutmann                     Standards Track                    [Page 10]

RFC 3211           Password-based Encryption for CMS       December 2001


   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   35:   SEQUENCE {
   36 06   11:     OBJECT IDENTIFIER id-alg-PWRI-KEK
             :         (1 2 840 113549 1 9 16 3 9)
   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
             :       }
             :     }
   71 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
   of the underlying mechanisms employed, for which further information
   can be found in RFC 2630 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.












Gutmann                     Standards Track                    [Page 11]

RFC 3211           Password-based Encryption for CMS       December 2001


5. IANA Considerations

   The PasswordRecipientInfo key encryption algorithms are identified by
   object identifiers (OIDs).  OIDs were assigned from an arc
   contributed to the S/MIME Working Group by the RSA Security.  Should
   additional encryption algorithms be introduced, the advocates for
   such algorithms are expected to assign the necessary OIDs from their
   own arcs.  No action by the IANA is necessary for this document or
   any anticipated updates.

Acknowledgments

   The author would like to thank Jim Schaad, Phil Griffin, and the
   members of the S/MIME Working Group for their comments and feedback
   on this document.