This is indeed a very important issue.
In the case of a T10 compliant application pushing a key down to an
arbitrary drive which the application knows nothing about the vendor
(that is using a proprietary nonce). We need to make sure that vendor
A and B have a 0 chance of a collision.
I would suggest there are two solutions.
1) we do nothing and tell T10 that they must make sure this never
happens and emails like this need to occur in that working group.
this abdicates the nonce collision to them.
2) since we allow the nonce to be vendor independent, we describe and
endorse something like the following.
I want to discuss this issue openly in the group and then decide.
Based on that decision, we can then discuss methods. (especially
since SHA-1 is under a significant amount of scrutiny and we can do
better).
Jim
On Jan 4, 2006, at 9:01 PM, Matt Ball wrote:
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
