The keepass password manager uses multiple rounds of AES for its key derivation, as described here. I was somewhat surprised that it wasn't using pbkdf2, bcrypt, or something more common. Essentially, the key derivation is:

key = sha256(password)
cipher = AES(random_seed1, ECB)
for i in number_of_iterations:
  key = cipher.encrypt(key)
key = sha256(key)
key = sha256(random_seed2 + key)

Is there a name for this kdf? Are there other systems that use something similar? I'm mostly interested in general background info on the above approach. Are there any weaknesses in this approach? It seems considerably simpler than pbkdf2 and bcrypt.

  • 1
    $\begingroup$ I don't recognize it from anywhere. But a negative answer is tricky; I don't think I know all the KDF's ever invented. I'm not so sure if it is simpler than other approaches. It seems to use two primitives - AES-256 and SHA-256 instead of one. I'm pretty sure it is safe. It seems that they used two primitives that are readily available on most platforms. Because they are not using the state as a key, it may be that an attacker has a larger advantage than with other schemes though. $\endgroup$ – Maarten Bodewes Aug 28 '13 at 7:33
  • $\begingroup$ Why not something like $\operatorname{KDF}(k,s,n) = \bigoplus_{i=1}^n \operatorname{AES}_{\operatorname{MD5}(k \mathbin\| s)}(i)$ instead? $\endgroup$ – forest Jan 14 at 3:18

One of the advantages of schemes like scrypt and bcrypt is that they are designed to be "hard" to brute-force. That is, the actual guts of the algorithm are designed to continuously use something that is difficult for a specialized implementation to speed up. For example, scrypt is based on sequential memory-hard operations, which makes sequential memory access a bottleneck of the computation process (meaning that the CPU is idle waiting on memory for some of the time).

This scheme doesn't leverage such a problem, and I would further argue that it's choke-point is pragmatically easy to brute-force due to the prevalence of AES-NI. For an attacker with AES-NI, a scheme like this would possibly the easiest type of scheme to brute-force because the choke-point uses the fastest cryptographic algorithm the attacker has access to.


Practically, there probably isn't anything wrong with it other than it's fast (AES is really fast in software and hardware).

Theoretically it is not secure. The danger here is that when iterating AES there is probably a cycle with a period less than 2^128 (block size of AES is 128 bits). That is, at some point in the iteration the same value will get output again and the cycle will restart.

There are two AES blocks being iterated with the same key but different starting inputs. They may collide, or be in separate cycles, or in different parts of the same cycle. So in the end, it is less than 2^256 work for the attacker, even though the derived key is 256 bits long.

  • 4
    $\begingroup$ The odds of hitting such a cycle with a standard KDF number of iterations, such as 10k, are very low. $\endgroup$ – B-Con Aug 28 '13 at 22:42

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.