RFC 3217

Triple-DES and RC2 Key Wrapping

📅 published December 2001, from ietf

RFC 3217: Triple-DES and RC2 Key Wrapping ✨

Okay bestie, this one is all about wrapping keys, which means encrypting one symmetric key with another. It's giving security nerd realness 🔐💖

  • Network Working Group
  • Author: R. Housley, RSA Laboratories
  • Category: Informational
  • Date: December 2001
  • Obsoletes / Updates: the header doesn't list any 🌸

Status of this Memo

Okay so this memo just provides information for the Internet community 📚. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited, so share it with everyone 🦋

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

Abstract

This doc lays out how to wrap one Triple-DES key with another Triple-DES key, and how to wrap one RC2 key with another RC2 key ✨. These key wrap algorithms first showed up in section 12.6 of RFC 2630. They got republished because people realised they're useful in situations RFC 2630 didn't really cover 🙈

1. Introduction 🎀

Managing symmetric keys is messy, and it often ends up with one symmetric key encrypting another. Key wrap algorithms usually pop up in two situations 👑. First, key agreement algorithms (like Diffie-Hellman [DH-X9.42]) make a pairwise key-encryption key, and then a key wrap algorithm encrypts the content-encryption key or a multicast key with that pairwise key-encryption key. Second, a key wrap algorithm encrypts the content-encryption key, multicast key, or session key using either a locally generated storage key-encryption key or a key-encryption key that was distributed out-of-band 🔥

This document covers wrapping one Triple-DES key with another [3DES], and wrapping one RC2 key with another RC2 key [RC2]. Triple-DES keys wrapped with Triple-DES use the algorithm in section 3, and RC2 keys wrapped with RC2 use the algorithm in section 4. Both of these rely on the key checksum algorithm in section 2. Triple-DES and RC2 content-encryption keys get encrypted in Cipher Block Chaining (CBC) mode [MODES] 🌈

In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described by Scott Bradner in [STDWORDS]. Those capitals are important, so read them carefully 🫶

2. Key Checksum 🌸

The key checksum is how you get a key integrity check value 🔍. Here's how it works:

  1. Compute a 20 octet SHA-1 [SHA1] message digest on the key that is to be wrapped.
  2. Use the most significant (first) eight octets of the message digest value as the checksum value.

3. Triple-DES Key Wrapping and Unwrapping 💜

This section is all about the algorithms for wrapping and unwrapping one Triple-DES key with another Triple-DES key [3DES] ✨

The same key wrap algorithm works for both Two-key Triple-DES and Three-key Triple-DES keys 🦋. When you wrap a Two-key Triple-DES key, you create a third DES key that has the same value as the first DES key. So all wrapped Triple-DES keys end up with three DES keys. Also, a Two-key Triple-DES key MUST NOT be used to wrap a Three-key Triple-DES key that is made of three unique DES keys. Not me doing that 💀

3.1. Triple-DES Key Wrap 🍓

The Triple-DES key wrap algorithm encrypts a Triple-DES key with a Triple-DES key-encryption key. Here's the step-by-step:

  1. Set odd parity for each of the DES key octets making up the Three-Key Triple-DES key that is to be wrapped, and call the result CEK.
  2. Compute an 8 octet key checksum value on CEK as described above in Section 2, and call the result ICV.
  3. Let CEKICV = CEK || ICV.
  4. Generate 8 octets at random, and call the result IV.
  5. Encrypt CEKICV in CBC mode using the key-encryption key. Use the random value from the previous step as the initialization vector (IV). Call the ciphertext TEMP1.
  6. Let TEMP2 = IV || TEMP1.
  7. Reverse the order of the octets in TEMP2. That means the most significant (first) octet swaps with the least significant (last) octet, and so on. Call the result TEMP3.
  8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use an initialization vector (IV) of 0x4adda22c79e82105. The ciphertext is 40 octets long 🧚

Note: When the same Three-Key Triple-DES key is wrapped in different key-encryption keys, a fresh initialization vector (IV) must be generated for each invocation of the key wrap algorithm. ⭐

3.2. Triple-DES Key Unwrap 🔓

The Triple-DES key unwrap algorithm decrypts a Triple-DES key using a Triple-DES key-encryption key. Here's the unwrap, step by step:

  1. If the wrapped key is not 40 octets, then error.
  2. Decrypt the wrapped key in CBC mode using the key-encryption key. Use an initialization vector (IV) of 0x4adda22c79e82105. Call the output TEMP3.
  3. Reverse the order of the octets in TEMP3. That means the most significant (first) octet swaps with the least significant (last) octet, and so on. Call the result TEMP2.
  4. Decompose TEMP2 into IV and TEMP1. IV is the most significant (first) 8 octets, and TEMP1 is the least significant (last) 32 octets.
  5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use the IV value from the previous step as the initialization vector. Call the ciphertext CEKICV.
  6. Decompose CEKICV into CEK and ICV. CEK is the most significant (first) 24 octets, and ICV is the least significant (last) 8 octets.
  7. Compute an 8 octet key checksum value on CEK as described above in Section 2. If the computed key checksum value does not match the decrypted key checksum value, ICV, then error.
  8. Check each of the DES key octets making up CEK for odd parity. If parity is incorrect, then error.
  9. Use CEK as a Triple-DES key.

3.3. Triple-DES Key Wrap Algorithm Identifier 🏷️

Some security protocols use ASN.1 [X.208-88, X.209-88], and those protocols use algorithm identifiers to name cryptographic algorithms 🎀. To support them, the Triple-DES key wrap algorithm got this algorithm identifier:

id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

