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).