高速ハッシュ：ファイルの変更を識別するためのさまざまな手法の組み合わせ？

ファイルが同じかどうかをすばやく検出する方法を作成したいと思います。ほぼ100％の確実性のために、既存のハッシュアルゴリズム（SHA256など）を使用します。ただし、ファイルは数GBの巨大なビデオファイルであることが想定されているため、SHA256ハッシュの計算には、特にネットワーク上で時間がかかる場合があります。

したがって、他のさまざまな手法を組み合わせたいと思います。

• ファイルサイズ：ファイルサイズが変更された場合、コンテンツは変更されました（確か）
• 頭/尾ハッシュ
• ランダムハッシュ

後者の2つは私の質問の一部です。

私の推測では、ヘッダーには次のようなものがあります：

• フレームレート（ビデオなど）
• 解像度（ビデオ、画像など）
• （ファイル）長さ（フレーム、ピクセルなど）
• 最終変更日（例：動画ではなくWord文書）

尾をチェックすることを検討する理由は次のとおりです。

• MP3にはタグ情報があります
• EXIFが正しい場合は、最後にカスタムデータを追加します

ランダムハッシュは、ファイル内のランダムな位置にある特定の長さ（例：64 kB）の126の領域を選択し、それらのハッシュを作成します。もちろん、後で比較するためにオフセットを覚えています。全体として、ハッシュには（1 + 126 + 1）* 64 kBのデータを使用するので、ハッシュを取得するには、数GBではなく8 MBを読み取るだけで済みます。

たぶん今は数学の問題でしょうが、ファイルサイズ、ヘッド、テール、ランダムデータの組み合わせを使用して変更を検出し、このクイックハッシュサムを生成する可能性はどのくらいありますか？

ファイルは常に正当なファイルであると思います。シングルバイトを操作するメリットはありません。ユーザーは通常のビデオ編集ツールを使用してファイルを変更します。

更新：私はCrypto.StackExchangeからのこの回答を受け入れませんでした。私の提案は暗号化されておらず、安全であることを意図していないことに同意します。また、ファイルのCRC処理が高速であることにも同意しますが、私の場合は本当にハッシュが必要です。その理由を説明します。

• 私のアプリケーションでは、ブックマークをビデオに保存することが期待されています。私のデータベースは、ビデオハッシュとブックマークを保存することが期待されています。
• ユーザーがファイルを移動または名前変更することがあります。私のプログラムは、ファイルが存在しないことを認識しますが、データベースからブックマークを削除しません。代わりに、同じビデオが（誤って）再度再生されたときに、（おそらく）同じファイルであることを認識したいと思います。
• ユーザーは、ネットワークドライブ（NAS）にファイルを保存し、ビデオをストリーミングする必要があります。それらはダムストレージです。サーバーコンポーネントをインストールできません。そして、それらはかなり遅いかもしれないので、私は本当に完全なハッシュを望んでいません。3 GBファイルのフルハッシュの計算には、ハッシュアルゴリズムの速度に関係なく、10 MB /秒で少なくとも5分かかります。
• ユーザーがファイルを編集した場合、どういうわけかハッシュが一致しないことを期待します。そうしないと、間違ったブックマークが表示されてしまうからです。

正しいブックマークを取得できる可能性は約80％です。ハッシュピースをいくつまとめて、ファイルのどこに配置すればよいですか？

コインには2つの側面があります。

1. 安全にしたい場合は、SHA256のような暗号的に安全なハッシュを使用する必要があります（暗号ハッシュは高速であることを意味しますが、セキュリティ上の制約により少し遅くなる傾向があります）。
2. CRCのようなものは間違いなく高速ですが、同じ種類のセキュリティを提供することはできません（特に、私たちが話している場合）。

オプション1：CRC —セキュリティを犠牲にして迅速に行う：

変更の検出直後の場合は、ハッシュではなくチェックサムを使用してください。これがチェックサムの目的です。ファイルまたはデータストリームの変更をすばやく検出します。ただし、CRCは悪意のあるアクションではなく、送信エラーを防止するように設計されていることに注意してください。

