Here are a couple comments on using an arbitrarily long IV:
-----------------------------------------------------------
According to the GMAC specification here are the two ways to create Y0 (the
first input into the AES engine):
Y0 = IV || 0x00000001 (if length(IV) = 96 bits)
Y0 = GHASH(H, {}, IV) (if length(IV) > 96 bits)
(practically speaking, if length(IV) < 96 bits, then zero fill until length(IV)
= 96 bits)
Something to watch out for: When using a long IV (> 96 bits), there would be a
temptation to write Y0 to tape instead of the IV because Y0 is fixed at 128
bits and the IV could potentially be longer. However, writing Y0 to tape will
allow the attacker to easy compute the hashing constant 'H', thus compromising
the authentication. It is therefore necessary to write the long IV (if one
chooses to write the IV) to tape instead of the pre-hashed version (Y0).
Another thing about using a long IV is that we have lost the guarantee of
uniqueness within the same tape. We have traded off a higher interchange
security for a lower security level on a per-tape basis. With long IVs, there
is now a chance that two different records on the same tape contain the same
Y0. I believe the chance of an IV collision is somewhere around 1 in 2^128 for
16-byte blocks within different records. After the user writes roughly 2^64
16-byte blocks (or 2^68 bytes), then there will probably be an IV collision,
which then leaks 128 bits of plaintext. This is roughly equivalent to the
security level of CBC mode. While this isn't too bad, it is a drop in the
security level from the original CTR mode.
Concerning IEEE Vendor IDs:
---------------------------
I just realized that we probably can't use the 3-byte IEEE OUI for
differentiating vendors. The interchange problem is not vendor-specific, but
rather format-specific. For example, the LTO format needs to be compatible
with drives made by three different vendors: HP, IBM, and Quantum. In this
situation, we would want to specify something like the 'LTO-1' format instead
of a vendor like 'Quantum'.
Ideally, we would want a way to use numbers or strings that uniquely identify a
particular tape format. If we stick with the hashing approach, it could be
possible to use arbitrarily long strings to identify each format. Even if we
use AES to transform the key, it would be possible to first hash the format
string, then use that value in conjunction with AES.
Is there an existing registry for uniquely identifying formats?
(If people don't like the security of a straight hashing function (like
SHA-256), then we could increase the security by using a construct like HMAC.)
---------------------------------
Can anyone describe the NIST key-derivation algorithm? This would be very
helpful in guiding the group.
Thanks,
-Matt
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Shai
Halevi
Sent: Thursday, January 05, 2006 7:42 AM
To: SISWG
Subject: Re: p1619.1 document (tape), draft version 0.4
There are two ways that I see to solve the IV collision issue:
1. Allow longer IVs: The GCM spec allows IVs of any size, we can just
do the same for 1619.1, and leave it to the application to decide how
to set the IV and to what size. The application can then set the IV to
include the vendor-ID and whatever else it wants to put there. (Does
the CCM spec allow long IVs?)
2. Push the problem to key-management, using a solution such as the one
that was proposed by Matt. We can probably devise key-derivation methods
that use AES rather than SHA256 (or use existing methods from NIST).
Approach 1 is more elegant (I think) but either would work. In the spirit
of having a very permissive standard, I suggest that we just allow any-size
IV and put some appendix that describe the multi-vendor IV issue and
sketches the two solutions above.
-- Shai
Matt Ball wrote:
> [...] 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):
> [...]
> Just brainstorming here -- How about if we did something like this:
>
> NewKey = SHA-256(UserKey || 3-byte IEEE OUI || Vendor unique information)
> [...]
