Comment 6 for bug 1214844

Seth, I'll leave it to your judgement as part of the Ubuntu Security Team on whether and how to escalate this. Personally I would err on the side of removing the decision from the user as we've seen, time and again, that ordinary users just do not have the ability to make rational judgements over questions of security.

I wasn't sure where else I should report it, considering that 0.4.x is unmaintained upstream. Having thought about it some more I suspect the Debian security team ought to be alerted? I see that the same developers are involved with both Ubuntu and Debian packaging of keepassx.

Key derivation looks like this:

RawMasterKey := SHA256( ConvertToCP1252(password) )
Generate nonces N1,N2.
MasterKey := SHA256( AES-ECB(AES-ECB( ... /* 50000 times */ AES-ECB(data=RawMasterKey, key=N1) ... ,N1),N1) )
FinalKey := SHA256(N2, MasterKey)

The database payload is then AES-CBC or Twofish-CBC encrypted using FinalKey with a random IV. The IV and all nonces are generated using Yarrow, seeded from /dev/urandom, and stored in the database header.

If a key file (32 bytes binary or 64 hex digits) is used as well as a password,
RawMasterKey := SHA256(RawMasterKey from password || KeyFile).

There is a little further wrangling for backwards compatibility with earlier database versions that used Latin-1 or UTF-8 encoding for passwords; the file opening logic may also try with Latin-1 or UTF-8 conversions of the password entered.

I am only an armchair cryptographer so can't really speak for the security of this key derivation scheme, but I didn't spot any obvious issues with it. It's not the same as PBKDF2, though may be comparable. The nonces - different on every save - seem to reduce the scope for attacks based on obtaining multiple copies of the same database protected by the same password but I haven't thought about them terribly deeply.