(Doug Whiting, there's a CCM question for you below...)
Hi Jim,
See comments below:
> >> Propose that bullet 3 in section 3.1 be reworded to: 3.1
> "Plaintext P
> >> shall have a length from 1 to 2^24"
> >
> > It might be better to not impose any limit, but rather let the
> > particular
> > application define a limit. 16 MB is a customary limit in SCSI tape
> > drives, but we don't necessarily need to specify this limit
> in 1619.1.
> > I believe the CCM spec limits the plaintext to at most 2^64 bytes.
> > We should probably change the upper limit to 2^64. A particular
> > implementation may impose other limits, as appropriate.
> > (If we allow 'authenticate-only', we'd also have to allow for zero
> > bytes
> > of plaintext.)
>
> This impacts the nonce size. going to an upper limit of 2^64 reduces
> the usable nonce length from 12 bytes to 7. A pretty dramatic change.
Oops, I read through the CCM spec and 1619.1 draft too fast! I
mistakenly thought the 2^24 number referred to the maximum SCSI record
size, when in fact it is the limit imposed by the CCM spec based on
the choice of L=3. However, in looking at CCM closer, it's not quite
clear what the real limit is.
The CCM spec gives the following limit in section 1.2 (Inputs):
The message m, consisting of a string of l(m) octets where
0 <= l(m) < 2^8L. The length restriction ensures that l(m)
can be encoded in a field of L octets.
Therefore, the CCM spec imposes the limit that the plaintext contain
between 0 and (2^24)-1 bytes, with L=3.
However, in looking further into the CCM spec, it appears that the
real limit is (2^24)-1 blocks, which equals 2^28 - 16 bytes.
(See section 1.4 - Encryption)
Doug Whiting, could you shed some light on the real limits for
the plaintext in CCM? Am I reading the spec. correctly?
> >> Propose that bullet 3 in section 4.1 be reworded to: 4.1
> "Plaintext P
> >> shall have a length from 1 to 2^36-32 bytes".
> >
> > I removed the 'record' language from this statement.
> > (Again, if we're supported 'authenticate-only', we need to support
> > zero
> > bytes of plaintext. I'll change that)
>
> Really... Didn't know that a 0 length record is possible.
A zero length plaintext is possible when running in authenticate-only.
In this case, there is not plaintext and all the data becomes AAD.
It's really more of a point of semantics. If it makes more sense,
I could clarify this point in the document.
> >> Propose to strike "the third bullet above shall not
> encrypt a partial
> >> media record with a separate IV and authentication tag, and" from
> >> section 3.1. Propose to strike "the last bullet above shall
> >> not encrypt
> >> a partial media record with a separate IV and authentication tag,
> >> and"
> >> from section 4.1.
> >
> > I think it still makes sense to prevent encrypting partial records.
> > We just have to make it clear that the records we're
> referring to are
> > not necessarily media records.
>
> I really don't understand this.
The main problem here is a matter of terminology. Using the term
'record' is probably a poor choice for describing the 'basic
encryption unit' because people think of 'media records'. The
two units should generally equate but this isn't necessary.
Maybe we could change the document to use a different term like
'Authenticated Block'.
Let me try an example. Take for instance the LTO-1 format, as
specified in ECMA-319. An LTO-1 tape drive will take a group of
host records, compress them, then place the compressed data into
a 'Data Set'. Each Data Set is then written to tape as a single
unit. In this architecture, a perfectly legitimate implementation
would be to encrypt on a Data Set basis instead of a Record
basis. Since the LTO-1 tape drive already needs to decompress a
Data Set as a group, why not decrypt it as well? In this
implementation, the basic encryption unit would be the 'data set',
and it would then be the responsibility of higher-level processing
to reassemble the decrypted and decompressed records.
-Matt
