Thanks Doug!
I can see part of my confusion now. I was looking at the CCM proposal
that you had written with Russ Housley and Niels Ferguson:
<http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ccm/ccm.pdf>
Since we're actually using SP800-38C, I'm now looking at the correct version:
<http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf>
However, it looks like Morris Dworkin may have carried this ambiguity
through to the NIST version. In looking at the length requirements of
the plaintext, I found the following text in section A.1 (Length Requirements)
on page 18:
The parameter q determines the maximum length of the payload: by
definition, p < 2^8q, so P consists of fewer than 2^8q octets,
i.e.,
fewer than 2^(8q-4) 128-bit blocks. The fourth condition implies
that a choice for q determines the value of n, namely, n=15-q.
(Equivalently, the nonce length, n, may be considered as the
parameter of the formatting function that determines the value of
q.) The value of n, in turn, determines the maximum number of
distinct nonces, namely, 2^8n. Thus, the fourth condition amounts
to a tradeoff between the maximum number of invocations of CCM
under a given key and the maximum payload length for those invocations.
For our given implementation, I'm assuming that we're using q = 3, which
provides 12 bytes for the nonce and 3 bytes for the block counter.
According to the above text, the maximum allowed plaintext should be
2^(8q) octets, which is 2^(8*3) = 2^24 octets = 2^20 128-bit blocks.
However, a 3 byte counter allows for a full 2^24 blocks, which equals
2^28 bytes. Which limitation must we obey: the limits imposed by section
A.1, or the limits of a 3-byte counter value?
I guess in reality, a limit of 2^24-1 bytes should be sufficient. I just
wanted to clarify the issue since Garry had recommended we allow 2^24 bytes
of plaintext in CCM mode. Depending on the interpretation, 2^24 bytes
may not be allowed.
Thanks!
-Matt
> -----Original Message-----
> From: Doug Whiting [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 08, 2006 5:14 PM
> To: Matt Ball; james hughes
> Cc: Garry McCracken; [EMAIL PROTECTED]
> Subject: RE: IEEE 1619.1 draft 4 (tape) Comments and feedback
>
>
> I'm not sure exactly which CCM doc you're referring to, as
> your section
> numbers don't match the NIST doc or the P1619.1 doc or RFC3610. Having
> said that, I think that I understand your question and can explain it.
>
> CCM uses a single AES block as the first block (B0) of its CBC-MAC
> computation. This block includes a flag byte, plus the length
> count. The
> length count occupies L bytes, where currently L=3 for the
> P1619.1 draft
> (in 802.11, by contrast, L=2, so the length requirements are obviously
> application-dependent). The flag byte includes a 3-bit field
> to specify
> L. The fact that the length field is included in B0 is used
> extensively
> in the security proof of CCM. We made L a variable precisely
> so that it
> can vary from application to application (e.g., 802.11 and P1619.1).
>
> The rest of B0 is the nonce. So, there are 15-L bytes of nonce. With
> L=3, that gives us 12 bytes of nonce, or 96 bits. If we need longer
> blocks than 2^28 bytes (2^24 blocks), then we'd need to go to
> L=4, which
> would decrease the nonce size to 88 bits. Similarly, if we could live
> with blocks of up about to 1MB, then we could use L=2 and
> have 104 bits
> of nonce. Seems to me that, for this application, L=3 is
> probably about
> right.
>
> Does this help?
[Previous Message Deleted]
