I found the following info on the KeePass homepage[0]:

>For both algorithms [AES/Twofish], a 128-bit initialization vector (IV) is generated randomly each time you save the database.

>This allows multiple databases to be encrypted using the same key without observable patterns being revealed.

I'm no crypto expert, but I think this also covers multiple versions of your kdb file.

[0]: http://keepass.info/help/base/security.html#secencrypt

I do not think HN is the best place to ask this.

Try http://security.stackexchange.com/

Submit the answer back for HN to discuss if you want.

submitted: http://security.stackexchange.com/q/35831/13510

I am not a cryptographer, but looking at a KDB file in git (with xxd in-between), it would _seem_ you're safe (esp. considering pfg's sibling comment). This pattern of differences repeats for all of the 4 commits I tried: http://i.imgur.com/rxesWJl.png -- so basically there's only two constant 16-byte sequences, there rest of the file being entirely unique.

If you wonder why you're being downvoted: it's probably because there is consensus that either a system has been checked by security professionals (be it mathematicians or implementors) OR should not be considered secure. Note that it is not an exclusive or! Your reasoning only proves that a specific type of attack is unlikely to succeed, but does not say anything for any other attack.

I basically agree. However, if you trust KeePasses implementation of AES-CBC and you consider the fact that the IV will be randomly generated for every file version, you're betting on AES-CBC not leaking any information about the plain-text (which hopefully some expert already checked).

I don't know whether the AES implementation in KeePass has been checked by someone considered an expert yet.

I haven't reviewed KeePassX but they've published a bit about their encryption. They say they're using AES-CBC with random IVs, generated each time the database is updated. You should be fine keeping it versioned.

Three scenarios in which it would be potentially unsafe to keep a versioned password database, from worst to least-worst:

* Had they used AES-CTR with a fixed key and nonce --- a surprisingly common design, unfortunately --- then every save they did would create a chunk of ciphertext encrypted under the same keystream as some previously versioned chunk. This is fatal to the security of AES-CTR; it is a failure mode that keeps me from recommending AES-CTR. (Similar problems exist for the other stream modes).

* Had they used AES-ECB --- ie, the default mode of most AES libraries --- every repeated chunk of 16 bytes would be evident in the ciphertext of the database, and, worse, the versioned copies would likely create variants of that data at different offsets. Combined with known plaintext (maybe there's some in the KeePassX headers?), this could set up an attack, albeit a very elaborate one that would require lots of changes to the database.

* Had they used AES-CBC with a fixed IV, instead of generating it randomly every time the database was updated, they'd have the ECB problem on first blocks of each message. Messing up the CBC IV is a very big problem in online systems where attackers can take many thousands of bites at the apple and adapt their inputs in response to what the target does, but it's less of a problem in offline systems like KeePassX and would have been a mostly theoretical problem.

The bigger problem with KeePass is that it doesn't see to do a good job of deriving keys from passphrases (as documented, it uses salted SHA-256). Maybe that's changed since their security page was authored, but that problem would keep me from putting a KeePass database on any machine I didn't control.

Is the key derivation bad because of SHA-256, or because it is too fast/easy to brute-force? According to the security page, they do 6000 (AES) encryption rounds on the key after hashing it (6000 by default, you can increase the work factor). So I guess this is comparable to what bcrypt/scrypt does?

(There's something on the security page saying that KeePassX (as opposed to KeePass) only partially supports this, though.)

It depends what encryption algorithm you used. In short- Maybe.

Depends on algorithm. Do not store binary data in GIT, make separate archive with binary files if you need them.

To follow up on what mifchip said, binary data can possibly be quite large, and git-annex was designed to manage files in git and create syncing mechanisms without the disk space and overhead of managing the file contents inside said git repo. I would recommend that over using straight git, as it also has options for encryption which might simplify the workflow or make things more transparent. Again, ask around for better info regarding how versioning the file can be used by an adversary (it does depend on the encryption algorithm and implementation, YMMV), but this might be a more suitable solution for you.

http://git-annex.branchable.com/

http://git-annex.branchable.com/encryption/