

Transparent Git Encryption - dpeck
https://github.com/shadowhand/git-encrypt

======
616c
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-Linus.

[http://article.gmane.org/gmane.comp.version-
control.git/1132...](http://article.gmane.org/gmane.comp.version-
control.git/113221)

~~~
__david__
> 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/>

~~~
agwa
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_operatio...](https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29)).
In contrast, git-crypt uses CTR mode with a synthetic IV, which is secure.

------
lm741
This is cute. It's like encrypting all of your files with the same one time
pad so diff works. Also not secure at all.

~~~
Dylan16807
Oh come on that's not fair. You had me thinking the code output a cipherstream
and reused it.

It's using a real encryption method, the only flaw is having identical blocks
encrypt the same. Since this is designed to be applied to a handful of small
text files (I think?) this is not a crippling flaw, only a notable one.

~~~
agwa
git-encrypt uses AES in ECB mode. You're right that it's not as bad as reusing
a one time pad, but it's still insecure. The pictures here speak volumes:
[https://en.wikipedia.org/wiki/Block_cipher_modes_of_operatio...](https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29)

It might not be crippling in most git-related use cases, but as a user you
should not need to worry about your cryptosystem potentially leaking
information. My project, git-crypt[1], is similar to git-encrypt but uses AES
in CTR mode with a synthetic IV, which leaks only whether two entire files are
identical. This is the bare minimum you need to leak to make git diffs work,
and there's also a security definition called "deterministic CPA security"
which CTR with a synthetic IV provably meets.

[1] <http://www.agwa.name/projects/git-crypt/>

------
janerik
Came across this today: <https://github.com/AGWA/git-crypt> Nearly the same
but in C++

~~~
michaelmior
The biggest difference I see with git-crypt is that it's designed to encrypt a
subset of files in the repository. This makes a lot of sense to me for storing
secrets within a repo.

------
ch0wn
This doesn't seem much better than rolling your own crypto. I'd rather go with
ecryptfs. `mount -t ecryptfs mygitproj/ mygitproj/` is easy enough.

~~~
feb
As said by Hamano, if you want encryption, use an encrypted file system.
Besides cryptfs, Encfs uses FUSE and works well too
(<http://www.arg0.net/encfs>).

