Hi HN. This has been bugging me a very long time, hopefully the brilliant minds of HN can enlighten me.<p>I use KeePassX as a password manager, and I store the kdb file in Sparkleshare folder as a way for backing up and syncing with multiple devices.<p>The kdb file in itself is encrypted, but if someone stole the git repo, they technically have many versions of the same file with minor variations. Would that in any way reduce the security of the file?<p>Would really love to hear with people think.
I found the following info on the KeePass homepage[0]:<p>>For both algorithms [AES/Twofish], a 128-bit initialization vector (IV) is generated randomly each time you save the database.<p>>This allows multiple databases to be encrypted using the same key without observable patterns being revealed.<p>I'm no crypto expert, but I think this also covers multiple versions of your kdb file.<p>[0]: <a href="http://keepass.info/help/base/security.html#secencrypt" rel="nofollow">http://keepass.info/help/base/security.html#secencrypt</a>
I do not think HN is the best place to ask this.<p>Try <a href="http://security.stackexchange.com/" rel="nofollow">http://security.stackexchange.com/</a><p>Submit the answer back for HN to discuss if you want.
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: <a href="http://i.imgur.com/rxesWJl.png" rel="nofollow">http://i.imgur.com/rxesWJl.png</a> -- so basically there's only two constant 16-byte sequences, there rest of the file being entirely unique.
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.<p>Three scenarios in which it would be potentially unsafe to keep a versioned password database, from worst to least-worst:<p>* 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).<p>* 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.<p>* 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.<p>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.