Use of PBKDF2 when no access to HKDF?

Question

I would like to use a unique encryption key and authKey for each payload that I encrypt and authenticate via AES256 CBC with HMAC-SHA256. I'm considering the following:

Salt = 32 random bytes, unique to each payload, stored out in the open.
MasterKey = 32  random bytes, chosen once ever, stored securely
EncKey||AuthKey = PBKDF2(MasterKey, Salt, iterations) 

Where EncKey will be 32 bytes used as the encryption key to AES256CBC and AuthKey will be 64 bytes used as the hashKey for HMAC-SHA256.

From my reading on crypto.stackexchange.com I understand that HKDF is probably a better function to use for deriving EncKey and AuthKey then PBKDF2 but in the development environment I'm in (.Net) I don't have access to HKDF from an authoritative source.

Is it ok to use PBKDF2 for this purpose? And if so, is it better to use a high iteration count (like 100,000) or a low iteration count like 1?

Answer 1

From my reading on crypto.stackexchange.com I understand that HKDF is probably a better function to use for deriving EncKey and AuthKey then PBKDF2 but in the development environment I'm in (.Net) I don't have access to HKDF from an authoritative source.

Discretion is the better part of valor, so more often than not it makes sense to try and use algorithms your environment provides over having to implement your own. In this case, however, I think we have a reasonable exception; if your environment provides PBKDF2, and thus presumably HMAC, I think HKDF is simple enough that I'd say just write your own implementation of it. The most useful source is the RFC:

• https://www.rfc-editor.org/rfc/rfc5869

In particular, if your MasterKey is already uniformly distributed, section 3.3 tells you that you can skip the HKDF-Extract function (section 2.2) and implement just the HKDF-Expand (section 2.3), which is little more than a fairly straightforward chain of HMAC calls:

HKDF-Expand(PRK, info, L) -> OKM

Options:
   Hash     a hash function; HashLen denotes the length of the
            hash function output in octets
Inputs:
   PRK      a pseudorandom key of at least HashLen octets
            (usually, the output from the extract step)
   info     optional context and application specific information
            (can be a zero-length string)
   L        length of output keying material in octets
            (<= 255*HashLen)

Output:
   OKM      output keying material (of L octets)

The output OKM is calculated as follows:

N = ceil(L/HashLen)
T = T(1) | T(2) | T(3) | ... | T(N)
OKM = first L octets of T

where:
T(0) = empty string (zero length)
T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)
...

(where the constant concatenated to the end of each T(n) is a
single octet.)

Answer 2

Yes, you could use PBKDF2 for this.

You can use an iteration count of 1 as the master key will already contain 256 bits of entropy: that's plenty, you don't need any strengthening for that.

So you should try and configure PBKDF2 using HMAC-SHA256 or HMAC-SHA512 as PRF. Note that the standard indicates SHA-1 as default, so that's probably what is used if you don't configure it with a different secure hash or HMAC. It seems however impossible to configure Rfc2898DeriveBytes with SHA-256. That means that the key strength may be diminished somewhat as SHA-1 is configured to provide no more than 160 bits of security.

Note that normally you should not use more output from PBKDF2 than the hash size as it provides an advantage to an attacker. This is however inconsequential because the high amount of entropy in the master key puts the attacker at a pretty strong disadvantage in the first place.

Input:

• P: the masterkey in bytes (instead of the password)
• S: the derivation data, possibly prefixed by a salt (included with the ciphertext, one salt should suffice per set of keys)
• c: the iteration count, set to 1
• dkLen: 32 (the size of the derived key or secret in octets)

You could for instance use an 8 byte salt, followed by the encoding of the ASCII encoded strings "EncKey" and "AuthKey". You may also want to include some ID, especially if you want to establish keys between two parties (for two way communication).

The salt isn't really necessary, it's optional for HKDF as well.

---

Implementing HKDF is indeed not that hard, but be sure to test it plenty if you decide to go that route; in the end this is your choice.

[EDIT: removed HMAC using key for HKDF, IKM is put in HMAC as message, not as key]

Answer 3

If you are going to generate a MasterKey with a CSPRNG, and securely store/retrieve it when encrypting/decrypting, I see no need for a key derivation function of any kind. I suggest you just use the key directly with AES-GCM which takes care of the authentication for you. If you need to use AES-CBC-HMAC, then just generate a longer MasterKey and split it into two keys as required.