Below is a retransmission of my comments on draft 4 of P1619.1 on Jan
13.
Since I sent the original message Matt Ball has been tasked to draft a
specification for ensuring uniqueness of IVs between vendors and a
different mode of operation where encryption and authentication keys are
separated has been discussed. These may address my more general
concerns from Jan 13.
However, the specific proposed text change changes and typo fixes still
stand. I would like to bring these to the attention of the editor of
the next IEEE 1619.1 draft or volunteer to make them myself.
-----
Garry
-----Original Message-----
From: Garry McCracken
Sent: Friday, January 13, 2006 12:57 PM
To: '[EMAIL PROTECTED]'
Cc: Garry McCracken
Subject: IEEE 1619.1 draft 4 (tape) Comments and feedback
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.
Propose that bullet 3 in section 3.1 be reworded to: 3.1 "Plaintext P
shall have a length from 1 to 2^24"
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".
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.
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.
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."
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
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 ..."
...Garry McCracken
