Thanks Shai for your feedback See comments intermixed below:
> In terms of the algorithms I have only a few comments: > > * Is the restriction to 2^24-byte plaintext in Table 1 comes the CCM > spec or is it something that we added in 1619.1? In the latter case, > do we really want to be so restrictive? Please see the e-mail discussion between Doug Whiting and me at this link: <http://grouper.ieee.org/groups/1619/email/msg00746.html>. The conclusion was that according to the CCM spec, the maximum plaintext size is 2^24-1 bytes, given that we have fixed L=3. (I think the real limit is 2^24-1 _blocks_ (which equals 2^28-16 bytes), but the CCM spec didn't allow this (for a currently unknown reason)). Unless we want to update the CCM spec, or use a different 'L' value, we need to keep the CCM plaintext limit to 2^24-1 bytes. > * Do we want to limit the FormatSpecific data in eqn (2) (cf. 6.2.2) > to 127 bits? This will ensure that the whole thing fits in > one 512-bit > block (even after the padding that is specified in FIPS 180-2). > > If we do not limit it to 127 bits, then I suggest that we use a > different format that ensures that the user-key is included in > its entirety in the last 512-block of the input. Something like > > deviceKey = SHA256(1|256|OUI|FormatSpecific|UserKey) > > where the length of padded-FormatSpecific must be equal to > 127 modulo 512 > (i.e., 127 bite or 127+512 bits, etc.) I like this general approach. This would limit the entropy-loss problem. To keep things a little simpler, I'd like to use bytes instead of bits for representing the sizes. Furthermore, aligning all elements to 32-bit words would help many implementations to increase their performance, suggesting that we should use multiples of 4 bytes. How about this proposal?: DeviceKey = SHA256(1|256|OUI|FormatSpecific|Key) (as outlined above) where FormatSpecific is VB-device-defined data whose length shall be congruent to 8 bytes, modulo 32 bytes. The data shall be left-justified, and all unused bytes shall be zero-filled. (Examples of valid FormatSpecific lengths: 8, 40, 72, 104, etc) This format will create exactly 31 bits of pad at the end of the last 32-byte hash-block. The key will then be aligned to a nice 32-bit boundary. > * When using the procedure in 6.3, do we want to say that in this case > a single key should not be used for more than (say) 2^40 bytes of > storage? I gave this some thought when writing the draft. I even had extra columns in Table 1 that included the Clause 6.3 algorithm. However, in the end, the limits imposed by GCM and CCM were more restrictive than any imposed by a random IV. CCM limits the plaintext to 2^24-1 bytes, and GCM limits it to 2^36-32 bytes. If the random IV contains 96 bits of entropy, the birthday limit would be at about 2^48 records. Even if each record contains 1 byte, the limit would be 2^48 bytes. However, this is much higher than the limit of 2^36-32 bytes imposed by GCM. > I have many "small editorial comments", but main ones are these: > > * The normative text should only have the "things to do" and not the > "why we need them". (In particular, most/all discussions of the > security considerations should be moved to the informative parts.) I agree wholeheartedly. This was my first pass at trying to take the workgroups notes and put it into a format compatible with an IEEE standard. There are quite a few sections I wouldn't mind either moving down into an informative appendix or removing altogether. If there are any specific changes, please let me know. > * All mention of entropy and probabilities should be removed from the > normative part. These notions have concrete mathematical meanings > that are very unlikely to be attained by any real implementation. > (And do we really want to specify what is the probability space > over which these are defined?) Instead of requiring that something > "has high entropy" we should say that it is derived from a > "cryptographically strong pseudo-random source". That's a fair comment. I agree that it is very hard to enforce that an IV contain 96 bits of entropy. I'll look into rewording this. If you have any other particular suggestions, let me know. -Matt
