When I call Crypt­Protect­Data with the same parameters, why aren’t the results identical?

If you call Crypt­Protect­Data twice in a row with the same parameters, you get different results. Why are the results inconsistent?

The plaintext is the same. The entropy is the same. The key is the same. Shouldn't the result be the same?

If those were the only inputs to the encryption algorithm, then the results should be the same. But they aren't the only inputs to the encryption algorithm. The Crypt­Protect­Data function adds in some bonus random data. This extra data is recorded in the encrypted blob so that it can also be used during decryption.

The purpose of the extra data is to prevent exactly what you're trying to do. Without the extra data, an attacker could recognize that two encrypted blobs were identical and conclude that they had the same plaintext.

For example, suppose an attacker sees that two passwords have the same encrypted blob. The attacker can try to extract the plaintext from one of the blobs by some other means. Maybe one of the blobs corresponds to a site which suffered a security breach that leaked a bunch of passwords. Or maybe the site transmits passwords unencrypted. Or perhaps the site is one the attacker is good at phishing for. However the attacker gets the plaintext for one site, it now knows the plaintext for the other site.

Adding extra random data means that multiple encryptions of the same plaintext with the same key and entropy will nevertheless produce different results. This foils attacks based on comparing encrypted results.

Comments (9)

  1. Gee Law says:

    Bonus reading: IND-CPA (indistinguishability under chosen plain-text attack).

  2. pm100 says:

    aka ‘salt’

    1. Person says:

      No. It’s called an Initialization Vector.

    2. Tanveer Badar says:

      +1 to that.

    3. Indeed, the article summary¹ is “A little added seasoning” :-)

      1. or whatever is called the short text that is displayed under the title in the blog index.

  3. Lauren says:

    So the salt is free? Neat.

  4. Danny says:

    Nitpick: Entropy is changed precisely because of that random data.

    1. Brian says:

      Nitpick of a nitpick. If you call the function 3 times, there’s added entropy from the IV/Salt on the first call, but the same amount of added entropy on the second and third calls as well. So Raymond’s statement “The plaintext is the same. The entropy is the same. The key is the same. Shouldn’t the result be the same?” is correct. What’s different are the bits that make up the added entropy.

    2. GL says:

      You took the word “entropy” out of the context. In Raymond’s article it is an optional blob passed into the API.

      Mathematically, entropy is a number that reflects the degree of uncertainty of a distribution. I believe Windows draws a random IV (or whatever it is) from the same distribution each time you call CryptoProtectData, therefore, the entropy is constant across invocations.

Skip to main content