< draft-housley-ccm-mode-00.txt   draft-housley-ccm-mode-01.txt >
Internet Engineering Task Force D. Whiting Internet Engineering Task Force D. Whiting
Internet-Draft Hifn Internet-Draft Hifn
Expires: January 2003 R. Housley Expires: March 2003 R. Housley
RSA Laboratories RSA Laboratories
N. Ferguson N. Ferguson
MacFergus MacFergus
Counter with CBC-MAC (CCM) Counter with CBC-MAC (CCM)
<draft-housley-ccm-mode-00.txt> <draft-housley-ccm-mode-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 3, line 46 skipping to change at page 3, line 46
Within the first block B_0, the Flags field is formatted as follows: Within the first block B_0, the Flags field is formatted as follows:
Bit Number Contents Bit Number Contents
---------- ---------------------- ---------- ----------------------
7 Reserved (always zero) 7 Reserved (always zero)
6 Adata 6 Adata
5 ... 3 M 5 ... 3 M
2 ... 0 L 2 ... 0 L
Another way say the same thing is: Flags = 64*Adata + 8*M + L.
The Reserved bit is reserved for future expansions and should always The Reserved bit is reserved for future expansions and should always
be set to zero. The Adata bit is set to zero if l(a)=0, and set to be set to zero. The Adata bit is set to zero if l(a)=0, and set to
one if l(a)>0. The M field encodes the value of M as (M-2)/2. As M one if l(a)>0. The M field encodes the value of M as (M-2)/2. As M
can take on the even values from 4 to 16, the 3-bit field can take on can take on the even values from 4 to 16, the 3-bit field can take on
the values from 1 to 7. The L field encodes the size of the length the values from one to seven. The 3-bit field MUST NOT have a value
field used to store l(m). The parameter L can take on the values of zero, which would correspond to a 16-bit integrity check value.
from 2 to 8 (recall, the value L=1 is reserved). This value is The L field encodes the size of the length field used to store l(m).
encoded in the 3-bit field using the values from 1 to 7 by choosing The parameter L can take on the values from 2 to 8 (recall, the value
the field value as L-1 (the zero value is reserved). L=1 is reserved). This value is encoded in the 3-bit field using the
values from one to seven by choosing the field value as L-1 (the zero
value is reserved).
If l(a)>0 (as indicated by the Adata field), then one or more blocks If l(a)>0 (as indicated by the Adata field), then one or more blocks
of authentication data are added. These blocks contain l(a) and a of authentication data are added. These blocks contain l(a) and a
encoded in a reversible manner. We first construct a string that encoded in a reversible manner. We first construct a string that
encodes l(a). encodes l(a).
If 0 < l(a) < (2^16 - 2^8), then the length field is encoded as two If 0 < l(a) < (2^16 - 2^8), then the length field is encoded as two
octets which contain the value l(a) in most-significant-byte first octets which contain the value l(a) in most-significant-byte first
order. order.
skipping to change at page 5, line 37 skipping to change at page 5, line 41
The Flags field is formatted as follows: The Flags field is formatted as follows:
Bit Number Contents Bit Number Contents
---------- ---------------------- ---------- ----------------------
7 Reserved (always zero) 7 Reserved (always zero)
6 Reserved (always zero) 6 Reserved (always zero)
5 ... 3 Zero 5 ... 3 Zero
2 ... 0 L 2 ... 0 L
Another way say the same thing is: Flags = L.
The Reserved bits are reserved for future expansions and MUST be set The Reserved bits are reserved for future expansions and MUST be set
to zero. Bit 6 corresponds to the Adata bit in the B_0 block, but as to zero. Bit 6 corresponds to the Adata bit in the B_0 block, but as
this bit is not used here, it is reserved and MUST be set to zero. this bit is not used here, it is reserved and MUST be set to zero.
Bits 3, 4, and 5 are also set to zero, ensuring that all the A blocks Bits 3, 4, and 5 are also set to zero, ensuring that all the A blocks
are distinct from B_0, which has the non-zero encoding of M in this are distinct from B_0, which has the non-zero encoding of M in this
position. Bits 0, 1, and 2 contain L, using the same encoding as in position. Bits 0, 1, and 2 contain L, using the same encoding as in
B_0. B_0.
The message is encrypted by XORing the octets of message m with the The message is encrypted by XORing the octets of message m with the
first l(m) octets of the concatenation of S_1, S_2, S_3, ... . Note first l(m) octets of the concatenation of S_1, S_2, S_3, ... . Note
that S_0 is not used to encrypt the message. that S_0 is not used to encrypt the message.
The authentication value U is computed by encrypting T with the key The authentication value U is computed by encrypting T with the key
stream block S_0 and truncating it to the desired length. stream block S_0 and truncating it to the desired length.
U := T XOR first-M-bytes( S_0 ) U := T XOR first-M-bytes( S_0 )
2.4. Output 2.4. Output
The final result c consists of the encrypted message m, followed by The final result c consists of the encrypted message followed by the
the encrypted authentication value U. encrypted authentication value U.
2.5. Decryption and Authentication Checking 2.5. Decryption and Authentication Checking
To decrypt a message the following information is required: To decrypt a message the following information is required:
1. The encryption key K. 1. The encryption key K.
2. The nonce N. 2. The nonce N.
3. The additional authenticated data a. 3. The additional authenticated data a.
skipping to change at page 6, line 39 skipping to change at page 7, line 39
authentication data is then used to recompute the CBC-MAC value and authentication data is then used to recompute the CBC-MAC value and
check T. check T.
If the T value is not correct, the receiver MUST NOT reveal any If the T value is not correct, the receiver MUST NOT reveal any
information except for the fact that T is incorrect. The receiver information except for the fact that T is incorrect. The receiver
MUST NOT reveal the decrypted message, the value T, or any other MUST NOT reveal the decrypted message, the value T, or any other
information. information.
2.6. Restrictions 2.6. Restrictions
All implementations MUST limit the total amount of data that is To preserve security, implementations need to limit the total amount
encrypted with a single key. The sender MUST ensure that the total of data that is encrypted with a single key; the total number of
number of block cipher encryption operations in the CBC-MAC and block cipher encryption operations in the CBC-MAC and encryption
encryption together does not exceed 2^61. (This allows nearly 2^64 together cannot exceed 2^61. (This allows nearly 2^64 octets to be
octets to be encrypted and authenticated using CCM, which should be encrypted and authenticated using CCM. This is roughly 16 million
more than enough for most applications.) Receivers that do not terabytes, which should be more than enough for most applications.)
expect to decrypt the same message twice MAY also check this limit. In an environment where this limit might be reached, the sender MUST
ensure that the total number of block cipher encryption operations in
the CBC-MAC and encryption together does not exceed 2^61. Receivers
that do not expect to decrypt the same message twice MAY also check
this limit.
The recipient MUST verify the CBC-MAC before releasing any The recipient MUST verify the CBC-MAC before releasing any
information such as the plaintext. If the CBC-MAC verification information such as the plaintext. If the CBC-MAC verification
fails, the receiver MUST destroy all information, except for the fact fails, the receiver MUST destroy all information, except for the fact
that the CBC-MAC verification failed. that the CBC-MAC verification failed.
3. Security Proof 3. Security Proof
Jakob Jonsson from RSA Laboratories has developed a security proof of Jakob Jonsson has developed a security proof of CCM [PROOF]. The
CCM. The resulting paper will be published in the proceedings of the resulting paper was presented at the SAC 2002 conference. The proof
SAC '02 conference, so it will be available to everyone very soon. shows that CCM provides a level of confidentiality and authenticity
The proof shows that CCM provides a level of confidentiality and that is in line with other proposed authenticated encryption modes,
authenticity that is in line with other proposed authenticated such as OCB mode [OCB].
encryption modes, such as OCB mode [OCB].
4. Rationale 4. Rationale
The main difficulty in specifying this mode is the trade-off between The main difficulty in specifying this mode is the trade-off between
nonce size and counter size. For a general mode we want to support nonce size and counter size. For a general mode we want to support
large messages. Some applications use only small messages, but would large messages. Some applications use only small messages, but would
rather have a larger nonce. Introducing the L parameter solves this rather have a larger nonce. Introducing the L parameter solves this
issue. The parameter M gives the traditional trade-off between issue. The parameter M gives the traditional trade-off between
message expansion and probability of forgery. For most applications, message expansion and probability of forgery. For most applications,
we recommend choosing M at least 8. we recommend choosing M at least 8.
skipping to change at page 36, line 18 skipping to change at page 38, line 18
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes [MODES] Dworkin, M., "Recommendation for Block Cipher Modes
of Operation: Methods and Techniques," NIST Special of Operation: Methods and Techniques," NIST Special
Publication 800-38A, December 2001. Publication 800-38A, December 2001.
[OCB] Rogaway, P., Bellare, M., Black, J. and T, Krovetz, [OCB] Rogaway, P., Bellare, M., Black, J. and T, Krovetz,
"OCB: A block-Cipher Mod of Operation for Efficient "OCB: A block-Cipher Mod of Operation for Efficient
Authenticated Encryption," 8th ACM Conference on Authenticated Encryption," 8th ACM Conference on
Computer and Communications Security, pp 196-295, Computer and Communications Security, pp 196-295,
ACM Press, 2001. ACM Press, 2001.
[PROOF] Jonsson, J., "On the Security of CTR + CBC-MAC,"
SAC 2002 -- Ninth Annual Workshop on Selected Areas
of Cryptography, Workshop Record version, 2002.
Final version to appear in the LNCS Proceedings.
12. Author's Address 12. Author's Address
Doug Whiting Doug Whiting
Hifn Hifn
5973 Avenida Encinas, #110 5973 Avenida Encinas, #110
Carlsbad, CA 92009 Carlsbad, CA 92009
USA USA
DWhiting@hifn.com DWhiting@hifn.com
Russell Housley Russell Housley
 End of changes. 9 change blocks. 
22 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/