2

Inspired by this question about the difficulty of cracking a KeePass database, I'm wondering if changing the default number of iterations in an encryption application (e.g., KeePass) increases security. I'm hoping the question is applicable to a variety of applications; if not, I guess today I'm curious about KeePass.

My reasoning is that an attacker doesn't know the number of iterations ahead of time and therefore has two options:

  1. Assume the user of the encryption application didn't bother to change the default number of iterations, or
  2. Check for password validity for a range of thousands of possible iteration choices (the default is 6,000, so maybe anything from 5,000 to 20,000 or more)

Because #2 is much more work, it's a safer bet for the user to change the default. My theory would be that using a number like 6,001 actually substantially increases security since the attacker is going to focus efforts on the default value of 6,000.

I've read some related questions, which discuss generally how many iterations to choose. What isn't clear to me is whether using an application such as KeePass, where the default number is known to the attacker, makes it important to change the default. If my hunch is wrong, you'll tell me that using 6,001 iterations in KeePass is just as secure as 6,000.

Community
  • 1
Logical Fallacy
  • 715
  • 8
  • 12

2 Answers2

4

Before we start, I think it's important to point out that the round count is stored in the KeePass dictionary file header, so that KeePass itself can open your password files regardless of the setting in its preferences. Otherwise you wouldn't be able to open a KeePass file on another machine if it had a different number of iterations, without first reconfiguring KeePass to that same iteration value (which you may not even remember).

Trying to keep the number of iterations secret is largely pointless, and it's in direct contradiction of Kerckhoffs's principle - only the password should be considered secret; the algorithm and its general parameters should be considered known.

The most important thing to keep in mind is that PBKDF2 is designed to be secure against both precomputation attacks (e.g. rainbow tables) and brute-force attacks where the attacker has immediate access to the hash or an equivalent oracle. Increasing the number of iterations makes the attacker work harder for each password guess, at the cost of taking longer to open the vault legitimately.

Essentially, the security system relies upon the fact that you have to do one quantum of work (let's call this W) when entering the known password, but the attacker has to try hundreds of thousands of passwords (100000 * W), and therefore has to do hundreds of thousands of times more work than you. If your KDF is particularly fast, then W might only involve a millisecond or so of computation, meaning that 100000 * W is only a minute or so. However, if you can tolerate a one second delay, you can increase the work factor W such that the attacker's work takes days or years, not minutes.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • Doh! Makes sense that the number of iterations would more/less have to be known; I'm not sure why that didn't occur to me. I'm marking this as the answer because of the explanation about Kerckhoff's principle, which is new to me. (I'd upvote both answers, but I have insufficent reputation.) – Logical Fallacy Mar 16 '15 at 16:54
  • I've seen it handled differently, however. Sarah Dean's FreeOTFE allows the user to specify both nonstandard salt lengths as well as password derivation hash iteration count. That software stores neither in the block header. I would argue this does increase security. In practice the "secret" to unlock the volume is the combination of the pass phrase plus two numbers (salt length and iterations). If that be a violation of Kerckhoff's principle in theory, so what. It makes cracking such volumes infinitely harder, espec. if the user's pass phrase has some entropy weakness. – boggart Mar 16 '15 at 17:04
0

You're assuming incorrectly: the number of iteration is part of the "public" headers of the keepass file format.

Its necessary otherwise Keepass itself wouldn't know how many iteration to perform (it would have to perform the all). You can verify that this by checking the the keepass source code.

That doesn't mean increasing the amount of iteration used by keepass for key derivation isn't useful, it just means that increasing it by one isn't doing much for security (it more or less increases it by a factor of 1/6000)

Stephane
  • 18,557
  • 3
  • 61
  • 70