--- 1/draft-ietf-smime-cms-aes-ccm-and-gcm-02.txt 2007-09-21 19:12:11.000000000 +0200 +++ 2/draft-ietf-smime-cms-aes-ccm-and-gcm-03.txt 2007-09-21 19:12:11.000000000 +0200 @@ -1,16 +1,18 @@ INTERNET DRAFT R. Housley S/MIME Working Group Vigil Security +Expires March 2008 September 2007 + Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) - + Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -284,31 +286,33 @@ Unfortunately, it is easy to misuse counter mode. If counter block values are ever used for more that one encryption operation with the same key, then the same key stream will be used to encrypt both plaintexts, and the confidentiality guarantees are voided. Fortunately, the CMS AuthEnvelopedData provides all of the tools needed to avoid misuse of counter mode. Automated key management is discussed in Section 2. - There are fairly generic precomputation attacks against all block - cipher modes that allow a meet-in-the-middle attack against the key. - These attacks require the creation and searching of huge tables of - ciphertext associated with known plaintext and known keys. Assuming - that the memory and processor resources are available for a - precomputation attack, then the theoretical strength of any block - cipher mode is limited to 2^(n/2) bits, where n is the number of bits - in the key. The use of long keys is the best countermeasure to - precomputation attacks. Use of an unpredictable nonce value in the - counter block significantly increases the size of the table that the - attacker must compute to mount a successful precomputation attack. + There are fairly generic precomputation attacks against the use of + any block cipher in counter mode that allow a meet-in-the-middle + attack against the key [H][B][MF]. AES-CCM and AES-GCM both make use + of counter mode for encryption. These precomputation attacks require + the creation and searching of huge tables of ciphertext associated + with known plaintext and known keys. Assuming that the memory and + processor resources are available for a precomputation attack, then + the theoretical strength of any block cipher in counter mode is + limited to 2^(n/2) bits, where n is the number of bits in the key. + The use of long keys is the best countermeasure to precomputation + attacks. Use of an unpredictable nonce value in the counter block + significantly increases the size of the table that the attacker must + compute to mount a successful precomputation attack. Implementations must randomly generate content-authenticated- encryption keys. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area. @@ -329,30 +333,44 @@ [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation (GCM)", Submission to NIST, May 2005. http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ gcm/gcm-revised-spec.pdf. [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. Informative References + [B] Biham, E., "How to Forge DES-Encrypted Messages in + 2^28 Steps", Technion Computer Science Department + Technical Report CS0884, 1996. + [BDJR] Bellare, M, Desai, A., Jokipii, E., and P. Rogaway, "A Concrete Security Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation", Proceedings 38th Annual Symposium on Foundations of Computer Science, 1997. + [H] Hellman, M. E., "A cryptanalytic time-memory trade-off", + IEEE Transactions on Information Theory, July 1980, + pp. 401-406. + [KEYMGMT] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", RFC 4107, BCP 107, June 2005. + [MF] McGrew, D., and S. Fluhrer, "Attacks on Additive + Encryption of Redundant Plaintext and Implications on + Internet Security", The Proceedings of the Seventh + Annual Workshop on Selected Areas in Cryptography + (SAC 2000), Springer-Verlag, August, 2000. + [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Recommendations for Security", RFC 4086, June 2005. 6. IANA Considerations None. {{{ RFC Editor: Please remove this section prior to publication. }}} Appendix: ASN.1 Module @@ -399,21 +417,21 @@ END Authors' Addresses Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA - EMail: housley(at)vigilsec.com + EMail: housley@vigilsec.com Copyright and IPR Statements Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and translations of it may be copied and furnished to