ダウンロードしたファイルのチェックサムを計算する理由

ダウンロード可能なファイルの横にチェックサムが表示されることがよくあります。この練習の目的は私を免れます。破損したファイルを検出することは明らかですが、この破損の原因は何でしょうか？

ネットワークプロトコルによって検出されるため、転送エラーによってファイルが破損することはありません。また、悪意のある目的でファイルを変更できる攻撃者は、特定のチェックサムを同様に変更できます。ハードドライブのエラーをチェックしていますか？読むとき、書くとき、それらは起こりそうですか？重要なものが欠けていますか？

破損を検出することは完全に正しいとは限りません。ソフトウェアの整合性を確認することは、より適切な使用法です。通常、ソフトウェアは単一のサーバーから配布されません。同じソフトウェアが多くのサーバーから配布される場合があります。そのため、特定のソフトウェアをダウンロードする場合、ダウンロード速度を上げるために、ダウンロードソースとして宛先に最も近いサーバーが選択されます。ただし、これらの「非公式」（サードパーティ）サーバーは常に信頼できるとは限りません。彼らは/プログラムにトロイの木馬/ウイルス/アドウェア/バックドアを含めることができるかもしれない良いではありません。

そのため、ダウンロードされたソフトウェアが、関係する組織によってリリースされた「公式」ソフトウェアのソフトウェアとまったく同じであることを確認するために、チェックサムが使用されます。チェックサムの生成に使用されるアルゴリズムは、プログラムのわずかな変更でさえ、まったく異なるチェックサムになるようなものです。

実用的なUnixおよびインターネットセキュリティからの例

MD5（青いボックスに$ 1500があります。）= 05f8cfc03f4e58cbee731aa4a14b3f03

MD5（青いボックスに1100ドルあります）= d6dee11aae89661a45eb9d21e30d34cb

単一の文字（およびその文字内では単一のバイナリビット）だけが異なるメッセージは、完全に異なるメッセージダイジェストを持っています。

ダウンロードしたファイルのチェックサムが「公式」ウェブサイトで指定されたチェックサムと同じ場合、ソフトウェアは変更されていないと見なすことができます。

サイドノート：理論的には、2つの異なるファイルは同じハッシュ値を持つことができます。ハッシュ/チェックサムアルゴリズムが安全であると見なされるためには、同じチェックサムを生成する別のファイルを見つけるのは計算上非常に高価でなければなりません。

また、悪意のある目的でファイルを変更できる攻撃者は、特定のチェックサムを同様に変更できます。

常にではない。

HTTPSで提供されるチェックサムとともにコンテンツリンクを持つことができます。リンクは、暗号化されていないリンクである可能性があります-プレーンHTTPまたはFTP、または他の何か。

マイナス面では、暗号化されていない接続は簡単に仲良くなり、プラス面では、ウェブマスターにとってより高速または便利になります（必要なコンピューティングリソースが少なくなり、ネットワークがそのようなものをキャッシュする機会が増えます）。

チェックサムが途切れない信頼できる接続で提供され、ペイロードがチェックサムと一致する場合、両方の長所を利用できます（チェックサムが暗号的に安全であれば）。

そうは言っても、「セキュア」であると主張するディストリビューションがありますが、ウェブサイトはHTTPのみであり、画像へのリンクもあります。

例：

• http://www.networksecuritytoolkit.org/nst/index.html
• http://std.org/download.html

あなたはそれをより安全にできないかもしれないので、それはちょっとおかしいです。ISP自体が悪意のないものであったとしても、どのISPでもWebサイトと画像の両方を偽物に簡単に置き換えることができます。 pwnage。

TCP / IPエラーチェックがすべてをキャッチしない理由に関して：https : //stackoverflow.com/a/17083365/2551539から

発生する可能性のあるさまざまなエラーがあります（TCPが検出します）[Jacob Krallが指摘]：

• パケットの順序が正しくありません
• パケットの損失
• パケット内の破損したデータ
• ファントムパケット（受信者は送信されていないパケットを取得します）

追加情報を編集します。

この調査のページ9：http : //paperhub.s3.amazonaws.com/8ff1e4414c070e900da8ab3885593085.pdfは、TCPによって検出されないエラーがあることを示唆しています。私の理解では、誤ったデータグラム（調査では「不良双生児」と呼ばれる）が目的のデータグラム（調査では「良性双生児」と呼ばれる）と同じチェックサムを持つときに発生するということです。

