Any comments on using something like the NIST key-derivation proposal? Maybe HMAC with SHA-256?:
DeviceKey = HMAC-SHA-256(UserKey, OUI || Vendor-Specific Info) If we're not worried about entropy loss, then a hashing algorithm seems to make sense. This approach does introduce a new cryptographic primitive, however, it should be possible to implement this in software or firmware, making it essentially 'free'. The Option 1 for AES key transform potentially limits the amount of vendor unique information to about 13 bytes (16 bytes - 3 byte OUI). It'd be nice to have a bit more room than that. Can we get some comments from the other cryptographers out there? -Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Shai Halevi Sent: Tuesday, January 10, 2006 6:52 AM To: SISWG Subject: Re: p1619.1 (tape) Proposal for AES key transform based on 3-byte IEEE OUI Sorry that I didn't get to look at it earlier. Jim's "option 2" is cryptographically baaaaaaad. Using non-secret (possibly malleable) information as the AES key for the purpose of key-derivation raises nasty issues wrt related keys. If the application uses the same "user key" with several "transform keys" that are only slightly different, then the resulting "device keys" will be related in a bad way. I don't know if this can be exploited for cryptanalysis, but I will not be very surprised if it can. "Option 1" is much much better, and the "lost entropy" in the keys is a non-issue (even these were 128-bit keys, and certainly for 256-bit keys). -- Shai On Jan 5, 2006, at 6:43 PM, Matt Ball wrote: > 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
