We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

13

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 ...


10

You should aggregate bits until you have enough seed bits to start your DRBG using an initial seed. Your seed should contain at least 128 bits of entropy (the amount of uncertainty to an attacker). Then you could either add the bits as additional seed when you get it or you could first aggregate some entropy. With only an update rate of about 8 bits per ...


9

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 ...


9

The HKDF paper answers this question at length. Section 8 in particular seems to be the most relevant. But perhaps you may find that the explanations are very technical. To help you out a little bit, the general flavor is this: the security of nearly all modern cryptographic algorithms is conjectural—we don't have unconditional proof that they are ...


9

If you are using the full HKDF each time, you could possibly save time by only using the Extract portion once and Expand once per derived key. That could even halve the total time taken, if you had a worst case situation. Another speedup possibility within HKDF is to use another hash. Either a faster hash or one that matches the required key length better. ...


8

To me it seems like HMAC(salt, IKM) would be weaker against a brute force search of IKMs, as the digest of the salt can in this case be precalculated by an attacker (assuming the salt is a non-secret value or zero). Yes, it is slightly faster to brute force, but if the IKM does not have enough entropy to give brute force resistance, then a small factor will ...


7

These hash functions are also used for the key derivation function. Both are roughly equally secure for a KDF in the sense of collision resistance etc., but SHA512 offers a bit more security as countermeasure for custom hardware attacks, since the memory requirements are a higher than for SHA256 and custom hardware to crack the passwords like FPGAs is more ...


7

Do you really need a KDF when you have a PRF? Maybe. The security contract of a PRF requires that the key be a uniform random bit string. If you have a DH secret or a diceware phrase, then what you have is not uniform random as a bit string, and so your contractual obligations are not satisfied and the PRF may give no security. You need something a ...


6

It depends on how you use HKDF to derive multiple keys. Background: HKDF consists of two stages: first HKDF-Extract computes an intermediate value from the randomness source; then HKDF-Expand can be used to generate one or more session keys from the intermediate value. The right way is to use HKDF-Extract once, and then call HKDF-Expand multiple times, ...


6

Without looking at the code I would say your construction is pretty much the same as XChaCha20: From https://download.libsodium.org/doc/advanced/xchacha20.html Internally, XChaCha20 works like a block cipher used in counter mode. It uses the HChaCha20 hash function to derive a subkey and a subnonce from the original key and extended nonce, and a ...


5

RFC-5869 is about the "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", while NIST SP-800-108 gives "Recommendation for Key Derivation Using Pseudorandom Functions". The main difference between Extract-and-Expand KDFs and KDFs based on PRFs are the requirements on the input keying material. A PRF requires a uniform random key, which implies ...


5

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 ...


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 ...


5

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 ...


5

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 ...


5

There are three classes of random number generators (my own informal classes), dependant on the relative entropies that flow in and out:- Class 1. Hout < Hin, which is a true random number generator (the most secure and best) such as those by Swiss company ID Quantique. This is the class of generator that can be used for creating one time pad material. ...


5

What you describe will work once, and it will be fine to use one salt, which need not even be secret as long as it's different from everyone else's salt. Just derive each service password from the same master key with a different HKDF info parameter. But what happens when a site's password database is breached, and turns out not to have been hashed, and ...


5

Due to the design of TLS 1.3 and different to earlier TLS versions the normal (EC)DHE key exchange is already finished once the server sends the certificate. They key server_handshake_traffic_secret used to encrypt the certificate and other handshake messages is based on the same key material as the keys which are used for the application data later. For the ...


4

What you propose—using the intermediate derivation key $K_{\mathit{DK}}$ from a single input $Z$ to derive many output keys with distinct info strings—is perfectly fine. The excerpt you quoted is about the HKDF-Extract step, not the HKDF-Expand step. What it is saying is that you should not use the same $Z$ with many different salts for HKDF-Extract: use ...


4

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 ...


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 ...


4

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 is ...


4

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 contexts....


4

Deriving multiple keys from a strong source key material (which is what HKDF is for) is not key stretching. The important bit from from the Wikipedia excerpt is this one: 2./ To "expand" the generated output or an already reasonably random input such as an existing shared key into a larger cryptographically independent output, thereby producing ...


4

I'm not aware of any attacks on SHA-512 this way. I would create a small function to validate that the input size to SHA-512 is indeed identical to the seed size though, just in case. Even without that the function should be secure. Kind of related is my question about KDF1 and KDF2. Note that implementation of HKDF-expand from a hash should be pretty easy, ...


4

For example, there are no current attacks to HMAC-MD5, although MD5 is broken for several years. Hash functions have very strong requirements (e.g., collision resistance, preimage resistance, etc.), and some hash functions have been shown to fail some of these requirements (e.g., MD5 is not collision resistant). Hash-based KDFs may be affected by the ...


4

It seems like a stream cipher will always be one-way, whereas a KDF might not be (see AES or DES key schedules for example). A KDF has nothing to do with DES or AES key schedules. Key schedules are internal functions of the block cipher, they aren't designed to be KDF's. And KDF's are certainly supposed to be one-way functions. From SP-800 SP 108 chapter 7....


4

In a secure KDF, the output is indistinguishable from random. In particular, all the output bits are independent, so revealing some of the output doesn't give any indication about the other bits. Hugo Krawczyk's HKDF definition paper proves that HKDF is a secure KDF under some reasonable assumptions on the underlying hash function which SHA-2 is believed ...


4

1) Does that means the kdf generates "actually" 6 keys, but in fact they are 4 keys? The KDF generates 6 values; of the 6, 4 of them can be considered "keys" (in the sense that they'll be used to key some cryptographical primitive) and 2 are not (an IV is typically not considered a "key", as exposing it does not yield a security weakness). Also, some TLS ...


4

The salt is not required to make HKDF secure. Using a static salt doesn't make too much sense - you should be perfectly fine with using an empty salt. Either you can use an empty salt, or a new random salt. This salt could be generated and prefixed per file. If it is large enough (say 128 bytes) then it would make each encryption key unique so you don't have ...


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