[解決済み] なぜGitは暗号化ハッシュ関数を使うのですか？

質問

なぜGitは SHA-1 より高速な非暗号化ハッシュ関数ではなく、暗号化ハッシュ関数なのですか？

関連する質問

Stack Overflowの質問 なぜGitはバージョン番号にSHA-1を使うのですか？ は、なぜGitがコミット時に連番ではなくSHA-1を使うのかを説明しています。

解決方法は？

TLDR

• 2005年から2018年/Git 2.18まで。 SHA-1 参照
• 2019年、いずれは切り替わる予定 から SHA-256

から確認することができます。 リーナス・トーバルズ自身が、2007年にGoogleにGitを紹介したときのことです。 :

(強調)

暗号学的に安全とされるチェックサムをチェックしています。誰もSHA-1を破ることはできませんが、ポイントは。 gitに関する限り、SHA-1はセキュリティ機能ですらありません。純粋に一貫性のチェックです。 .

セキュリティの部分は別のところにあります。多くの人が、gitはSHA-1を使っていて、SHA-1は暗号的に安全なものに使われているので、それが大きなセキュリティ機能であると思い込んでいるのです。セキュリティとは全く関係なく、単に最高のハッシュ値を得ることができるだけです。

良いハッシュを持つことは、データを信頼するために良いことです。 オブジェクトをハッシュ化するときに、そのハッシュがうまく分散されていることがわかるので、特定の分散の問題を心配する必要がないのです。

内部的には、実装の観点から、ハッシュが非常に優れているため、ハッシュアルゴリズムを使用しても悪いケースがないことが分かっており、信頼できることを意味します。

ですから、暗号の面でも好きな理由はあるのですが、本当にデータを信頼できるかどうかということなのです。

もしあなたが自分のデータをgitに置いたなら、5年後、ハードディスクからDVDに変換され、どんな新しい技術であれ、あなたがそれをコピーした後でも、あなたはその事実を信頼できることを保証します。 5年後に戻ってきたデータが、入れたデータとまったく同じものであることを確認できる。これは、ソースコード管理システムに求められるものです。 .

Git 2.16（2018年第1四半期）で2017年12月更新：代替SHAをサポートするこの取り組みが進行中です："をご覧ください。 なぜGitはよりモダンなSHAを使わないのですか？ "。

"に記載しました。 git は blob の SHA-1 衝突をどのように処理するのでしょうか？ というのは できる 特定の SHA1 を持つコミットを設計する 接頭辞 (それでも非常にコストのかかる作業です)。

しかし、ポイントは、次のとおりです。 エリック・シンク で言及しています。 Git 暗号ハッシュ " ( 実例で学ぶバージョン管理 (2011年)書籍 :

DVCSにとって重要なことは、同じダイジェストを持つ2つの異なるデータに遭遇しないことである。幸いなことに、優れた暗号ハッシュ関数は、そのような衝突を極めて起こりにくくするように設計されています。

を見つけるのが難しくなっています。 良い非暗号化ハッシュ のような研究をしない限り、衝突率が低い。 遺伝的プログラミングによる最先端の非暗号化ハッシュの探索 ということです。

また、"もお読みください。 ハッシュの高速化のために非暗号化ハッシュアルゴリズムの利用を検討する "で、例えば次のようなことに言及しています。 xxhash RAMの限界に近い速度で動作する、非常に高速な非暗号化ハッシュアルゴリズムです。

Gitのハッシュを変更することに関する議論は、新しいものではありません。

• どちらか を最適化する（2009年8月） ただし、ライセンスの問題があります。

(リーナス・トーバルズ)

本当に何もないんです 残り モジラのコードから始めたんです。今にして思えば、ブロッキングを正当に行っているPPCのasmコードから始めるべきだったのでしょうが、これはquot;20/20 hindsight"のようなものです。

それに、モジラのコードがひどい粗悪品の山だったからこそ、自分ならもっと改善できると確信したんです。だから、それは、実際に残っているコードよりも、動機付けの側面についてであっても、一種のソースです ;)

そして、気をつけなければならないのは 実際の最適化利得をどのように測定するか

(リーナス・トーバルズ)

この方法によって状況が改善されるのは、gccがくだらないコードを生成するようになり、P4の問題のいくつかが隠蔽されるからだと、私は断言できます。

• または 全面的に変更する（2010年1月）
  
  (例えばSHA-3へ、しかしそれは他のどのハッシュにも適用されます)。

(ジョン・タプセル - johnflux )

git を SHA-1 から新しいアルゴリズムにアップグレードするためのエンジニアリングコストは、はるかに高くなります。 . どうやったらうまくできるのか、よくわからない。

まず第一に、新しいハッシュ値のためのスロットがあっても、そのスペースを読み込んだり使用したりすることはなく、他のスロットにあるSHA-1ハッシュ値を使用するだけのgitのバージョン（この会話のためにバージョン2と呼ぶことにしましょう）をデプロイする必要があるでしょう。

そうすることで、一度 結局 は、SHA-1 ハッシュに加えて SHA-3 ハッシュも生成する新しいバージョンの git（バージョン 3 と呼びましょう）をデプロイしますが、バージョン 2 を使っている人は相互運用を続けることができるのです。

(ただし、この議論によると、彼らは脆弱であり、彼らのSHA-1のみのパッチに依存している人々は脆弱であるかもしれません)。

に切り替えることで、簡単に言えば 任意 ハッシュは簡単ではありません。

2017年2月更新：はい、衝突するSHA1を計算することは理論上可能です。 シャッタード.io

GITはどのような影響を受けるのですか？

GITは、すべてのファイルオブジェクトとコミットの識別と整合性チェックにおいて、SHA-1に強く依存しています。

同じコミットハッシュを持つ2つのGITリポジトリを作成し、異なるコンテンツ、例えば良質のソースコードとバックドアを持つリポジトリを作成することが本質的に可能です。

攻撃者は、ターゲットとなるユーザーに対して、どちらかのリポジトリを選択的に提供することができる可能性があります。この場合、攻撃者は自分自身で衝突を計算する必要があります。

しかし

この攻撃には9,223,372,036,854,775,808回以上のSHA1計算が必要でした。これは、シングルCPUの計算で6500年分、シングルGPUの計算で110年分に相当する処理能力を要したことになります。

だから、まだ慌てないでおこう。

詳しくは"でご覧ください。 Git は Blob の SHA-1 衝突をどのように処理するのですか？ "です。