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.
Yes, that should be secure. It seems however that your problem lies with the secure random number generator and that you are using a KDF to overcome those. Basically you are using a KDF as key generator; no keys are derived from another / master key.

It seems more obvious to use a DRBG / CPRNG (deterministic random bit generator / cryptographically secure pseudo random number generator - there are probably more names) and seed it with random values from the system and the user. After that you can just extract the key bytes, and you would still be left with a (fast) RNG that you can reuse / reseed - something you will likely need later on.

Many API's already provide these out of the box, and usually they are pre-seeded as well, so you may just have to add your user generated entropy to the state by mixing in additional seed data. Nothing stops you from adding HKDF + OtherInfo in addition to the DRBG of course, but that is not required.