# Tag Info

5

With proper hashing the entopy of $Z$ is roughly the sum of both individual entropies, capped to the strength of the hash-function. For SHA-256 the limit is 256 bits, for SHA-512 it's 512 bits. Since entropy above 256 bits is meaningless, this isn't a practical limitation. For XOR computing the entropy of $Z$ is tricky and depends on how your keys are ...

4

Short: In some simple cases, hash could be adequate. However, HKDF is intended to be a generic construct you can commonly apply for needs requiring Extract-Expand (such as when you have a shared secret agreed using DH or ECDH). It aims to be largely compatible with existing practices and thus makes it easy to apply the same pattern to multiple uses. It ...

4

There are two answers: the "engineering" answer, and the "principled" answer. The engineering answer is that, in practice, if you generate two keys using two different info strings, I suspect you'd probably get away with it without problems. If we model the hash as a random oracle (admittedly a very strong "assumption"), then I suspect it might be possible ...

4

One common pitfall when implementing HMAC(key, data) is mishandling the case when key is longer than the underlying hash block. In your case salt is 80 octets, which is longer that SHA-256 "block" (64 octets) so the salt have to be run through SHA-256 before being XOR'ed with i_padin the HMAC. Without seeing any actual code, and provided that the test ...

3

It is unclear if you wanted to compare TLS 1.1 PRF or TLS 1.2 PRF. Different TLS versions have different PRFs. Assuming you meant TLS 1.1 PRF although you linked TLS 1.2 RFC. TLS 1.1 PRF Short: HKDF is commonly a better choice than TLS 1.1 PRF, but not always. Consider these aspects: HKDF is a generic construct. HKDF is extract and expand. TLS1.1 PRF ...

3

You're right: there is no need for key stretching if your key already has enough entropy to resist brute force attacks without it. A 128-bit keyspace should be plenty for that. AFAIK, there is no significant difference between HKDF and single-iteration PBKDF2 in practice. Both effectively achieve the goal of expanding the input key to a potentially longer ...

3

A key derivation function is intuitively "purifying" the entropy in the group element Z into uniformly random (looking) bits that can used as a key for other purposes. It is not designed to produce "multiple keys" from the same Z, and one should definitely not call the KDF on the same Z twice (even with different salts) and expect to get two independent ...

3

No, you don't have to worry about collisions. As long as no pair of users have the same LowEntropy input, they will receive different MasterKeys. If the MasterKey is different, then the AuthKey will be different. Even if you use the same MasterKey to generate multiple AuthKeys, you don't need to worry about collisions: as long as the keynumber values are ...

3

No, the info is not a salt. The input key material for a KBKDF (key based key derivation function) should already be pseudo-random, and should therefore contain enough entropy to not need a salt. If the user already has a unique 16+ pseudo-random bytes key then there is little reason to use the email address as part of the info. The email address could be ...

2

It's best practice to use the KBKDF to generate separate key material for validation as well as for generating the key used for encryption using a different input or counter of each key. If you do apply a KBKDF for each key / IV (using different ID's/counters for each) then you should not have any concern leaking any information. These KBKDF's are plenty ...

2

If you have two keys of constant length, using HKDF is rather pointless. You can simply combine them using a hash function like SHA-2: $$combined\_key = \text{SHA-2}(k_1 || k_2)$$

2

HKDF is deterministic, that is, given the same input; IKM (Input Keying Material), salt, and contextual info (these last two are optional, but recommended), and provided that the same underlying hash function is used (SHA256, for example), the output will always be the same.

2

Although the answer is already accepted, I'll add an answer with a different look on things. It's safe, but that's not what HKDF-expand should be used for. The idea of HKDF-expand is to call it twice, once for each key, using the info element to distinguish between the two (e.g. info could be an ASCII encoding of the key name). Note that HKDF should have a ...

2

Taken directly from the RFC: The second stage "expands" the pseudorandom key to the desired length; the number and lengths of the output keys depend on the specific cryptographic algorithms for which the keys are needed. The use of the plural here suggests (at least to me) that yes, it's ok to expand the same PRK several times with different ...

1

Yes, that should be secure. It seems however that your problem lies with the secure random number generator and that you are using a KDF to overcome those. Basically you are using a KDF as key generator; no keys are derived from another / master key. It seems more obvious to use a DRBG / CPRNG (deterministic random bit generator / cryptographically secure ...

1

If I'm reading your specs correctly, you do this: $IV||VAL||K_E||K_A=KDF(PBKDF(PW,Salt,Iterations))$. (Order doesn't matter here) As far as I know this is common practice and shouldn't pose any security threats, as the IV is in fact unpredictable as it needs to be. If I may I'd suggest you using EAX, CCM GCM mode if available, as this is easier than using ...

1

In both options, if the adversary has a way to check either AES key, then a brute password guessing attack can be attempted, and BCrypt is the main line of defense against that. For constant effort, option 2 force to halve the cost parameter in BCrypt, and is thus twice more vulnerable to password guessing than option 1 is. BCrypt's output is described as ...

1

Yes. You can either use HKDF-expand twice with different info values, or once with a longer output length. Depends. If your 256-bit master key is generated using a secure RNG, a salt is unnecessary. OTOH, if it's derived from something with less entropy, like a password, having unique salts would ensure uniqueness of derived keys even if the master keys ...

1

This hastily written implementation of HKDF in C# agrees with the RFC test vectors: private const int SHA1 = 1; private const int SHA256 = 2; private static HMAC NewHMAC(int h, byte[] key) { switch (h) { case SHA1: return new HMACSHA1(key); case SHA256: return new ...

1

You don't need a salt (it defaults to a zero length salt) if you generated the session keys using Diffie-Hellman. You should however use a different info (octet) string for each key in the expand part of the function. The idea is that the salt makes sure that the derived keys are different if the input keying material (IKM) repeats. If no salt is used ...

1

Realistically, it probably doesn't matter, if all of your premises are accurate. If it were me, I'd probably concatenate the inputs, then apply a HKDF to the concatenation to derive two keys -- but honestly, it's unlikely to matter. This is very unlikely to be the weakest link in your system. Pick something that's easy to implement and easy to understand, ...

1

Yes, according to NIST SP 800-56A revision 2, a KDF based on HMAC-SHA-256 is a suitable option. The basic idea behind using a Key Based Key Derivation Function KBKDF is that the output of the the primitive within the key agreement protocol (DH, ECDH) returns enough entropy for a key to be created. However that entropy may still be distinguishable from ...

Only top voted, non community-wiki answers of a minimum length are eligible