git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Herczeg Zsolt <zsolt94@gmail.com>
To: git@vger.kernel.org
Subject: Git and SHA-1 security (again)
Date: Sat, 16 Jul 2016 15:48:49 +0200	[thread overview]
Message-ID: <CAPp-Vrb_n6z39RLHZ4AeUaBFiJfL3_xX8Utfq7+bTgzZrza58Q@mail.gmail.com> (raw)

Dear List Members, Git Developers,

I would like to discuss an old topic from 2006. I understand it was
already discussed. The only reason i'm sending this e-mail is to talk
about a possible solution which didn't show up on this list before.

I think we all understand that SHA-1 is broken. It still works perfect
as a storage key, but it's not cryptographically secure anymore. Git
is not moving away from SHA-1 because it would break too many
projects, and cryptographic security is not needed but git if you have
your own repository.

However I would like to show some big problems caused by SHA-1:
 - Git signed tags and signed commits are cryptographically insecure,
they're useless at the moment.
 - Git Torrent (https://github.com/cjb/GitTorrent) is also
cryptographically broken, however it would be an awesome experiment.
 - Linus said: "You only need to know the SHA-1 of the top of your
tree, and if you know that, you can trust your tree." That's not true
anymore. You have to trust your computer, you servers, your git
provider in a way that no-one can maliciously modify your data.

I understand that git is perfect for a work flow, where you have your
very own repository and you double-check any commits or diffs you
accepting to it. But that's not everybody's work flow. For example: if
I want to blindly trust my college, I could just include all commits
he signed without review. Currently I can't do that. There are
workarounds of course: signing the e-mail he sends me, or signing the
entire git repository's tarball, etc... But that's not the right way
to do things.

As a final thought on this, I would like to say: Git is a great tool,
but it can be so much better with a safe hash.


I would like to propose a solution for changing git's hash algorithm:
It would be a breaking change, bit I think it can be done pretty
painless. (If you read the discussion back in 2006 the problems of
moving are clear.)

In git, every data has to have one and only one key - so a hybrid hash
is a no-go. That means changing hash algo involves re-hashing every
data in a git repository, but it's not that bad. On a git clone, we
actually re-hash everything to check integrity. Changing all the keys
shouldn't be worth than that.

But - and that's the main idea i'm writing here - changing the storage
keys does not mean you should drop your old hashes out. If you change
the git data structure in a way, that it can keep multiple hashes for
the same "link" in each objects (trees, commits, etc) you can keep the
old ones right next to the new one. If you want to look up the
referenced object, you must use the newest hash - which is the key.
But if you want to verify some old hash, it's still possible! Just
look up the objects by the new key, remove all the newer generation
keys, and verify the old hash on that.

A storage structure like this would allow a very great flexibility:
 - You can change your hash algorithm in the future. If SHA-256
becomes broken, it's not a problem. Just re-hash the storage, and
append the new hashes the git objects.
 - You can still verify your old hashes after a hash change - removing
the new hashes from the objects before hashing should give you back
the old objects, thus giving you the same hash as before.
 - That makes possible for signed tags, and commits to keep their
validity after hash change! With a clever-enough new format, you can
even keep the validity of current hashes and signs. (To be able to do
that, you should be able to calculate back the current format from the
new format.)

Moving git forward to a format like this would solve the weak-key
problem in git forever. You would be able to configure your key algo
on a per repository basis, you - and git - can do the daily work on
the newest hashes, while still carrying the old hashes and signatures,
in case you ever want to verify them. That would allow repositories to
gracefully change hashes in case they need to, and to only
compatibility limitation is that you must use a new enough git to
understand the new storage format.

What are your thoughts on this approach? Will git ever reach a release
with exchangeable hash algorithm? Or should someone look for
alternatives if there's a need for cryptographic security?

Thank you for your time reading this.

References:
SHA-256 discussion in 2006:
http://www.gelato.unsw.edu.au/archives/git/0608/26446.html
Discussion about git signatures in 2014
https://www.mail-archive.com/git%40vger.kernel.org/msg61087.html
Linus's talk on git
https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s

Kind regards,
Zsolt Herczeg

             reply	other threads:[~2016-07-16 13:48 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-16 13:48 Herczeg Zsolt [this message]
2016-07-16 20:13 ` Git and SHA-1 security (again) brian m. carlson
2016-07-16 21:46   ` Herczeg Zsolt
2016-07-16 22:03     ` brian m. carlson
2016-07-17  8:01   ` Johannes Schindelin
2016-07-17 14:21     ` brian m. carlson
2016-07-17 15:19       ` Duy Nguyen
2016-07-17 15:42         ` brian m. carlson
2016-07-17 16:23           ` Theodore Ts'o
2016-07-17 22:04             ` brian m. carlson
     [not found]               ` <1468804249.2037.0@smtp.gmail.com>
2016-07-18  1:18                 ` Fwd: " Herczeg Zsolt
2016-07-18  7:12                 ` Johannes Schindelin
2016-07-18 15:09                   ` Herczeg Zsolt
2016-07-18 15:57                     ` Johannes Schindelin
2016-07-18 16:05                       ` Duy Nguyen
2016-07-19  7:18                         ` Johannes Schindelin
2016-07-19 15:31                           ` Duy Nguyen
2016-07-19 17:34                             ` David Lang
2016-07-19 17:43                               ` Duy Nguyen
2016-07-19 17:59                                 ` David Lang
2016-07-19 18:04                                   ` Duy Nguyen
2016-07-19 18:58                                     ` Herczeg Zsolt
2016-07-20 14:48                                       ` Duy Nguyen
2016-07-20 12:28                                     ` Johannes Schindelin
2016-07-20 14:44                                       ` Duy Nguyen
2016-07-20 17:10                                         ` Stefan Beller
2016-07-20 19:26                                           ` Junio C Hamano
2016-08-22 22:01                                         ` Philip Oakley
2016-07-18 16:12                       ` Herczeg Zsolt
2016-07-19  7:21                         ` Johannes Schindelin
2016-07-18 18:00               ` Junio C Hamano
2016-07-18 21:26                 ` Jonathan Nieder
2016-07-18 23:03                 ` brian m. carlson
2016-07-21 13:19                   ` Johannes Schindelin
2016-07-21 12:53                 ` Johannes Schindelin
2016-07-22 15:59                   ` Junio C Hamano
2016-07-18  7:00       ` Johannes Schindelin
2016-07-18 22:44         ` brian m. carlson
2016-07-21 14:13           ` Johannes Schindelin
2016-07-18 16:51       ` Duy Nguyen
2016-07-19  7:31         ` Johannes Schindelin
2016-07-19  7:46           ` David Lang
2016-07-19 16:07         ` Duy Nguyen
2016-07-19 17:06           ` Junio C Hamano
2016-07-19 17:27             ` Duy Nguyen
2016-07-19 18:46               ` Junio C Hamano
2016-07-18 16:51 ` Ævar Arnfjörð Bjarmason
2016-07-18 17:48   ` Herczeg Zsolt
2016-07-18 20:01     ` David Lang
2016-07-18 20:02     ` Ævar Arnfjörð Bjarmason
2016-07-18 20:55       ` Junio C Hamano
2016-07-18 21:28         ` Herczeg Zsolt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPp-Vrb_n6z39RLHZ4AeUaBFiJfL3_xX8Utfq7+bTgzZrza58Q@mail.gmail.com \
    --to=zsolt94@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).