I have an encrypt function that takes a single encryption key and encrypts data but also incorporates an HMAC. So I need to derive a second key from the encryption key to use it for HMAC.
You recommend using a simple hash like sha256 or HKDF for driving the second key and why?
Which one is better and why?
But I am not stringent about these details, and if simple hash has no serious flaw I will use it because it seems much simpler.
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 actually secure, but rather arguments in forms like this:
The difference between your proposed uses of SHA-256 and HKDF comes down to HKDF being more careful and pessimistic. We don't have proof that HKDF is more secure than SHA-256 in your application, but the arguments for HKDF's security are better than those for SHA-256 because they rely on fewer and/or weaker untested premises than your use of plain SHA-256 would.
But it's also entirely possible that simple SHA-256 would be secure in this application. Do you want to bet on it? (Lots of systems do, so far successfully.)
So applying this to your comment here:
But I am not stringent about these details, and if simple hash has no serious flaw I will use it because it seems much simpler.
...the thing to remark is that you're looking at the issue backwards—you're proposing to use the simple hash unless somebody can prove to you that it's insecure (which it might not be!). But the way cryptographers look at it is that you shouldn't use the hash function unless you can articulate some good (even if inconclusive) reason why it's secure (e.g., by conjecturing that SHA-256 behaves similarly to a random oracle).
