What is the purpose of the entropy parameter for DPAPI.Protect?

Question

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."

Answer 1

From browsing: http://msdn.microsoft.com/en-us/library/ms229741.aspx

The entropy provides a 16 byte (128 bit) initialization vector, not a cryptographic salt.

You generally do not need to keep your IV secret [1], you just have to be careful not to reuse the same IV (which won't happen if it was randomly generated as there are 2¹²⁸ possible values).

The purpose of the initialization vector is to initially randomize your message before encrypting (typically just the first block).

Compare Electronic CodeBook (ECB) which has no need for an IV and Cipher-Block Chaining which needs one.

Let's say you have some encryption function encrypted_block = Encrypt(block, key) which will take a block of data of fixed size (say 128 bits), a secret encrypt key and return an encrypted block of data, that can be decrypted with block = Decrypt(encrypted_block, key). So if you encrypt a 10 kB file with a 128-bit block size, then you have 640 blocks to encrypt. If two blocks are identical in the original (say its an image with little entropy), then the encrypted blocks at the end will end up identical and patterns can often be discerned. So ECB basically just splits a file into blocks and applies the encryption function to each block individually (without relying on the output of previous blocks).

Now let's look a scheme like CBC which uses an initialization vector (IV). The first block is encrypted by encrypted_block_0 = Encrypt(block_0 ^ IV, key), where ^ is the XOR (bitwise exclusive or operator). The next block is encrypted with encrypted_block_1 = Encrypt(block_1 ^ encrypted_block_0, key); that is you use the result of the encryption of the previous block to 'randomize' the current block prior to feeding into your encryption function. Now if they didn't use an initialization vector for the first block, one could deduce things by observing the first couple blocks. E.g., if you had two encrypted files both with the same initialization vector and saw that the first 10 blocks were identical, you would learn that the first 10 blocks of the plaintext files are identical and you get extra information. Not that merely knowing the IV in the plaintext doesn't help you at all, as it is inside a complicated non-linear Encrypt function that you can't reverse without knowing the secret key.

EDIT: Actually, I think I was wrong to assume that the 16 bytes are used as initialization vector in DPAPI; here'a reverse engineering of microsoft's secret DPAPI: http://cdn.ly.tl/publications/Recovering-Windows-Secrets-and-EFS-Certi%EF%AC%81cates-Of%EF%AC%82ine.pdf