RFC 3058

Use of the IDEA Encryption Algorithm in CMS

📅 published February 2001, from ietf

RFC 3058 🎀 Use of the IDEA Encryption Algorithm in CMS

okay bestie, the paperwork first 📋✨ This is RFC 3058, Use of the IDEA Encryption Algorithm in CMS, from the Network Working Group, dated February 2001. It was written by S. Teiwes and P. Hartmann from iT_Security AG (Ltd.), and D. Kuenzi from 724 Solutions Inc. Its category is Informational. The title block doesn't list anything it obsoletes or updates, so it's just doing its own thing 💅

Status of This Memo

so this memo is here to inform the Internet community 🦋 It doesn't specify an Internet standard of any kind, so it's not a rulebook, and it can be shared with anyone with no limits 🌸

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

Abstract ✨

this memo explains how to bring the International Data Encryption Algorithm (IDEA) into CMS or S/MIME as another strong option for symmetric encryption 🔐 Organizations that already rely on IDEA for their data security are obsessed with the idea of having it in S/MIME too, so this memo gives the OIDs and algorithms needed to use IDEA in S/MIME for symmetric content and key encryption 💖

1. Introduction ✨

bestie, so this memo is the how-to for adding IDEA [IDEA] to CMS or S/MIME [SMIME2, SMIME3] as an extra strong symmetric encryption algorithm 🧚 Orgs that use IDEA for data security really want it inside S/MIME, and this memo is what makes that happen by giving the OIDs and algorithms needed for both symmetric content and key encryption 🫶

The official S/MIME OIDs are the thing that spells out what S/MIME can do and what it prefers 📜 You can find the registered list at http://www.imc.org/ietf-smime/oids.html. A client's supported S/MIME functions are shown by the S/MIME capabilities attribute, which is basically a list of OIDs for the crypto functions it supports 💅

quick note on the wording: in this document, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT are written in capitals, and that follows the definitions in [MUSTSHOULD] 🙈

2. Object Identifier for Content and Key Encryption ✨

okay so CMS [CMS] comes from PKCS#7 [PKCS7], and it's the framework for doing crypto in S/MIME 🔥 It lays out the data formats and encryption steps without naming any specific algorithms. Every algorithm used for encryption must get its own unique algorithm identifier. For content encryption, the ContentEncryptionAlgorithmIdentifier tells you which algorithm to use. Per [CMS], any symmetric algorithm a CMS implementation includes as a content-encryption algorithm also has to be included as a key-encryption algorithm 🌸

IDEA joins the optional symmetric encryption algorithms in S/MIME with two unique OIDs 🎀 One is for content encryption and the other is for key encryption. So an S/MIME agent can use IDEA for either job just by picking the right OID, supplying the required parameter, and starting the program code 💖

For content encryption, the recommended choice is IDEA in cipher block chaining (CBC) mode, and the key length is fixed at 128 bits 🌈

The IDEA content-encryption algorithm in CBC mode has this OID:

  IDEA-CBC OBJECT IDENTIFIER
    ::= { iso(1) identified-organization(3)
        usdod(6) oid(1) private(4) enterprises(1)
        ascom(188) systec(7) security(1) algorithms(1) 2 }

The identifier's parameters field can hold an optional initialization vector (IV) 🧸

  IDEA-CBCPar ::= SEQUENCE {
    iv  OCTET STRING OPTIONAL } -- exactly 8 octets

If an IV is specified like that, it MUST be used as the initial vector. In that case, the ciphertext MUST NOT include the initial vector 🙅‍♀️ If no IV is specified, the first 64 bits of the ciphertext MUST be treated as the initial vector. But leaving the IV out of the "iv OCTET STRING" of IDEA-CBCPar SHOULD NOT be used in CMS or S/MIME, so please don't do that, bestie 🫣

Next, the key-wrap and unwrap algorithms for encrypting and decrypting an IDEA content-encryption key with an IDEA key-encryption key are in the next section. Generating and distributing the IDEA key-encryption keys is outside the scope of this document 🦋

