# How well will the max transformation rounds in Keepassx deter an attacker for the next twenty years?

Keepassx lets you decide how many transformations rounds need to be run in order to unlock your Keepass database. In my version of Keepassx (2.0.3) the max value seems to be 999,999,999. With that setting it takes my laptop about 22 seconds to unlock the database. I imagine that a beefy workstation would take less time than that. With that in mind, how well can this setting deter someone else from accessing your database, assuming that they managed to get access to it? Let’s just say an individual (not an organization) with a computer made to do this kind of work. How much work can you assume that they will have to do per try with the kind of computation power that they will have access to in twenty years?

• I'm not sure that anyone can guess what computing power will look like in 20 years ... Jan 5, 2020 at 21:06
• Are you sure that you need to be able to keep the data inside secret for 20 years? By rolling over the password once every 2 years, you just need to be able to secure it for 2 years max, 1 year average.
– user163495
Jan 5, 2020 at 21:50
• @MechMK1 That would be more sensible. :-) Jan 5, 2020 at 22:50
• @schroeder Sure, but it's pretty easy to create a sane upper based on trends and our understanding of computing hardware. While 100 years is very likely too distant in the future to guess where technology will be going, I'd be willing to bet big bucks that, 20 years in the future, we're still using the same basic technology (fast switching semiconductors, probably still silicon on various substrates). Jan 6, 2020 at 8:31

A bit of math allows you to easily understand how many extra bits of security these iterations provide. The general rule is that the number of bits of security you gain is the base 2 logarithm of the number of iterations. Rounding your maximum value of iterations to 109 iterations, you gain log2(109) ≈ 30 bits.

Is an extra 30 bits enough to deter an attacker for the next 20 years? That depends on how many bits of entropy your initial password has. If your original password started with 70 bits it would be difficult, but not impossible, to break even today. If you add an extra 30 bits through 109 hash iterations, you will have effectively 100 bits of security, which is likely to deter most attackers for the next 20 years.

• The answer is not quite correct. You ignore the performance. Suppose they changed internal implementation and put 1 000 000 todays transformations into a loop and call it a single transformation. So that 1 000 new transformations need the same computational resources as 1 000 000 000 todays transformations. You may say that the entropy increases in log2(1 000) = 10 bits, which is 20 bits worse than in todays scenario, and that it is essentially easier to brute-force it. But that is not true, because the hacker still needs the same computational resources. Jan 6, 2020 at 12:06
• Another example: Suppose you have a 4-digit PIN. A 256-bit key is derived from it and derivation takes 1 hour. Because of 256-bit random IV precalculation makes no sense and the attacker has to test every single PIN. Then it does not matter that the attacker can perform let say 10^12 tests of 256-bit passwords per second, tests in the sense "does this 256-bit key decrypt this AES-256 encrypted message. He will need at least 1 hour to brute force this 4-digit PIN having 10 000 CPUs/computers. Jan 6, 2020 at 12:20

The passwords kept in the password manager database can be arbitrary long, because user doesn't need to remember them, he will just copy them from the password manager. But the *master password is not stored in the database. It should be either remembered or stored somewhere else (e.g. in hardware like Yubikey or Titan key). Passwords of what length can you remember? 10 characters? 12?

A human readable password of 12 characters means entropy of about 72 bit. This is can be brute-forced easily. To slow brute-forcing down, Keepass uses transformations.

How much slowness is needed?

Suppose you have password of 12 characters, each one from the range of "human friendly" characters (a-z, A-Z, 0-9 --> 62 characters). There are 62^12 possible passwords, this is about 10^22.

Suppose password transformation takes 1s. Suppose an attacker has 1 000 000 CPUs. The he will be able to check 1 000 000 passwords/s.

There are about 3x10^7 seconds in a year. The attacker will check 3x10^7 x 1 000 000 = 3 x 10^13 passwords per year.

To check all 10^22 passwords he will need 10^22 / (3 x 10^13) ~= 3 x 10^8 years.

If you use less iterations so transformation instead o 1s takes 0.001s, then the attacker will need 3 x 10^8 x 0.001 = 3 x 10^5 = 300 000 years.

Not only takes it long. It costs also money: to purchase these CPUs, to supply electric power, etc. Who will rent a cluster of 1 000 000 CPUs for many years just to break your password?

It is much cheaper to install some hardware like video cameras or key loggers and obtain your password in a short time.

To your question: even transformation of 0.001s and password of 12 random characters will deter an attacker for many thousands of years.

• 80+ or even 90+ entropy passphrases are pretty easy with diceware.
– Ben
Jan 6, 2020 at 6:02
• 72 bits cannot be brute forced easily, though it's not impossible with enough money. Jan 6, 2020 at 8:07
• @Guildenstern: As I showed you don't have to wait 22 seconds to open database. Even if you adjust the number of iterations so that transformation takes 1s, it will take 3 x 10^8 years to brute-force it. Waiting 22 sec each time you are just loosing time without effectively getting more security. Jan 6, 2020 at 12:42