Let's assume that I generate a high entropy AES master key (through /dev/random for example) and I want to derive it with a fixed-length serial number (12345 for instance). The derived key is used to encrypt and authenticate files that can be read by a specific device only (with said serial number). Therefore, to create files for that device, only the master key and the serial number would be required. Which KDFs would you recommend for that scenario? Thanks!

  • $\begingroup$ Personally, I would use HMAC-SHA512 and truncate to the required key size $\endgroup$ – Richie Frame Apr 9 '15 at 13:38
  • $\begingroup$ @RichieFrame: Might as well use HKDF-SHA512, so you can say you're using a real standardized KDF. (HKDF is basically just a standardized answer to "How do I use HMAC as a KDF?") $\endgroup$ – Ilmari Karonen Apr 9 '15 at 16:13

Any standard key derivation function should do.

There are, in general terms, two kinds of KDFs: those that are meant for deriving keys from (potentially) low-entropy passwords, and are thus designed to be deliberately slow (key stretching), and those that are meant for deriving keys from a high-entropy master key / secret, and so can be made much faster. Your use case falls into the latter category.

One example of a non-key-stretching KDF you could use is HKDF, a nice and versatile KDF based on a cryptographic hash function (used in the HMAC construction). HKDF is an "extract and expand" KDF, where the output keys are derived in two steps:

  1. in the extraction phase, the master key and an optional non-secret "salt" are used to derive an intermediate "pseudorandom key" (PRK), whose size is determined by the output length of the hash function used; and

  2. in the expansion phase, the pseudorandom key computed in the extraction phase is combined with an optional "info" string to derive one or more output keys of arbitrary length.

In situations (like yours) where the master key is already a uniformly random bitstring, the HKDF standard allows the extraction phase to be skipped, and the master key to be used directly as the pseudorandom key. Thus, you could simply skip the HKDF extraction phase, and use the device ID as (one part of) the "info" parameter to HKDF-Expand.

Alternatively, e.g. if you wish to derive multiple keys for each device (say, an encryption key and a message authentication key), you could use the device ID as the non-secret "salt" in the HKDF-Extract stage to obtain a device-specific PRK, and then derive the actual device keys from this PRK using HKDF-Expand.

HKDF requires you to choose an underlying hash function to use. Basically any secure cryptographic hash would do, but Richie Frame's suggestion to use SHA-512 seems fine to me, and at least ensures that the size of the PRK will not be a security bottleneck.

Finally, let me briefly note that the general extract-and-expand construction use in HKDF could also be instantiated with some pseudorandom function other than HMAC; some possible variants are mentioned in the HKDF paper (Krawczyk, 2010).

| improve this answer | |
  • $\begingroup$ Thank you very much for your clear and thorough explanation. I have a couple of additional questions: - About the expansion phase, you mention using the device ID as "(one part of) the info". Something as short as a serial number would be enough for the info or would you recommend using additional data or some sort of padding? - In your alternative scenario, what is the advantage in using different keys for encryption and authentication per device (keeping in mind that multiple files - or file sections - will be encrypted for each device)? $\endgroup$ – Shiranui Apr 14 '15 at 8:30
  • $\begingroup$ The length of the "info" parameter does not matter; it just needs to be unique for each derived key. Or, to put it the other way around, if you feed the same PRK and info parameters to HKDF-Expand, you get the same key out. As for using separate keys for encryption and authentication, many authenticated encryption schemes (including, notably, those based on generic composition of a cipher and a MAC) require it, for their security proofs to be valid. $\endgroup$ – Ilmari Karonen Apr 14 '15 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.