Transparent Git Encryption | Hacker News Reader

Transparent Git Encryption

github.com

36 pointsdpeck10 comments

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

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

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...). In contrast, git-crypt uses CTR mode with a synthetic IV, which is secure.

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.

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.

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

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/

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

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.

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.

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

Reply on news.ycombinator.com