RE: p1619.1 document (tape), draft version 0.4
Hi Jim,
Let me make sure I understand the idea. Does this describe a possible implementation of the two options?:
Option 1:
K2[0:127] = AES-Enc_k1(id)
K2[128:255] = AES-Enc_k1(id')
where id is a globally unique identifier and id' is also unique, but possibly derived from id.
Option 2:
K2[0:127] = AES-Enc_id(k1[0:127])
K2[128:255] = AES-Enc_id(k1[128:255])
(We have a subtle problem because the AES cipher is using a 256-bit key, but processes 128-bit blocks. To generate the derived key, it would then be necessary to perform at least two encoding operations from the AES engine.)
Concerning the two options, I suspect that Option 1 might be more secure because it is not easy to compute k1 given K2. It also uses the full 256-bit k1 in the correct place in the AES block cipher (i.e. as the key input). However, with Option 1 there is an issue with creating a good value for id' (maybe use the 1's complement of id?). Also, it appears that there is likely a loss of entropy in Option 1, similar to the loss from a hashing function. In fact, I suspect the entropy loss might be greater because of using two block ciphers (each block cipher in this configuration would probably lose roughly 2/3 of a bit of entropy, for a total of 4/3 of a bit).
Option 2 is more symmetric with respect to k1 and k2 and doesn't have the problem of needing an alternate id'. It would also allow a 256-bit (32 byte) id instead of 128-bit. However, if k1[0:127] == k1[128:255], then the derived K2 will also have the upper and lower halves being the same. I suspect this isn't a problem, but it does depart a little from an ideal 256-bit random permutation. Lastly, since the id is being used as a key, there might be weak key problems, although I suspect this isn't an issue.
Option 2 also maintains the full entropy of k1 within K2, which is probably the most compelling reason to use this construct over a hashing function. However, the hashing function approach has a bit more flexibility with allowing variable-length inputs and also protects k1 if K2 is ever discovered.
I'm personally leaning towards using HMAC, although I could be easily persuaded to use AES.
Any other thoughts?
-Matt
-----Original Message-----
From: stds-p1619@ieee.org [mailto:stds-p1619@ieee.org]On Behalf Of james
hughes
Sent: Thursday, January 05, 2006 2:56 PM
To: Landon Noll
Cc: james hughes; SISWG
Subject: Re: p1619.1 document (tape), draft version 0.4
We have some challenges.
The CCM spec does not allow long IVs.
Thinking out loud... If we do not want to use SHA-1, would it be
possible to K2 = E_k1(id) or K2 = E_id(k11) where k1 is the key
provided, id is a 16 byte is vendor unique (or standard name) and K2
is the actual media key. This way, we don't introduce a new algorithm
into the standard? (more algorithms, more potential weaknesses).
jim