リンク先のブログで書かれているコリジョンの確率の数字って、誕生日コリジョンは考慮されてないんですね。ブログに対するコメントのほうで書かれてますけど。 まあ、それでも普通のデータ量なら心配しなくていいほどに2^256は広い空間だし、どうしても心配な人は zfs set dedup=verify tank すればいいのか。
>設定で zfs set dedup=verify tank とすれば、「ハッシュ値が同じ」だけでなくちゃんとビットイメージまで等しいかをチェックしてくれるので、心配性な人はそれを利用すればいいですよ、とブログにはあります。 >実際にコリジョンがあった場合にどうなるのかは分かりません。記録できないのかな？ ハッシュ値が同じならdiff取ると言うことであれば、同じ／違うの区別は明確にできると思うので大丈夫じゃない？ #それ否定されたらオイラが昔MD5で作った仕組み否定されかねない、業務の主目的じゃなかったから無くても支障無いはずだけど（笑）
衝突の確率はもっと高いような気がするです (スコア:3, 興味深い)
リンク先のブログで書かれているコリジョンの確率の数字って、誕生日コリジョンは考慮されてないんですね。ブログに対するコメントのほうで書かれてますけど。
まあ、それでも普通のデータ量なら心配しなくていいほどに2^256は広い空間だし、どうしても心配な人は zfs set dedup=verify tank すればいいのか。
# SHA256ってまだコリジョン見つかってないんでしたっけ。
Re: (スコア:1)
Re: (スコア:3, 参考になる)
すいません、「誕生日のパラドックス [wikipedia.org]」「誕生日問題」のほうが一般的な呼び方でした。（攻撃に使う場合は「誕生日攻撃」）
リンク先のブログのコメント欄では、birthday problem なんて書かれています。しかし、これ計算が間違っていそう。
Re: (スコア:4, 興味深い)
# 書き忘れました。
リンク先のブログだと、「SHA256のようなセキュアなハッシュを使うときは、コリジョンの可能性は 1/2^256 または 1/10^77 」と書かれています。恐ろしく小さな確率で安全、安心。
が、任意のデータとなにか他のデータのハッシュ値が一致（衝突、コリジョン）してしまう確率としてはそれは正しいですが、ここではZFSで大量に扱う全てのデータどうしでコリジョンしないことが求められるので、正しくは誕生日問題のほうの確率でみないといけないんじゃない？ …と、いう話です。で、そのあたりもブログに対するコメントで既出なのですが、そこにある計算は間違っていそうです。
Re: (スコア:0)
>設定で zfs set dedup=verify tank とすれば、「ハッシュ値が同じ」だけでなくちゃんとビットイメージまで等しいかをチェックしてくれるので、心配性な人はそれを利用すればいいですよ、とブログにはあります。
>実際にコリジョンがあった場合にどうなるのかは分かりません。記録できないのかな？
ハッシュ値が同じならdiff取ると言うことであれば、同じ／違うの区別は明確にできると思うので大丈夫じゃない？
#それ否定されたらオイラが昔MD5で作った仕組み否定されかねない、業務の主目的じゃなかったから無くても支障無いはずだけど（笑）
Re: (スコア:2)
だとすると、衝突フラグみたいなものをキーに含めておく、というところですかねえ。
いや、なんでこんなに気にしているかというと、私もSHA256で同じようなことやっているからです。（ブロック単位はやりたいけど重過ぎるので、ファイル単位）
もちろんコリジョンにはノーガード戦法ですよー。（・∀・）
Re: (スコア:1)
ファイル単位で処理してると、「ファイルサイズ」もキーにすれば、もうちょっと衝突確率は減るんじゃないでしょうか。
まあ、ファイルサイズなんてせいぜい32bitで、256bit→288bitになる程度ですが…
私の自作バックアップソフトでは、リネームしたファイル検出のために、
ファイルサイズをキーにしたstd::map内に、MD5をキーにしたstd::mapを入れてました。
32bitの数値比較で先に絞り込んだ方が検索が速いって理由だったかな。←そういや、4GB超のファイルのことは考えてなかったなぁ…
あと、ファイル冒頭の何バイトかについても比較対象のキ
Re:衝突の確率はもっと高いような気がするです (スコア:1)
ZFS 的には 32bit なんてファイルサイズを前提にするのは極めて「おいしくない」と思うんですが……。
下位 32bit だけってことでしょうか。今時 OS の DVD ISO イメージでも 4GB 超とか普通にあったりすると思うんですけど。