ファイルチャンクハッシュ値とファイルフィンガープリントの結合

Question

サーバー内のすべてのアップロードファイルに対してファイルフィンガープリントが必要です。さて、sha256がハッシュ関数として選択されました。

大きなファイルの場合、各ファイルは転送するファイルサイズが同じファイルサイズ（最後のものを除く）に分割されます。各ファイルチャンクのsha256値はクライアントによって提供されます。それらはサーバーによって再計算され、チェックされます。

ただし、これらの値をファイル全体のsha256値に組み合わせることはできません。

だから私は、ファイルの指紋の定義変更を検討：1GB未満のファイルの場合は

を、SHA256値は、指紋です。

1GBを超えるファイルの場合、1GBのチャンクにスライスされます。各チャンクは、s0、s1、s2（すべて整数値）と表示された独自のsha256値を持ちます。

h0 = s0

を第二のチャンクこれは本質的に2つのハッシュ値を連結して再度ハッシュである

h1 = SHA256(h0 << 256 + s1)

を受信した場合：最初のチャンクが受信

。このプロセスは、すべてのチャンクが受信されるまで繰り返されます。そして、最終的な値hnがファイルフィンガープリントとして使用されます。私はGoogleで検索している

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ロット。そして、さまざまな言語やフレームワークのcombine_hash関数に関するいくつかの記事を読んでください。異なる著者が異なるビットマングリングハッシュ関数を選択し、それらのほとんどがうまく機能していると言われています。

しかし、私の場合、効率は問題ではありません。しかし、指紋は、システム全体のファイル内容識別子として格納され、使用される。

上記の単純な方法でsha256自体よりも多くの競合が導入されるのではないかと心配していますか？

sha256がこのケースでハッシュ値を組み合わせるのに適していない場合は、推奨事項はありますか？

Answer 1

あなたは本質的にMerkle treeを再発明しています。

大容量のファイルを同じサイズのチャンク（最後の断片化されていない）に分割し、それらのチャンクごとにハッシュを計算し、最終的なハッシュ値が1つになるまでペアごとに結合します。 の "ルート"ハッシュは、元のファイルのハッシュと同じではありませんが、ファイル全体の整合性を検証する必要はありません。はではありません。