git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Using gpg and gitattributes together

From
Jeff King <peff@peff.net>
Date
Feb 29, 2008, 20:02 UTC
Message-ID
<20080229200237.GA6892@coredump.intra.peff.net>
In-Reply-To
<alpine.LSU.1.00.0802291455120.22527@racer.site>
On Fri, Feb 29, 2008 at 02:59:43PM +0000, Johannes Schindelin wrote:
> When encrypting, gpg uses a random element (to make the encryption harder 
> to break, I guess).  So when I update netrc with "git add" (and nothing 
> was changed), git will have a _different_ blob.
This is probably due to two things:
  1. random salting of the passphrase when generating a key
     To turn a passphrase into a key, you usually do something like
       salt = some random data
       K = hash(salt + passphrase)
     and then include the salt in your message (since the decrypter
     needs to know it). The point is to avoid dictionary attacks against
     common passphrases (IOW, if "foobar" always becomes 0xabcdef, then
     I can just build a table lookup to make brute forcing faster).
     So you can turn this off at the price of lessened security against
     dictionary attacks.
  2. CBC mode with a random IV
     Most symmetric algorithms are block ciphers. There are many "modes"
     for encrypting a stream; a common one is CBC, which works like
     this:
       C[0] = random initial vector
       C[i] = E(K, P[i] ^ C[i-1])
     so each block depends on the block before, and the first block
     depends on some randomly selected data.
     You can switch to ECB mode, where C[i] = E(P[i]), but it can reveal
     patterns in the data (there is a nice graphical example on the
     wikipedia page:
       http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
     You can also use the same IV over and over again, but that does
     leak some information: you can tell up to which block two messages
     encrypted with the same key and IV are the same.
     In the case of your netrc, either of these is probably OK. You are
     only trying to keep secret one fixed string within the file.

I don't think gpg's command-line interface is flexible enough to change any of these options, but I might be wrong. You can definitely use openssl like this:

  openssl aes-256-ecb -nosalt

If you wanted to implement higher quality encryption in git, you could just encrypt/decrypt objects going into the object database (like how we do zlib compression), but still name them by hash. The downside, though, is that if objects are named by their contents, there is an obvious "guessing" attack where I can see if your repo contains an object with particular content. There might be a way around that, but I'd have to give it some thought.

-Peff
Previous: Johannes Schindelin
Message 3 of 3 in “Using gpg and gitattributes together”
  1. Johannes SchindelinFeb 27, 2008
  2. Johannes SchindelinFeb 29, 2008
  3. Jeff KingFeb 29, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.