Thanks Shai and Glen for getting this updated!
I think the only big outstanding issue is that we need to find a way to solve
the problem of unique IVs across different vendors. Jim, have you had a chance
to looks at some of the options? I'd like to get some discussion started
before our next meeting in February, so here are some comments (most coming
from Fabio's meetings of the December meeting):
Does anyone have a link to the NIST key derivation algorithm draft? This could
be a good candidate if it's somewhat useable. If nothing else, it would
provide a good starting point.
Just brainstorming here -- How about if we did something like this:
NewKey = SHA-256(UserKey || 3-byte IEEE OUI || Vendor unique
information)
That is, we concatenate the provided user key with the unique 3-byte IEEE
vendor ID, along with anything else that would be useful for a vendor to
include (product name, serial number, media ID, etc). Of course, using a
hashing function like this would reduce the entropy of the 256-bit key by
roughly 2/3 of a bit, but it seems to me that 255.3 bits would still be enough
security (anyone think we need to keep the whole 256-bits of entropy?). By
using a hashing function we shouldn't need to worry about possible weak keys
(not that AES has any...).
Other ideas? The minutes mentioned that we could try using NIST key wrap.
Does anyone have a link to this as well?
Also, I've discovered that it may not be easy to guarantee a unique nonce in
all cases. For example, with some technologies it is difficult to create a
unique media ID because the tapes may have no preformatting whatsoever (thus no
way to store a unique media ID). It is then up to the first drive that writes
a tape to create a media ID for that tape. The most promising approach so far
is to create a 64-bit random number and use that within the nonce.
Realistically speaking, a 64-bit random number would not reach its birthday
limit until somewhere around 4 billion tapes. This seems to me like adequate
protection for someone who has already lowered their security standards by
using the same key on multiple tapes.
Would it be okay if we relaxed the 1619.1 specification to say that the IV must
only be unique for a given tape, and otherwise have a high probability of being
unique across different tapes? This would make for a much more practical
solution for the different technologies. We could additionally add an advisory
that the user should generally not use the same key on multiple tapes.
Thoughts?
Thanks,
-Matt
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Shai Halevi
Sent: Friday, December 23, 2005 6:55 PM
To: SISWG
Subject: p1619.1 document (tape), draft version 0.4
Attached is another version the p1619.1 draft, modified by Glen and myself.
Following the discussion in the last meeting, we modified it to be very
permissive
in terms of what is written to tape and in what format. Also we added a section
about authentication-only mode to reflect a request to put it there. We need to
discuss, however, whether or not we really want it there (I personally do not).
Some editorial changes: the draft now talks about variable-length block storage
rather than tape. Also, we tried to be consistent about using bytes vs. bits to
specify length (we chose bytes).
-- Shai