The IDEA key-encryption algorithm has this OID:

  id-alg-CMSIDEAwrap OBJECT IDENTIFIER
    ::= { iso(1) identified-organization(3)
        usdod(6) oid(1) private(4) enterprises(1)
        ascom(188) systec(7) security(1) algorithms(1) 6 }

The identifier's parameters field MUST be NULL 💅

3. Key-Wrapping and Unwrapping ✨

the IDEA key-wrap and key-unwrap algorithms in this section follow [CMS], section 12.3 🎀

3.1 IDEA Key Wrap

the IDEA key-wrap algorithm takes an IDEA content-encryption key and encrypts it with an IDEA key-encryption key 🔐 Here's how it works:

  1. Let the content-encryption key (16 octets) be called CEK
  2. Compute an 8 octet key checksum value on CEK as described in [CMS], section 12.6.1, and call the result ICV.
  3. Let CEKICV := CEK || ICV.
  4. Generate 8 octets at random, and call the result IV.
  5. Encrypt CEKICV using IDEA in CBC mode and 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 using IDEA in CBC mode and the key-encryption key. Use an initialization vector (IV) of 0x4adda22c79e82105. The ciphertext is 32 octets long 🌸

3.2 IDEA Key Unwrap

the IDEA key-unwrap algorithm decrypts an IDEA content-encryption key using an IDEA key-encryption key 🧚 Here's the flow:

  1. If the wrapped content-encryption key is not 32 octets, then error.
  2. Decrypt the wrapped content-encryption key using IDEA in CBC mode with the key-encryption key. Use an initialization vector (IV) of 0x4adda22c79e82105. Call the output TEMP3.
  3. Reverse the order of the octets in TEMP3. The most significant (first) octet swaps with the least significant (last) octet, and so on. Call the result TEMP2.
  4. Split TEMP2 into IV and TEMP1. IV is the most significant (first) 8 octets, and TEMP1 is the remaining (last) 24 octets.
  5. Decrypt TEMP1 using IDEA in CBC mode with the key-encryption key. Use the IV value from the previous step as the initialization vector. Call the plaintext CEKICV.
  6. Split CEKICV into CEK and ICV. CEK is the most significant (first) 16 octets, and ICV is the least significant (last) 8 octets.
  7. Compute an 8 octet key checksum value on CEK as described in [CMS], section 12.6.1. If the computed key checksum value does not match the decrypted key checksum value, ICV, then error.
  8. Use CEK as the content-encryption key 💖

4. SMIMECapabilities Attribute ✨

an S/MIME client announces which crypto functions it supports using the S/MIME capabilities attribute from [SMIME3] 📣 This attribute is a partial list of crypto OIDs and it must be signed by the client 🫶 These OIDs should be sorted into functional categories, and they MUST be ordered by preference. If an S/MIME client has to support symmetric encryption and key wrapping with IDEA, the capabilities attribute MUST contain the OIDs above in the symmetric algorithms and key encipherment algorithms categories. IDEA doesn't need extra OID parameters because its key length is fixed at 128 bits 🌈

The SMIMECapability SEQUENCE for the IDEA symmetric encryption algorithm MUST include the IDEA-CBC OID in the capabilityID field, and the parameters field MUST be absent. This SEQUENCE SHOULD be included in the symmetric encryption algorithms part of the SMIMECapabilities list. It MUST be DER-encoded like this:

300D 060B 2B06 0104 0181 3C07 0101 02

The SMIMECapability SEQUENCE for IDEA key wrapping MUST include the id-alg-CMSIDEAwrap OID in the capabilityID field, and the parameters field of KeyWrapAlgorithm MUST be absent. This SEQUENCE SHOULD be included in the key encipherment algorithms part of the SMIMECapabilities list. It MUST be DER-encoded like this:

300D 060B 2B06 0104 0181 3C07 0101 06

the ASN.1 notation for the SMIMECapability SEQUENCE representing IDEA is:

   SMIMECapability ::= SEQUENCE {
      capabilityID OBJECT IDENTIFIER,
      parameters ANY DEFINED BY capabilityID OPTIONAL }

