3 ms·

Actually, this might not come as surprise to you, but there are a few reasons you should not do this, as highlighted by Hamano, the head maintainer of Git post-

• __david__ 14y ago
  > Actually, this might not come as surprise to you... Probably not, given he has a link to that same email as one of the very first things in his README. > ...but there are a few reasons you should not do this Having read the thread, it seems that everyone is talking about encrypting an entire repository in such a way, where as this project and (the surprisingly similar) git-crypt[1] are designed to encrypt only a few select files inside a repo--which isn't going to impact the git packer's compression techniques too much. [1] http://www.agwa.name/projects/git-crypt/ http://www.agwa.name/projects/git-crypt/
  • agwa 14y ago
    Hey, git-crypt author here. I agree with Junio Hamano that you shouldn't use this technique to encrypt an entire repo but of course I think it works fine for encrypting a few select files. Another important difference is that the example in the thread was using GPG, which is non-deterministic encryption, whereas git-crypt (also git-encrypt[1]) uses deterministic decryption (i.e. the same plain text always encrypts to the same ciphertext). Using deterministic encryption is absolutely essential or else git thinks the file has changed when it really hasn't. This was one of Junio's main objections ("making a pair of similar 'smudged' contents totally dissimilar in their 'clean' counterparts"). [1] Beware that git-encrypt uses ECB to accomplish deterministic encryption, which is insecure (the pictures here speak volumes: https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 https://en.wikipedia.org/wiki/Block_cipher_modes_of_operatio...). In contrast, git-crypt uses CTR mode with a synthetic IV, which is secure.