Re: Migrating away from SHA-1?

First, sorry for not having this message threaded: I'm not subscribed to the list and haven't found a way to get a Message-Id from gmane.

I just wanted to ask, as an end-user highly relying on commit signatures, a few questions as to the migration away from SHA-1.

SHA-1 already suffers from a freestart collision attack. Based on what I understand of the object model of git, a chosen-prefix collision attack (perhaps somewhat improved) is enough to make reviewers accept a patch, sign it, and then swap the innocuous-looking patch for an evil-doing one -- which *will be signed*.

As for the issue about code checking being an easier entrypoint (Theodore Ts'o, 2016-04-14 22:40:51 GMT), in a use case of mine there is a repo with my dotfiles on an untrusted server. Yet I download them and am able to execute them without fear because each commit is PGP-signed with my key. The point being that code checking is not even a possible entrypoint in some cases, so SHA-1 seems to be(come) the weakest link.

So, I don't think it is possible to disagree with Jeff King when he wrote his 2016-04-12 23:15:19 GMT email.

Peter Anvin (2016-04-14 17:28:50 GMT) gets a point in that there is no need to hurry (chosen-prefix collisions may be still quite a long way, even though there is no guesswork in these matters), and quality is important. Yet Jeff King's proposal (2016-04-12 23:42:52 GMT), amended by Junio Hamano (2016-04-13 01:03:02 GMT) and himself (2016-04-13 01:36:32 GMT) seem to have met no opposition.

So, my questions to the git team:
 * Is there a consensus, that git should migrate away from SHA-1 before
it gets a collision attack, because it would mean chosen-prefix
collision isn't far away and people wouldn't have the time to upgrade?
 * Is there a consensus, that Peter Anvin's amended transition plan is
the way to go?
 * If the two conditions above are fulfilled, has work started on it
yet? (I guess as Brian Carlson had started his work 9 weeks ago and he
was speaking about working on it on the week-end he should have finished
it now, so excluding this)
 * If the two first conditions are fulfilled, is there anything I could
do to help this transition? (including helping Brian if his work hasn't
actually ended yet)

Sorry for bringing up again a subject that seems to be quite recurrent, and for this long block of text, Leo Gaspard

Leo Gaspard <leo@gaspard.io> wrote:

Appending "/raw" to the gmane URL will get you the raw message with full headers:

  article.gmane.org/gmane.comp.version-control.git/$NUMBER/raw

you can also use that article $NUMBER via NNTP on news.gmane.org

It is customary to Cc: all relevant parties involved with that thread since they may not all be subscribed, either.

AFAIK, brian is still working on it. Last series on the matter begins here: http://mid.gmane.org/20160607005716.69222-2-sandals@crustytoothpaste.net I'm just on the sidelines observing :)

On Sat, Jun 18, 2016 at 03:10:27AM +0100, Leo Gaspard wrote:

Sorry it's taken so long to get back to this. I've been at a conference.

I plan on adding support for a new hash as soon as that's possible, but I don't have a firm timeline. This is a volunteer effort in my own limited free time.

I'm not planning on changing algorithms in the middle of a repository. This will only be available on new or imported repositories.

My current thinking on proposed algorithms is SHA3-256 or BLAKE2b-256. The cryptanalysis on SHA-256 indicates that it may not be a great long-term choice, and I expect people won't want to change algorithms frequently.

If time becomes extremely urgent, we can always add support for a 160-bit hash first (e.g. BLAKE2b-160) and then finish the object_id transition later as it becomes convenient. I'd like to avoid that, though.

It takes a long time to get a patch series through. I'm rather busy and don't always have time to rebase and address issues during the week.

You're welcome to send patches if you like. I try to avoid areas I know are under heavy development, like the refs code.