# Can we have single hash function both for data integrity and key derivation function?

Can we have single hash function both for data integrity and key derivation function? Why and Why not? Any link describing difference analytically will be appreciated. Thanks.

• To my knowledge both can and do use the same types of hash functions as their core. Any key derivation function should also provide data integrity. However not all hash function implementations should be used as key derivation functions. – Q-Club Aug 17 '17 at 18:09
• @back_seat_driver Any secure hash function can be used as a building block for a key derivation function using HKDF, as far as I know. But is the converse true? There are key derivation functions that aren't defined using a hash (e.g. using CMAC instead of HMAC). Can you build a hash function out of an arbitrary KDF? – Gilles 'SO- stop being evil' Aug 17 '17 at 22:02
• AFAIK, a good answer to this question would at least mention: that you can build a KDF from a hash with HKDF; that some hashes (e.g. SHA-3, and more generally I think any hash based on a sponge function) have a natural associated KDF, but with others (e.g. Merkle-Damgård) you don't get a secure KDF; whether there is a generic way to build a hash function from a secure KDF. Unfortunately I don't understand the material well enough to write a good answer. – Gilles 'SO- stop being evil' Aug 17 '17 at 22:36
• ...maybe? It seems like it would probably require trimming the KDF's output and throwing some information away. – Q-Club Aug 17 '17 at 22:47

I'll answer the question in the context of the most common application of KDFs - Password-Based Key Derivation Functions (ex PBKDF2) which take a relatively low-entropy string and derive a key from it. As opposed to Key-Based KDFs which take something that's already a strong key and change its length.

Hashes and PBKDFs are designed for different things. Yes, they are both hash functions with all the usual collision resistance, pre-image resistance, etc, but:

• General-purpose hash functions want to be fast to have efficient implementations in software and hardware. This greatly reduces the runtime costs and latency of TLS servers, embedded devices doing TLS, hashing large files, etc.
• PBKDFs want to be slow to make it as frustrating / expensive as possible to perform brute-force attacks on the password or master key.

SHA2 makes a terrible PBKDF because it's way too fast. PBKDF2 makes a terrible hash function because it's way too slow.

Many key derivation functions use regular hash functions internally.

For example, if you take a look at the PBKDF1/2 spec in RFC 2898, you'll notice:

5.1 PBKDF1

PBKDF1 applies a hash function, which shall be MD2 [6], MD5 [19] or SHA-1 [18], to derive keys.

and

5.2 PBKDF2

PBKDF2 applies a pseudorandom function (see Appendix B.1 for an example) to derive keys.

And the example referenced in Appendix B.1 is to use HMAC-SHA-1 as the underlying pseudorandom function.

Related question on security.SE:

What's the advantage of using PBKDF2 vs SHA256 to generate an AES encryption key from a passphrase?

• I don't see any mention of password hashing in the question. – Maarten Bodewes Aug 17 '17 at 20:14
• Yes. Only relatively weak keys / passphrases require key strengthening. key based KDF's such as HKDF or counter mode based KDF's have been designed to be fast. In that sense cryptographic hash functions can be used as KDF. Although it is more common to use the hash in a HMAC construction (e.g. the PRF used in TLS). – Maarten Bodewes Aug 17 '17 at 20:34
• @MaartenBodewes Fair, although in my experience "key derivation" typically means password -> key while "key stretching" typically means key -> key. Though I have heard things like /dev/random -> key be referred to as "key derivation", but they tend to use DRBGs rather than explicitly using either a hash or KDF. I feel like we're arguing nomenclature more than concept. – Mike Ounsworth Aug 17 '17 at 20:40
• There are PBKDFs (e.g. PBKDF2) and KBKDFs (e.g. HKDF). Both are obviously KDF's - you just have to take a look at the acronym. Anybody calling /dev/random -> keykey derivation really doesn't understand cryptography, I'm sorry to say. Besides it not being valid code, of course :P – Maarten Bodewes Aug 17 '17 at 20:57
• Maarten is right. Password key derivation functions are to key derivation functions as password hashes are to hashes. Key derivation generates key material from a seed. Strengthening is only needed when the seed is a low-entropy string such as a password, not when the seed has sufficient entropy. This question is only about key derivation, not about a possible strengthening. – Gilles 'SO- stop being evil' Aug 17 '17 at 21:33

Well, yes, kind of.

First of all, a cryptographically secure hash only provides limited amount of data integrity. You'd have to know and trust the hash value in advance for it to work. A great example are downloads of software through mirrors. If the software hasn't actually been signed then the main site can host the hashes over the files while you can download the files by using the mirrors. Then you can calculate the hash and compare. Now if the file was altered on the mirror then the hash verification will fail: you'll get different values.

Now a hash is somewhat less problematic as "poor man's key derivation function". Note that hashing passwords instead of keys - as I presume the question implies - using a cryptographically secure hash will generally not create a secure key and may result in an adversary learning the password as well.

Now generally for both situations we can use a keyed hash. HMAC is probably the most well known keyed hash. If a keyed hash is used then yes, we can use a hash for both situations. Obviously it is now required to first agree upon a secret key to use. But after that you can use the same keyed hash to protect the integrity of the data and to perform key derivation.

In general two keys are used, one for each functionality. If that's not the case it will be tricky to prove that the scheme is secure. It is however perfectly fine to use the same hash algorithm as configuration parameter of the HMAC function.

Although HMAC is often used directly as KDF - for instance in TLS - it should really just be used as configuration parameter for a real KDF such as HKDF.

• A hash does provide integrity in the same way that a cipher provides confidentiality. A hash doesn't do anything about authenticity, but that's a different concern. Passwords are a different concern and off-topic for this question. I don't understand how you propose to use a keyed hash to get an authenticity property. You can use a keyed hash to build a KDF (HKDF works for any hash), but the relationship is a bit subtle (in particular you need to be careful not to expose any hash calculation that happens to be a KDF output). – Gilles 'SO- stop being evil' Aug 17 '17 at 21:48
• 1. No, a hash doesn't provide integrity the same way that a cipher provides confidentiality. If you just get a message and hash value then an adversary can change both leaving you without integrity protection. A cipher should however protect the confidentiality even with an active adversary. That's clearly not the same way. 2. Passwords are not explicitly mentioned and it's unlikely that they were implied, but a PBKDF2 is certainly a KDF so I just wanted to cover that corner case. – Maarten Bodewes Aug 17 '17 at 22:19
• 1. If you send a key and an encrypted message then the adversary can read both leaving you without confidentiality protection. That duality works pretty well. An encrypted message is only as confidential as the key, and similarly a hashed message is only as unmodified as the hash. – Gilles 'SO- stop being evil' Aug 17 '17 at 22:33
• The key is not the output of the encryption operation, it is a parameter. But I guess we're at the point where comparison of two rather different algorithms / use cases starts to break down. Before you know it we'll be splitting hairs over apples and pears. – Maarten Bodewes Aug 17 '17 at 22:43
• Thanks all for providing such a detail answers. @Mike Ounsworth, your answer is good and answer the context of my question analytically. Gilles improvements are over technical terms make context more clear. Reason I have asked this question is in some light weight VPN solutions, BLAKE2 is used as hash and HKDF is used for KDF. So natural question was why to use two hashes since memory and cpu cycles in resource constraint devices are limited. So why not one function. Hope no one have anything to add over Mike answer. – Sahil Gupta Aug 18 '17 at 0:19