> Can anyone describe the NIST key-derivation algorithm? This would be very > helpful in guiding the group.
I went ahead and answered my question about the NIST key derivation. It looks like this is a link to the current proposal to NIST for a standard "Key Derivation Function": <http://www.ietf.org/internet-drafts/draft-dang-nistkdf-00.txt> There is also some discussion about this standard on the IETF webpage. Here's a link to the e-mail list: <http://www1.ietf.org/mail-archive/web/cfrg/current/threads.html> Look for e-mails with the subject "Hash-Based Key Derivation". Several people from the 1619 group are also members of the ietf group, so we should be able to get some good feedback on pros and cons of a KDF. The NIST KDF spec above defines the key derivation as follows: Compute Hash-i = H (counter || SV {|| algorithmID} || contextID {|| SharedInfo}). Where counter is a 32-bit integer going from 1 to ceiling(keydatalen / hashlen), SV is the "Secret Value", or in this case, the 256-bit AES key, algorithmID is an optional algorithm identifier, contextID is a combination of an identifier for both the sender and receiver, SharedInfo is an optional string with any additional data, and || is the concatenation operator If we were to apply this standard to IEEE 1619.1, it would probably look something like this: NewKey = SHA-256(0x00000001 || UserKey || Len(FormatID) || FormatID || Len(Misc) || Misc) Since the output of SHA-256 matches the 256-bit key size, it is only necessary to run the hashing function once (that is, counter only ever equals 0x00000001). Can anyone from the IETF group make any comments on this approach? What kind of pitfalls should we expect? Is it likely to become a standard? Personally, I'd rather use HMAC-SHA256 instead of just SHA256. This construct would help to reduce the entropy loss and would also make it harder to attack SHA256 if a weakness is later found in the hashing function. We could also remove the 'counter' since it's always 1. Here is how this new approach could look: NewKey = HMAC-SHA-256(UserKey, Len(FormatID) || FormatID || Len(Misc) || Misc) or, by the definition of HMAC: NewKey = SHA-256(UserKey XOR 0x5C5C5C... || SHA-256(UserKey XOR 0x363636... || Len(FormatID) || FormatID) || Len(Misc) || Misc)) where UserKey is the user-provided 256-bit key, NewKey is the derived key later used in the AES-GCM engine, FormatID is a globally unique identifier of the tape format, and Misc is any other useful vendor-specific information. Each length field would be a Big-Endian 32-bit integer indicating the number of 8-bit bytes within the following field. The FormatID and Misc fields would either be a Big-Endian Integer, or a variable length ASCII string. 'FormatID' would need to be a registered, unique identifier that globally identifies the format. 'Misc' would be any other vendor-specific information that would be useful in uniquely identifying the media. Is this approach secure? Is there too much entropy loss? Comments? Thanks, -Matt
