Matt, I am good with your proposed changes to my proposed changes except perhaps removing / changing the limits on the length of plaintext P. I would like to hear what others on the reflector think the ramifications might be.
---------------------------------------------------------------- Garry -----Original Message----- From: Matt Ball [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 6:12 PM To: Garry McCracken; [EMAIL PROTECTED] Subject: RE: IEEE 1619.1 draft 4 (tape) Comments and feedback Hi Garry, I've got a couple comments for the suggested changes you sent out earlier: > All, below are some comments and feedback on IEEE 1619.1 > draft 4 (tape): > > Encryption blocks need not correspond to media records: > The standard should not constrain the location or technology used for > the encryption. It should support hardware or software based > solutions, > and it should support encryption in the tape drive, in the > application, > or at any point in between. > The standard should not assume that the encryptor even knows about > media-record boundaries, only that it knows about writing to > and reading > from VB-media. In particular, the VB-records handled by the encryptor > may or may not correspond to physical media-records. > Propose that "media-records" be referred to as just "records" > throughout. I agree. I've changed all instances of 'media record' to 'record'. Furthermore, it makes sense to not refer to a 'VB-Drive', but rather a 'VB-Device'. In this context, a device is any combination of software, firmware, or hardware that supports the 1619.1 standard. I believe T10 uses the term 'device server' instead of 'drive' for a similar reason. > 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.) > 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) > 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. > Nonce requirement for counter modes causes implementation > complexities: > The counter mode requirement for a guaranteed unique nonce seems to be > leading to an ever-increasing complexity to avoid repeated nonces. > Perhaps the standard should allow for an authenticated mode based on a > different underlying block cipher, such as LRW augmented with > the Galois > authentication used in GCM (GLRW). A GLRW like mode would also allow > for more efficient implementations at the application. I believe that a 'GLRW' mode would be more complex that the existing GCM mode. By taking a little care with IV management, it should be possible to sufficiently close that particular hole. > Authenticate-Only should be optional: > The Authenticate-Only Mode should be optional. > Implementations need not > support it to be compliant. > Propose that section 2 be modified to state: "Support of > Authenticate-Only mode is not required to comply with this standard." Agreed. I'll update the document to reflect this. > Not about interoperability: > The standard is not about interoperability, and should simply avoid > preventing it. That is, it should be possible for vendors to cooperate > to create interoperable solutions that are IEEE 1619.1 compliant but > this is outside the scope of the standard. > Propose that the statement "(and to a lesser extent interoperability)" > be removed from section 1.1 Statement removed > Typos: > There are a few places in the document where there are typos > or missing > words: > - On page 1, isn't it "AAD - Additional Authenticated Data" (not > Additionally) > - On page 3, under "Interoperability", there is a word missing > between multiple" what? Vendors? Implementations? Drives? > - On page 5, first paragraph, the web-page is "at the Computer > ...", not "as the ..." Changes made. Thanks, -Matt
