HKDF entropy extraction

I collect entropy from the following sources:

• system_entropy = System provided crypto entropy stream (CryptGenRandom on Windows)
• user_entropy = User-provided entropy - in a form of a byte stream of serialized random mouse movements, key strokes etc (this is manually entered by the user, similar to how TrueCrypt collects entropy)

To generate a key from these sources, is the following construct appropriate?

my_random_key = HKDF(salt, system_entropy || user_entropy)


Where HKDF is a RFC 5869 construct (both extract and expand steps, but since I don't use "info", just extract is sufficient also) based on HMAC-SHA256.

To my understanding, it should be perfectly fine to just append the user entropy to the system entropy, even under the assumption that the user entropy can be entirely controlled by an adversary, right? Because in that case, the adversary will just destroy the "user_entropy" contribution to the security of the key, but assuming the "system_entropy" is sufficient, then it's ok? In a sense, I assume the "system_entropy" to be already secure, but I want to provide "user_entropy" for additional hardening. So I just want to throw as much random junk at the HKDF as possible.

• This is security theater. First, CryptGenRandom already collects entropy from mouse movements, keystroke timings, etc — and using a much more well-tuned algorithm than you are likely to. Second, if Microsoft is untrustworthy and CryptGenRandom is backdoored, you're already screwed. Just use the output of CryptGenRandom and spend your leftover time addressing attack scenarios with a higher ratio of risk vs mitigation effort. – Stephen Touset May 22 '15 at 23:04
• @StephenTouset: I don't agree. System RNGs have been known to suffer from serious implementation errors (like the Android RNG bug) in the past, not to mention being potentially tempting targets for subversion attacks, and their correct operation is difficult if not impossible for a caller to verify. The safe approach, where possible, is to maintain your own entropy pool, and to treat the system RNG as just another potentially unreliable entropy source for it. – Ilmari Karonen May 22 '15 at 23:40
• @StephenTouset The app is multiplatform and so CryptGenRandom is used only on Windows. I have no idea what the library uses on other platforms. The purpose is to give the users an option for additional hardening in case the library does not do a great job at using the system's native crypto RNG. In such case, the method I suggested in my question is appropriate. – Paya May 22 '15 at 23:42
• @StephenTouset In the context of IlmariKaronen's response, I would like to mention the Dual_EC_DRBG CSPRNG backdoor. – Paya May 23 '15 at 1:18
• Again, if you are trying to defend against an operating system that is actively working against you, you have already lost. CryptGenRandom may very well be backdoored. If it is, you have no reasonable expectation that any other function of the operating system is acting faithfully. – Stephen Touset May 24 '15 at 3:39