伝送エラーが発生する可能性があります。リンク層プロトコルには、通常、チェックサムまたはエラー修正コードが含まれていますが、それらは完全ではありません。エラーが修正されない可能性はわずかです。TCPパケットにはチェックサムも含まれており、エラーの確率が2 ^ 16減少します。これにより、伝送エラーの確率は非常に小さくなりますが、ゼロではありません。これは、ほとんどの人が生涯知らず知らずに遭遇するようなことではありませんが、暗号チェックサムの10億年以内の可能性の範囲ではありません。

チェックサムはキャッシュされたコピーから計算されるため、ダウンロード直後にチェックしても、ディスク破損などのクライアントのハードウェアエラーは検出されません。一方、ブートに失敗した場合にブートメディアの破損をチェックすることは有用です。実際にメディアをテストしているので、ハードウェアが不良である可能性があります。

チェックサムを計算する本当の理由は、実際にはソフトウェアレベルのエラーを検出するためです。これらは起こります。考えられるエラーは次のとおりです。

• ファイルが部分的にダウンロードされました。Webサーバーとブラウザは、接続の中断の検出と部分的なファイルのクリーンアップが苦手です。ダウンロード中にエラーが発生したか、アップロード中にエラーが発生した可能性があります。
• 途中でいくつかの破損がありました。たとえば、ファイルの配布におけるいくつかの中間ノードは、バイナリファイルにテキストエンコーディング変換を適用することを決定しました。または、誤って構成されたサーバーがコンテンツではなくエラーメッセージを提供しました。
• バリアント：間違ったファイルがアップロードされました。
• まれですが、保護に役立つ可能性があります。攻撃者がファイルを変更しましたが、参照チェックサムを変更できませんでした。セキュリティインフラストラクチャは、攻撃者が無効なファイルよりも無効なチェックサムを伝播することを難しくする傾向があります。たとえば、大きなファイルは多くの場合ミラーを介して配布されますが、チェックサムは改ざんの機会が少ない中央サイトによって提供されます（プロジェクトリーダーへのサーバーアクセス、HTTPSによる配布）。

実際には、ダウンロードしたファイルのサイズをチェックすると、最も一般的なエラーが検出されます。これは、切り捨てられたファイルまたは無効に変換されたファイルです。チェックサムには、より多くの問題を厳密に検出できるという利点があります。

理論的には、ネットワークはすべての単一セグメントを適切に配信し、ディスク上で適切にアセンブルされ、何も問題はありません。

実際には、コンピューターは機械とソフトウェアであり、どちらも誤りのある人間によって設計および構築されています。ダウンロードが何らかの理由で何らかの形でダウンしない場合、たとえば、ダウンロードがデータを破壊する無害または悪意のある中間デバイスを介して行われる場合、ファイルがほぼ確実にあったことを確認する方法があると便利ですプロバイダー側​​でファイルの正確なレプリカとしてダウンロードされます。

高品質のチェックサムは、データの整合性を検証するための信頼できる方法です。

多くのファイルが同じチェックサムにマッピングされるため、100％信頼できるチェックサムはありません。

列車に別のチェックサムを追加すると、乗算します誤りを検出する確率。

インターネットには非常に多くのトラフィックがあるため、実際にはエラーは非常に一般的です。

チェックサムは、次の状況によるダウンロードの破損を防ぐのにも役立ちます。

ダウンロードの提供中にサーバーで内部エラーが発生したため、ダウンロードが終了します。

それが起こるとき、いくつかの可能な結果があります：

• 良好なサーバー - チャンク転送エンコーディングのサーバーの実装はバグがありません：
  • 良いクライアント（cURL、wgetなど）は、終了チャンクがサーバーから送信されたことがないため、これが悪いダウンロードであることを通知できます。
  • 不良クライアントは、サーバーからこれ以上データを受信して​​いないため、ダウンロードが完了したと判断します。
• 不良サーバー - チャンク転送エンコードの サーバーの実装は、それはこの悪いダウンロード用終端チャンクを送信するバギー：
  • すべてのクライアントは、このダウンロードが正常に完了したと考えるでしょう。

人気のあるクライアントツールとサーバーフレームワークでこれらの動作を見てきましたので、チェックサムを使用しない場合、「良いサーバー+悪​​いクライアント」または「悪いサーバー+任意のクライアント」の場合、破損したダウンロードは認識されません。