The AlgorithmIdentifier parameter field MUST be NULL. 💅

3.4. Triple-DES Key Wrap Example 🌷

This section has a Triple-DES Key Wrap example. The intermediate values that match the named items in section 3.1 are shown in hexadecimal 🔢

CEK:     2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98
KEK:     255e 0d1c 07b6 46df b313 4cc8 43ba 8aa7 1f02 5b7c 0838 251f
ICV:     181b 7e96 86e0 4a4e
CEKICV:  2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98
         181b 7e96 86e0 4a4e
IV:      5dd4 cbfc 96f5 453b
TEMP1:   cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 973b 7a79 60f6
         a44d cc5f 729d 8449
TEMP2:   5dd4 cbfc 96f5 453b cfc1 a789 c675 dd2a b49a 3204 ef92 cc03
         5c1f 973b 7a79 60f6 a44d cc5f 729d 8449
TEMP3:   4984 9d72 5fcc 4da4 f660 797a 3b97 1f5c 03cc 92ef 0432 9ab4
         2add 75c6 89a7 c1cf 3b45 f596 fccb d45d
RESULT:  6901 0761 8ef0 92b3 b48c a179 6b23 4ae9 fa33 ebb4 1596 0403
         7db5 d6a8 4eb3 aac2 768c 6327 75a4 67d4

Part 1 done, bestie 🌈 part 2 is coming with section 4 and the RC2 stuff, so stay tuned 💖

4.4. RC2 Key Wrap Example 🎀

okay bestie, here's a full RC2 Key Wrap example 💖 it walks through every named item from section 4.1, and all the intermediate values are in hexadecimal so you can follow along step by step ✨

CEK:        b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9
KEK:        fd04 fd08 0607 07fb 0003 feff fd02 fe05
LENGTH:     10
LCEK:       10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d9
PAD:        4845 cce7 fd12 50
LCEKPAD:    10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
            d948 45cc e7fd 1250
ICV:        0a6f f19f db40 4988
LCEKPADICV: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
            d948 45cc e7fd 1250 0a6f f19f db40 4988
IV:         c7d9 0059 b29e 97f7
TEMP1:      a01d a259 3793 1260 e48c 55f5 04ce 70b8
            ac8c d79e ffe8 9932 9fa9 8a07 a31f f7a7
TEMP2:      c7d9 0059 b29e 97f7 a01d a259 3793 1260
            e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932
            9fa9 8a07 a31f f7a7
TEMP3:      a7f7 1fa3 078a a99f 3299 8eff 9ed7 8cac
            b870 ce04 f555 8ce4 6012 9337 59a2 1da0
            f797 9eb2 5900 d9c7
RESULT:     70e6 99fb 5701 f783 3330 fb71 e87c 85a4
            20bd c99a f05d 22af 5a0e 48d3 5f31 3898
            6cba afb4 b28d 4f35

5. References 📚

  • [3DES] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
  • [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
  • [DES] American National Standards Institute. ANSI X3.106, "American National Standard for Information Systems - Data Link Encryption". 1983.
  • [DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
  • [DSS] National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
  • [MODES] National Institute of Standards and Technology. FIPS Pub 81: DES Modes of Operation. 2 December 1980.
  • [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
  • [RC2] Rivest, R., "A Description of the RC2 (r) Encryption Algorithm", RFC 2268, March 1998.
  • [SHA1] National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995.
  • [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
  • [X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.

6. Security Considerations 🔐

okay this section is SERIOUS 😭 so read it carefully, bestie 💅

implementations must protect the key-encryption key 🔒 if the key-encryption key gets compromised, every key that was wrapped with it can be disclosed, and that can lead to the disclosure of all traffic protected with those wrapped key 💀

implementations must randomly generate initialization vectors (IVs) and padding 🎲 generating quality random numbers is genuinely hard, so RFC 1750 [RANDOM] is the go-to guidance here, and Appendix 3 of FIPS Pub 186 [DSS] gives one quality PRNG technique 🧠

now the sneaky one 👀 if the key-encryption key and the wrapped key are tied to different symmetric encryption algorithms, the effective security for data encrypted with the wrapped key is set by the weaker of the two algorithms. for example, if data is encrypted with 168-bit Triple-DES and that Triple-DES key is wrapped with a 40-bit RC2 key, then at most 40 bits of protection is provided. a trivial search can find the 40-bit RC2 key, which recovers the Triple-DES key, and then the Triple-DES key can decrypt the content 😱 so implementers must ensure that key-encryption algorithms are as strong or stronger than content-encryption algorithms. no weak links, periodt 💖

the key wrap algorithms in this document were reviewed for use with Triple-DES and RC2, and have not been reviewed for use with other encryption algorithms. similarly, the key wrap algorithms make use of CBC mode [MODES], and they have not been reviewed for use with other cryptographic modes. so don't just plug them into anything and call it a day 🙈

7. Acknowledgments 🫶

this document is the result of contributions from so many professionals ✨ the author appreciates the hard work of all members of the IETF S/MIME Working Group, and gives a special thanks to Carl Ellison, Peter Gutmann, Bob Jueneman, Don Johnson, Burt Kaliski, John Pawling, and Jim Schaad for their support in defining these algorithms and generating this specification 👑

8. Author Address 💌

Russell Housley
RSA Laboratories
918 Spring Knoll Drive
Herndon, VA 20170
USA

EMail: rhousley@rsasecurity.com

Copyright (C) The Internet Society (2001). 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, as long as 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. the only exceptions are when needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it is 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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

funding for the RFC Editor function is currently provided by the Internet Society 🦋

📦 where this page comes from