

Ask HN: Does versioning an encrypted file in a git repo make it less secure? - isaacsu

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.
======
pfg
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>

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

~~~
iso8859-1
submitted: <http://security.stackexchange.com/q/35831/13510>

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

~~~
cpa
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.

~~~
pfg
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.

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

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

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

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

~~~
616c
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/>