実際には、CRC32が最も明白な候補です（ただし、CRC8を追加した場合でも、何かが変更されたかどうかを検出し、CRCからそれ以外のものを期待しない場合にのみ機能します）。

オプション2：CRCを超えて—変更検出を強化しながら、かなり迅速に実行します。

他の有効なオプション（@ponchoのコメントを参照）は、実際に単に最終更新のタイムスタンプをです。

または、両方を組み合わせて（ボトルネックを回避するため）、次の疑似コードのようなものを使用します。

if(LastMod != knownLastMod) { CreateNewCRCandCompare(FileName, knownCRC) };

しかし、これは実際のセキュリティを提供しますか？いいえ。あなたにも同じことが言えます…

尾をチェックすることを検討する理由は次のとおりです。
-MP3にはタグ情報があります
-私が正しい場合、EXIFは最後にカスタムデータを追加します

繰り返しますが、それはあなたがどれだけのセキュリティを期待するかに依存します。誰もが（適切なRWファイルアクセス権を持つ）変更できるため、攻撃者は確実にファイルを操作して古いID3およびEXIFデータを保持（またはコピーアンドペースト）することを理解する必要があります。Last-Modificationのタイムスタンプ、フレームレート、解像度、最終変更日、さらには（ファイル）の長さについても同様です。その「追加の」および「変更可能な」データ（十分なファイルアクセス権を持つユーザーが変更および削除できる）によっては、セキュリティ上の欠陥が発生します。

しかし、あなたはセキュリティを期待していますね。結局のところ、それがそもそもこのすべてについて考えている理由です。さて、暗号化された安全なハッシュを使用する方法はありません…

オプション3：暗号で保護されたハッシュ—速度を犠牲にして安全に実行します。

実際のセキュリティを期待する場合は、ハッシュに依存する必要があります。より正確には：暗号的に安全なハッシュ（衝突を生成することが知られていないハッシュを使用）。時間はかかりますが（MBあたり数マイクロ秒）、それだけの価値があります。

私の2（個人）セント：

ハッシュには時間がかかり、暗号化された安全なハッシュを使用してファイル全体をハッシュするという事実を受け入れてください。なぜなら、物事がファンを襲い始めたとき...あなたは申し訳ないのではなく、遅くなる方がいいです。

自分の編集に基づいて編集…

暗号化セキュリティが主な焦点ではない場合は、MD5またはSHA1を検討できます。MD5とSHA1は、衝突が検出されたため「暗号解読」されていますが、変更検出の目的（特に編集後）では、このような衝突が発生する可能性は十分に低くなければなりません。

もう一度すべて（EDITを含む）を見ると、MD5を使用する可能性が高いです。MD5は、（変更検出の目的で）使用可能な衝突抵抗を提供しながら、マルチギガバイトのファイルを完全にハッシュするのに十分な速度を備えています。

それはまだ「スピード」の意味でかどうかを満たしていない場合は、ハードウェアのリソースが実際にあることを制限され、あなたが高速で衝突耐性/変更検出のバランスを取るために試してみて下さい。意味…

個々のタイムスタンプ、個々のファイル名、およびヘッダー（長さはメディアタイプと使用されるファイル形式によって異なります）と、中央からの適切なチャンクとテールの適切なチャンク（=ファイルの終わり）をハッシュします。これらの5つを組み合わせると、ほとんどのフィルターを大まかに除外できる

正しいブックマークを取得できる可能性は約80％です。ハッシュピースをいくつまとめて、ファイルのどこに配置すればよいですか？

トラック全体の詳細（メディアタイプ、ファイル形式、使用可能なリソース、予想される変更検出率、ファイルの類似性など）に依存するため、これは個人的な意見の詳細です。ハードウェアやソフトウェアのボトルネックに起因する期待、実装、ローカルな結果。

それでも、いくつかのガイダンスを提供しようと思います。