where capabilityID is IDEA-CBC (no parameters) for IDEA content encryption in CBC mode, or capabilityID is id-alg-CMSIDEAwrap (no parameters) for IDEA key wrapping 🧸

5. Activation of IDEA in S/MIME Clients ✨

okay so when a sending agent makes an encrypted message, it has to pick which encryption algorithm to use 🤔 Usually that choice depends on the capabilities lists from the recipient's messages, plus other stuff like private agreements, user preferences, legal restrictions, and so on. If users want IDEA for symmetric encryption, then IDEA has to be supported by the S/MIME clients on both the sending and receiving sides, and it has to be turned on in the user preferences 💅🌸

A. References 📚

Okay bestie, here's the reading list 🤓 Every citation is exactly as written, so you can look them all up:

  • [IDEA] X. Lai, "On the design and security of block ciphers", ETH Series in Information Processing, J.L. Massey (editor), vol. 1, Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992. A. J. Menezes, P.C. v. Oorschot, S.A. Vanstone, "Handbook of Applied Cryptography," CRC Press New York, 1997, p. 265. B. Schneier, "Applied Cryptography," 2nd ed., John Wiley & Sons Inc. New York, 1996, pp. 319-325. IPR: see the "IETF Page of Intellectual Property Rights Notices", http://www.ietf.org/ipr.html
  • [SMIME2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, l. and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
  • [SMIME2] Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein, "S/MIME Version 2 Certificate Handling", RFC 2312, March 1998.
  • [SMIME3] Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein, "S/MIME Version 3 Certificate Handling", RFC 2632, March 1998.
  • [SMIME3] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
  • [MUSTSHOULD] Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
  • [PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.

B. Comments on IDEA Security and Standards 🔐

The IDEA algorithm came out of a joint project between the Swiss Federal Institute of Technology in Zurich (Dr. X. Lai and Prof. J.L. Massey) and Ascom Ltd. The whole point was to build a strong encryption algorithm that could replace DES. Iconic goal, honestly 💅

IDEA uses 128-bit secret keys and encrypts one 64-bit block at a time [IDEA]. It was specifically strengthened to protect against differential cryptoanalysis attacks 🛡️ For the full 8-round IDEA, there's no known attack that beats exhaustive search over the total 128-bit key space. So basically, you'd have to try every single key 💀

IDEA also works for standard Electronic Data Interchange applications. It's been entered in the ISO/IEC register for encryption algorithms, and the "SECURITY GUIDE LINES" code list of the UNI/EDIFACT "SECURITY JOINT WORKING GROUP" includes it too ✨

C. Intellectual Property Rights Notice ⚖️

Ascom Ltd. holds the patent to IDEA. Following the intellectual property rights procedures of the IETF standards process, Ascom offers a non-exclusive license under reasonable and non-discriminatory terms and conditions.

IDEA(TM) is protected by international copyright law, and it's also been patented in several countries. Because Ascom wants this highly secure algorithm to be widely available, non-commercial use of it is free 🎀

If you want to know more about IDEA or request a license, check out the web sites <http://www.media-crypt.com/> and <http://www.it-sec.com/>, or send an e-mail to info@media-crypt.com or Idea@it-sec.com 💌

D. Acknowledgements 🫶

Huge shoutout to Russ Housley, Jim Schaad and Francois Zeller for their contributions to this document 🌸

E. Authors' Addresses 🗺️

Here are the authors' contact details, copied exactly:

Stephan Teiwes
iT_Security AG (Ltd.)
Badenerstrasse 530
CH-8048 Zurich, Switzerland

Phone: +41 1 404 8200
Fax  : +41 1 404 8201
EMail: stephan.teiwes@it-sec.com


Peter Hartmann
iT_Security AG (Ltd.)
Badenerstrasse 530
CH-8048 Zurich, Switzerland

Phone: +41 1 404 8200
Fax  : +41 1 404 8201
EMail: peter.hartmann@it-sec.com


Diego Kuenzi
724 Solutions Inc.
Bahnhofstrasse 16
CH-5600 Lenzburg, Switzerland

Phone: +41 62 888 3070
Fax:   +41 62 888 3071
EMail: dkuenzi@724.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, 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 "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