3
$\begingroup$

The scenario: A user clicks on an encrypted file, and enters his password, in order to decrypt and authenticate it using HMAC (when its key is derived using PBKDF2). If the iteration-count is fixed, it's deemed secure.

What if the iteration-count is read from the file, Is it still secure? I assume that it's secure in the sense that its encryption is fine. But what about its authentication?

I'm having a hard time finding a specific vulnerability, but the fact that the key derivation "algorithm" is not completely fixed (and can be changed by an attacker) seems insecure.

Improve this question
$\endgroup$
3
  • $\begingroup$ Capture the count as part of the associated data input to the authenticated encryption primitive? (ie make the HMAC include the count) $\endgroup$
    – SEJPM
    Commented May 16, 2017 at 19:21
  • $\begingroup$ @SEJPM Thanks. I'm assuming everything is HMACed except for the HMAC calculated value. But assuming there's some practical attack without this being the case, I'm not sure having the iteration count HMACed would solve it. $\endgroup$
    – ispiro
    Commented May 16, 2017 at 19:38
  • $\begingroup$ What sort of an attack model do you have in mind? If the attacker can modify the iteration count and capture the PBKDF2 output then they can attack just one iteration... $\endgroup$
    – otus
    Commented May 17, 2017 at 4:43

1 Answer 1

Reset to default
3
$\begingroup$

No, variable message iteration count (or more generally workfactor parameters) passed in the ciphertext (including in clear and unauthenticated) is not by itself a vulnerability, to either encryption or authentication, under the following reasonable assumptions:

  1. The adversary can only get and manipulate the ciphertexts, and get plaintexts (with the exception of those s/he is trying to decrypt); not alter the programs used, nor spy their execution.
  2. PBKDF2 (or more generally a sound entropy-stretching function) is well-implemented, and used to convert password and salt to wide symmetric key(s) then used for symmetric encryption and message authentication. Here, "well-implemented" and "sound" includes:
    • The password-streching function does not exhibit much more collisions for different passwords than a random function for any iteration count (or more generally workfactor parameters) that can be parsed from the ciphertext (and leads to bearable execution time). For PBKDF2, an iteration count of 0 (or negative, if the encoding has provisions for that) should be rejected, as specified in RFC2898 / PKCS#5 v2.0 by
          c iteration count, a positive integer .
      An hypothetical implementation accepting an iteration count of 0 and in that case giving constant output (or one depending only on salt) would be vulnerable.
    • The code used for decryption and authentication is not sensitive to side-channel attacks made worse by some choice of the iteration count/workfactor parameters.
  3. There is no other implementation goof (or backdoor, perhaps disguised as goof) that the introduction of the variable workfactor can trigger.
  4. The symmetric encryption and authentication primitives are secure, assuming their wide key has enough entropy.

Argument (not a formal proof): With the password unknown, the entropy in the symmetric keys actually used by the verifier remains high (nearly that of the password or as limited by key width, whichever is lower), including under an attack where the workfactor has been altered. The best attack for the adversary remains to find the password, and the cost of that increases with the workfactor used for a ciphertext that the adversary can intercept and is encrypted or authenticated with the right password; other ciphertexts (including any that the adversary could build without knowledge of the password) do not help towards finding the password.

The main practical danger lies in the consequences of the increased complexity introduced by variable iteration count: the code is more complex, thus more likely to contain an undetected weakness.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thank you very much. And I'm assuming you also mean that it is reasonable to assume that the possibility of collisions for different iteration-counts of PBKDF2 (when using SHA1 as in .net ) is similar to that of iterations of SHA1 which, in turn, we assume to be the same as for any two different inputs (i.e. that there is no more chance of collision between a result of SHA1 and its result). $\endgroup$
    – ispiro
    Commented May 17, 2017 at 11:41
  • $\begingroup$ Thanks. By the way, I was planning to post a question asking whether SHA1-based-PBKDF2 is safe (because of SHA1-collisions), but found your answer here. +1 there, too. $\endgroup$
    – ispiro
    Commented May 17, 2017 at 11:51
  • $\begingroup$ @ispiro: Yes, I assume that for fixed and practical dkLen, whatever iteration count c>0 makes PBKDF2-HMAC-SHA1 essentially a random function/oracle of its other inputs (assumed short). That's not strictly true, but I'm confident that any deviation is beyond exploitable. I make no statement on implementations [reposted with minor tweak]. $\endgroup$
    – fgrieu ♦
    Commented May 17, 2017 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.