完全なファイルのハッシュが何らかの理由で選択肢にならない場合、私は–少なくとも–ヘッダー（およびおそらく数KB以上）、中間からの適切なチャンク（少なくとも「ヘッダーとcoのサイズ」 。”部分）、およびファイルの最後からの適切なチャンク（ここでも、少なくとも「header＆co。」部分のサイズ）。

投資できるリソースが多い（または投資する意思がある）ほど、取得できるチャンクが多くなったり、チャンクが大きくなったりする可能性があります。リソース/フィール/何でもまだ余裕があると思う場合は、ハッシュするチャンクのサイズを増やすか、ハッシュするチャンクの数を増やします。

チャンクの数を増やすのは簡単です。必要なことは、均等に分散することです（ファイルサイズをそれに応じて分割することで、ファイル全体の長さにわたって等間隔の部分から同じサイズのチャンクを抽出できます）。

また、「ランダムなチャンクの位置ではなく、なぜ均等に分散されるのか」と自問している場合、ランダムなチャンクの位置を選択すると、変更検出作業が事実上無効になる可能性があることに注意してください。通常は、検出しようとしている可能性を検出します。平等な分布を選択することは、簡単に言えば、より中立的です。

ショートカット

複数のファイルがあり、ファイルへの変更を検出する場合は、ファイルサイズと最終変更のタイムスタンプを使用します。

使用しているオペレーティングシステムがファイルの変更を検出する機能を提供している可能性があります。たとえば、Linuxではディレクトリへの変更の通知を取得できます。

完全なファイル処理

ファイルの実際の内容を読み取って、ファイルが変更されたかどうかを確認する必要がある場合は、実際の暗号化ハッシュを使用してください。CRCは、偽陰性を引き起こす可能性がかなりあります。SHA-256は非常に優れていますが、実際には、SHA-512は多くの最新プラットフォームで高速です。

多くのCPUコアがある場合は、ファイルのさまざまな部分のさまざまなハッシュを計算するか、ハッシュツリーを使用して処理を並列化すると便利です。

適切なハッシュを提案する理由は、いったん実際のファイルデータにアクセスすると、暗号処理はそれほど多くなく、代わりに、通常はディスクI / Oやネットワークパケットの送受信など、他の多くの低速な処理が行われるためです。

注：（少なくとも）小さいファイルの場合、ファイルの内容全体を保存し、ハッシュの代わりに内容を比較することもできます。

注2：ストレージが非常に限られている場合は、CRCまたは切り捨てられた暗号化ハッシュを選択することをお勧めします。CRC32はファイルごとに4バイトを使用し、SHA-256は32バイトです。4バイトの小さなタグは、編集を隠そうとする悪意のある試みから保護することができません。

部分的なファイル処理

ほとんどの場合、ファイル処理全体を使用することをお勧めします。

たぶん、これは数学の問題でしょうが、ファイルサイズ、ヘッド、テール、およびランダムデータの組み合わせを使用して変更を検出し、このクイックハッシュサムを生成する可能性はどのくらいありますか？

画像ファイルの場合、赤目を削除したり、口ひげや角を追加したりするなど、小さな編集を行うのが一般的です。JPG形式でのこれらの編集は、ファイルサイズに影響を及ぼさない場合があります（再圧縮のみを変更してJPGに変更を加えることができる編集プログラムを使用）エリア）またはあなたが言及する他の属性のいずれか。

ただし、ファイルの変更時間は通常影響を受けます。

ビデオファイルを検討する：多くのビデオフォーマットは一定のビットレートを生成します。固定ビットレートファイルの場合、途中のフレームが変更されると、ファイルサイズ、ヘッド、テールに表示されません。フレームを削除または追加すると、ほとんどの場合、サイズが異なります。

したがって、フィールドが検出されずに変更を取得する可能性は十分にあると思います。

このスキームで編集が検出される確率を推定することは非常に困難ですが、適切に検出されないビデオや画像の一般的な使用シナリオがあります。