So in Windows, when you make a call to the Data Protection API, you can specify some bytes as "entropy".

To me, this sounds like salt. In PBKDF2, the salt is can, and in fact needs to be stored as plain text. It does not compromise the security of the algorithm, it's part of the implementation of it.

Does the "entropy" you pass to the DPAPI serve the same function? I've read that all it does is make your key application-specific, to an extent, in that if the logged in user read out the keys stored with DPAPI, they couldn't decrypt your encrypted data without the entropy. Of course, the entropy would have to be stored as plain text (or else you end up with an infinite regress).

So, is it OK to store the entropy as plain text (maybe hardcode it)?

**Thanks to dr jimbob:**

The entropy parameter "is optional entropy provided by the application that will be added to the key derivation [...] By default, DPAPI already uses different entropy for each blob, so in practice adding additional entropy does **not** [bold added] improve encryption security. According to the documentation, its purpose is to allow applications relying on DPAPI to mitigate the risk of having their secrets stolen by another application. In our test, we found that only GTalk used the conditional entropy, with its value is stored in a registry key and therefore not a real hurdle for the attacker."