# Is SHA256 good enough to shrink a key?

I have a key that is the combination of two shorter keys generated by PBKDF2, which together are long more or less 64 bytes. Now I need to shrink it down to 32 bytes and I'm not sure what to use to do it. I was thinking of SHA256. I know that SHA256 is not safe to generate keys by itself, but since what I have is a combination of two proper generated keys, then SHA256 would be just fine. Am I right or I should use something else to accomplish this goal?

-
No objection... –  fgrieu Jul 3 '14 at 17:32
Since you have PBKDF2, you can also just do one iteration of that using both the keys as input, and the specified length as output. But SHA-256 works too. –  Stephen Touset Jul 3 '14 at 17:44
You haven't said what your use is, but there are better and newer hash algorithms available that aren't written by the NSA - Skein and Keccak come to mind. Use the 256 bit variant of them instead. –  NDF1 Jul 4 '14 at 4:27
Skein and Keccak do not have the thirteen years of cryptanalysis that SHA-256 has. There is little compelling reason to choose one of them over SHA-256 at the current time. There is no need to search for the NSA hiding under every rock. –  Stephen Touset Jul 4 '14 at 16:37
Do you work for the NSA Stephen? When using an algorithm from an author it requires a fair amount of trust in their work. When that author has been shown to be backdooring and weakening crypto standards (Dual EC DRBG and more) also their game plan to do exactly this in leaked documents then it's a fair assumption their other work may contain issues. For instance, where is the design document for how SHA2 was designed and the reasons for decisions made, e.g. choice of IVs etc? If I read the specs for Skein and Keccak they detail their decision making process and reasons for every small detail. –  NDF1 Jul 5 '14 at 8:31

$$\operatorname{HMAC-SHA-256}(\text{key}, \text{info} || \text{0x01}),$$