I'm familiar with how key derivation functions can be used to slow down brute force attacks against passwords by requiring significant computational and/or memory resources to compute the final key.

Common KDFs I'm aware of are bcrypt, PBKDF2, and scrypt, but KeePass seems to use an entirely different algorithm that I'm not familiar with. According to KeePass's help center:

To generate the final 256-bit key that is used for the block cipher, KeePass first hashes the user's password using SHA-256, encrypts the result N times using the Advanced Encryption Standard (AES) algorithm (called key transformation rounds from on now), and then hashes it again using SHA-256. For AES, a random 256-bit key is used, which is stored in the database file.


By default, KeePass sets N to 6000 encryption rounds (full encryptions are meant; N has nothing to do with the internal encryption rounds of AES). This number has been chosen in order to provide compatibility with portable device versions (PocketPC processors are slower, therefore the key computation takes longer).

Is this use of AES as a KDF secure? Are there any serious flaws with this approach? Is 6000 iterations enough to significantly slow down a determined attacker?

That line about "PocketPC processors" is a bit concerning, as it implies to me that this decision on what KDF to use was made quite some time ago, before phones with more powerful processors existed (and, by extension, at a time when desktop processors weren't nearly as powerful).

  • Asking whether something is "Secure" is like asking whether someone is "blond" or "Tall". Security is not a boolean value, it is a relative value. What is your use case? Are you protecting something worth a dollar? A hundred dollars? A million? A life? – Mark C. Wallace Sep 30 '15 at 16:12
  • 1
    Well, it's KeePass, so I'm protecting my password database. (As are everyone else using the same password manager.) I realize "secure" is a relative term, and that "security" can encompass a lot of things, but mainly I'm wondering here whether there are any serious flaws with this approach, and what caliber of brute force attacks it can stand up against. Approximate price/(guesses/second) would be a great estimate of security in this case. Or alternately, an analysis of how this method compares to industry standards like PBKDF2 would also make for a great answer here. – Ajedi32 Sep 30 '15 at 16:17

Based on a 2014 tweet from Malik Mesellem, who created a KeePass master key cracking software named KeeCracker, he was getting a bit over 1,000 password guesses a second with his tool on an Intel i7 CPU.

In an answer to this similar question about KeePass key storage from back in 2011, Tom Leek discusses the possibility of 32,000 password guesses per second with a quad core CPU. That may have been a best case estimate that is further degraded due to inefficiencies in the cracking software managing those AES operations, like we see with the KeeCracker figure.

Either estimate is pretty slow as far as password cracking goes, where you regularly see hundreds of millions or billions of hashes per second on a single GPU with a bad choice of algorithms like MD5. The KeePass implementation is a bit faster than a 'typical' modern implementation of bcrypt or scrypt, but probably not by so much that you'd consider them to be in a whole different class.

I'm not aware of any criticisms of their choice of algorithms or implementation, and I'm not really qualified to evaluate them myself, but it appears that it is not considered a bad choice. I think it's fair to question whether 6000 rounds is sufficient if you want a 'future proofed' password archive, but it doesn't seem that this is necessarily an irresponsible number to use today.

So the biggest concern of KeePass users should be choosing a master passphrase (e.g. not a password) that is going to withstand simpler cracking attempts. Don't use known phrases, don't make it too short, don't make it predictable based off someone's personal knowledge of you, etc. If you properly avoid these things it becomes unlikely that your passphrase will be discovered through dictionary, hybrid, or brute force cracking attacks.


Concerning your last question: you're right to be concerned about compatibility with PocketPC processors, as 6000 rounds is an insecure setting. You should set this value around 5000000 or so. The downside is that the encryption/decryption of the passwords archive takes longer, so you should try to find the highest value that causes a delay you're comfortable with.

  • 3
    While setting up the database, I noticed that KeePass has a button you can click to calibrate the number of rounds to take ~1 second on whatever PC you are currently using. I used that option and the resulting number of rounds was way, way higher than 6000, so you're probably right about 6000 being insecure against modern attackers. – Ajedi32 Oct 2 '15 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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