4 ms·

Transparent Git Encryption

36 points by dpeck 14y ago

deleted 14y ago
[deleted]
lm741 14y ago
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 14y ago
  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 14y ago
    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_operation#Electronic_codebook_.28ECB.29 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/ http://www.agwa.name/projects/git-crypt/
ch0wn 14y ago
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 14y ago
  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 http://www.arg0.net/encfs).
616c 14y ago
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/113221 http://article.gmane.org/gmane.comp.version-control.git/1132...
- __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.
janerik 14y ago
Came across this today: https://github.com/AGWA/git-crypt https://github.com/AGWA/git-crypt Nearly the same but in C++
- michaelmior 14y ago
  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.

36 points by dpeck 14y ago

deleted 14y ago

[deleted]

lm741 14y ago

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 14y ago
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 14y ago
  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_operation#Electronic_codebook_.28ECB.29 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/ http://www.agwa.name/projects/git-crypt/

ch0wn 14y ago

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 14y ago
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 http://www.arg0.net/encfs).

616c 14y ago

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/113221 http://article.gmane.org/gmane.comp.version-control.git/1132...

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

janerik 14y ago

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

michaelmior 14y ago
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.