[〜＃〜] update [〜＃〜]：上記の質問とこの回答は2015年のものです。それ以来、Googleは最初のSHA-1を発表しました衝突： https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
明らかに、Gitが引き続きSHA-1を使用し続ける理由については、外部から推測することしかできませんが、これらは理由の1つである可能性があります。
- GitはLinus Torvaldが作成したものであり、現時点では、LinusはSHA-1を別のハッシュアルゴリズムに置き換えたくないようです。
- 彼は、Gitに対するSHA-1衝突ベースの攻撃の成功は、衝突自体を達成するよりもかなり難しいともっともらしい主張をしており、SHA-1は、完全に壊れているのではなく、SHA-1が本来よりも弱く、少なくとも今日は実行可能な攻撃。さらに、彼は、衝突するオブジェクトが既存のオブジェクトよりも遅れて到着した場合、「成功した」攻撃はほとんど達成されないことに注意します。逆が発生する可能性があります）。
- ソフトウェアの変更は、特に移行が必要な既存のプロトコルに基づいた既存のインフラストラクチャとデータがある場合、時間がかかり、エラーが発生しやすくなります。暗号化セキュリティがシステムの唯一のポイントであるソフトウェアおよびハードウェア製品を製造している人でさえ、SHA-1やその他の弱いアルゴリズムからの移行を進めています。ハードコードされた
unsigned char[20]はあらゆる場所でバッファリングします;-)、後で改修するよりも、最初に暗号化の俊敏性をプログラムする方がはるかに簡単です。 - SHA-1のパフォーマンスは、さまざまなSHA-2ハッシュよりも優れており（おそらく、現在の契約を破るほどではありませんが、10年前の固定点だったかもしれません）、SHA-2のストレージサイズは大きいです。
いくつかのリンク：
- Gitで衝突が発生した場合に何が起こるかに関するStackoverflowの質問
- 主なSHA-1の弱点が2005年に知られるようになってから数か月後の主題に関するLinusからの短いコメントを示すニュースグループの投稿
- 2006年に弱点とsha-256への移行の可能性を議論するスレッド（Linusからの返信付き）
- SHA-1の非推奨と「ハッシュ関数のより強力なSHA-2ファミリに迅速に移行する」ことを推奨するNISTステートメント
私の個人的な見方では、実際の攻撃はおそらくしばらく休みますが、実際に攻撃が発生しても、人々はおそらくハッシュアルゴリズム自体を変更する以外の手段で最初にそれらを緩和するでしょう、セキュリティを気にするならあなたは間違っているべきです攻撃者の能力も一方向にしか進まないため、アルゴリズムの選択に注意し、セキュリティ強度を継続的に上方修正するため、Gitをロールモデル、特にその目的として採用するのは賢明ではありませんSHA-1を使用することは、暗号化セキュリティを意図したものではありません。
これはMercurialのSHA1からの移行の緊急性に関する議論ですが、Gitにも適用されます。 https://www.Mercurial-scm.org/wiki/mpm/SHA1
要するに、今日、あなたが非常に巧妙でなければ、sha1よりもはるかに悪い脆弱性があります。しかし、それにもかかわらず、Mercurialは10年以上前にsha1からの移行の準備を始めました。
sHA1の後継者向けにMercurialのデータ構造とプロトコルを改良する作業が長年にわたって進行中です。 RevlogNGの導入により、Mercurial 0.9では10年以上前にrevlog構造の大きなハッシュにストレージスペースが割り当てられました。最近導入されたbundle2形式は、ネットワークを介した異なるハッシュタイプの交換をサポートしています。残りの部分は、置換関数の選択と後方互換性戦略の選択のみです。
GitがMercurialが移行する前にsha1から移行しない場合、ローカルMercurialミラーを hg-git で維持することにより、常に別のレベルのセキュリティを追加できます。