{"thread":{"id":"12337","subject":"Using gpg and gitattributes together","startedAt":"2008-02-27T00:13:19Z","lastAt":"2008-02-29T20:02:37Z","messageCount":3,"participants":["Johannes Schindelin","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"70050","messageId":"alpine.LSU.1.00.0802270008550.22527@racer.site","threadId":"12337","inReplyTo":null,"subject":"Using gpg and gitattributes together","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-27T00:13:19Z","receivedAt":"2008-02-27T00:13:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nI just added my .netrc to a repository where I track some files that I \nwould hate to lose.  However, since I mirror that repository to a machine \nwhere other people than me have root access, I thought that I encrypt the \nfile with gpg.\n\nTo make this procedure more convenient for me, I decided not to encrypt \nwith a private key, but with a passphrase, and to use gitattributes to do \nthe encryption for me:\n\n$ echo 'netrc filter=gpg' > .gitattributes\n$ git config filter.gpg.clean 'gpg --cipher-algo AES256 -c'\n$ git config filter.gpg.smudge 'gpg --decrypt'\n$ git add netrc\n\nIt asks quite a few times for the passphrase (as expected), but I had to \nadd the file twice (not expected).  However, since it worked now, I am \nhappy.\n\nMaybe somebody else will find this information useful.\n\nCiao,\nDscho\n"},{"id":"70398","messageId":"alpine.LSU.1.00.0802291455120.22527@racer.site","threadId":"12337","inReplyTo":"alpine.LSU.1.00.0802270008550.22527@racer.site","subject":"Re: Using gpg and gitattributes together","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-29T14:59:43Z","receivedAt":"2008-02-29T14:59:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 27 Feb 2008, Johannes Schindelin wrote:\n\n> I just added my .netrc to a repository where I track some files that I \n> would hate to lose.  However, since I mirror that repository to a \n> machine where other people than me have root access, I thought that I \n> encrypt the file with gpg.\n> \n> To make this procedure more convenient for me, I decided not to encrypt \n> with a private key, but with a passphrase, and to use gitattributes to \n> do the encryption for me:\n> \n> $ echo 'netrc filter=gpg' > .gitattributes\n> $ git config filter.gpg.clean 'gpg --cipher-algo AES256 -c'\n> $ git config filter.gpg.smudge 'gpg --decrypt'\n> $ git add netrc\n> \n> It asks quite a few times for the passphrase (as expected), but I had to \n> add the file twice (not expected).  However, since it worked now, I am \n> happy.\n> \n> Maybe somebody else will find this information useful.\n\nUnfortunately, this procedure has an issue I was not able to fix, and not \neven Daniel's checkout patch could fix it.\n\nWhen encrypting, gpg uses a random element (to make the encryption harder \nto break, I guess).  So when I update netrc with \"git add\" (and nothing \nwas changed), git will have a _different_ blob.\n\nSo I just tried \"git checkout netrc\", hoping that the index would be \nupdated to say that the netrc file is current, after writing it.\n\nBut that did not work, since git checkout insisted on readding the file \n(which again resulted in a different blob, and therefore netrc seems to be \nout-of-date at all times).\n\nSo scrap that method.\n\nCiao,\nDscho\n\n"},{"id":"70411","messageId":"20080229200237.GA6892@coredump.intra.peff.net","threadId":"12337","inReplyTo":"alpine.LSU.1.00.0802291455120.22527@racer.site","subject":"Re: Using gpg and gitattributes together","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-29T20:02:37Z","receivedAt":"2008-02-29T20:02:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 29, 2008 at 02:59:43PM +0000, Johannes Schindelin wrote:\n\n> When encrypting, gpg uses a random element (to make the encryption harder \n> to break, I guess).  So when I update netrc with \"git add\" (and nothing \n> was changed), git will have a _different_ blob.\n\nThis is probably due to two things:\n\n  1. random salting of the passphrase when generating a key\n\n     To turn a passphrase into a key, you usually do something like\n\n       salt = some random data\n       K = hash(salt + passphrase)\n\n     and then include the salt in your message (since the decrypter\n     needs to know it). The point is to avoid dictionary attacks against\n     common passphrases (IOW, if \"foobar\" always becomes 0xabcdef, then\n     I can just build a table lookup to make brute forcing faster).\n\n     So you can turn this off at the price of lessened security against\n     dictionary attacks.\n\n  2. CBC mode with a random IV\n\n     Most symmetric algorithms are block ciphers. There are many \"modes\"\n     for encrypting a stream; a common one is CBC, which works like\n     this:\n\n       C[0] = random initial vector\n       C[i] = E(K, P[i] ^ C[i-1])\n\n     so each block depends on the block before, and the first block\n     depends on some randomly selected data.\n\n     You can switch to ECB mode, where C[i] = E(P[i]), but it can reveal\n     patterns in the data (there is a nice graphical example on the\n     wikipedia page:\n\n       http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation\n\n     You can also use the same IV over and over again, but that does\n     leak some information: you can tell up to which block two messages\n     encrypted with the same key and IV are the same.\n\n     In the case of your netrc, either of these is probably OK. You are\n     only trying to keep secret one fixed string within the file.\n\nI don't think gpg's command-line interface is flexible enough to change\nany of these options, but I might be wrong. You can definitely use\nopenssl like this:\n\n  openssl aes-256-ecb -nosalt\n\nIf you wanted to implement higher quality encryption in git, you could\njust encrypt/decrypt objects going into the object database (like how we\ndo zlib compression), but still name them by hash. The downside, though,\nis that if objects are named by their contents, there is an obvious\n\"guessing\" attack where I can see if your repo contains an object with\nparticular content. There might be a way around that, but I'd have to\ngive it some thought.\n\n-Peff\n"}]}