24

私は、さまざまなオブジェクト (科学論文、標本、DNA 配列など) に関する情報を保存するデータベースを構築しています。これらのオブジェクトはすべてオンラインで存在し、URL やDOIなどの識別子で識別できます。 . これらの GUID をオブジェクトの主キーとして使用することは合理的な考えのようです。私は GUID の md5 ハッシュを使用する際に、deliciousとConnoteaに従いました。おいしいブックマークまたは Connotea ブックマークの編集ボタンまたは削除ボタンにマウスを合わせると、ブラウザーのステータス バーに md5 ハッシュが表示されます。たとえば、http://stackoverflow/のブックマークは

http://delicious.com/url/e4a42d992025b928a586b8bdc36ad38d

e4a42d992025b928a586b8bdc36ad38d ai はhttp://stackoverflow/の md5 ハッシュです。

このアプローチの長所と短所について意見を持っている人はいますか?

私にとって、このアプローチの利点は (データベース自体によって生成された自動インクリメント主キーを使用するのではなく)、オブジェクト間で多くのリンクを作成する必要があり、md5 ハッシュを使用することで、これらのリンクを外部のファイルに保存できることです。 （たとえば、データマイニング/スクレイピングの結果として）、それらをまとめてデータベースにインポートします。同様に、データベースを最初から再構築する必要がある場合、オブジェクトへの URL は変更されません。オブジェクトは md5 ハッシュを使用するためです。

これが賢明に聞こえるかどうか、またはこれを行う他の (より良い?) 方法があるかどうかについての考えを歓迎します。

4

7 に答える 7

12

全然大丈夫です。

MD5 の偶発的な衝突は、すべての実際的なシナリオでは不可能です (50% の衝突の可能性を得るには、毎秒60 億のURLを毎秒100 年間ハッシュする必要があります)。

実際の衝突が原因で発生するよりも、検出されないハードウェア障害が原因でデータが台無しになる可能性が 1 兆倍も高い可能性は非常にありそうにありません。

MD5 に対する既知の衝突攻撃がありますが、現在のところ、ハッシュされた URL に対する意図的な悪意のある衝突は不可能です。

  • 別の URL のハッシュと意図的に衝突させる必要があるタイプの衝突は、プレイメージ攻撃と呼ばれます。MD5 に対するプレイメージ攻撃は知られていません。2017 年の時点では、実現可能性にさえ近づいた研究はありません。そのため、十分な資金を備えた断固たる攻撃者でさえ、データベース内の既存の URL のハッシュにハッシュされる URL を計算することはできません。

  • MD5 に対する唯一の既知の衝突攻撃は、URL のようなキーへの攻撃には役に立ちません。これは、互いにのみ衝突するバイナリ ブロブのペアを生成することによって機能します。BLOB は比較的長く、NUL やその他の印刷できないバイトが含まれているため、URL のようなものに似ている可能性はほとんどありません。

于 2008-11-13T22:44:25.560 に答える
8

stackoverfowをもう少し閲覧した後、以前の質問を見つけました。この分野の多くをカバーするGUID/UUIDデータベースキーの長所と短所。

于 2008-10-21T09:02:22.503 に答える
1

複数の文字列で同じmd5ハッシュを生成できます。主キーは一意である必要があります。したがって、ハッシュを主キーとして使用するのは適切ではありません。GUIDを直接使用することをお勧めします。

URLでの使用に適したGUIDです。もちろん。これが、Javaを使用して作成したGUID（実際にはUUID）です：1ccb9467-e326-4fed-b9a7-7edcba52be84

URLは次のようになります。

http://example.com/view?id=1ccb9467-e326-4fed-b9a7-7edcba52be84

それは長いですが完全に使用可能であり、あなたが説明することを達成します。

于 2008-10-21T09:07:07.267 に答える
0

MD5 は非推奨と見なされます - 少なくとも暗号化の目的のためですが、既存のものとの下位互換性のためにのみ md5 を使用することをお勧めします。(少なくともまだ) 壊れていない他のハッシュ アルゴリズムがある場合、md5 を使用する十分な理由があるはずです。

このアプローチで見られる問題:

  • URL識別子が異なるため、オブジェクトが重複しています（前述のとおり）
  • URL の変更

重要なのは後者です。これは、削除と追加のように簡単に実行できます。つまり、これらの ID がデータベースの外部で表示/保存できない場合です。(URL の構成要素のように。)

これらは DOI にとっては問題にならないと思います。

autonumber 以外の整数 ID 設定ではどのように機能しますか?ただし、オフライン挿入エージェントが番号を作成する場所はどこですか? (専用の番号範囲を使用できますか?) 2 人のユーザーが別々に同じ URL を追加すると、重複の問題が発生する可能性がありますか?

于 2009-08-03T11:34:52.490 に答える
0

たぶん、このドキュメントはあなたが読みたいものです:

http://www.hpl.hp.com/techreports/2002/HPL-2002-216.pdf

于 2008-10-21T08:39:35.310 に答える
0

多くの場合、多くの異なる URL が同じページを指しています。 http://example.com/ example.com http://www.example.com/ http://example.com/index.html http://example.com/ . https://example.com/ など

これはあなたにとって問題になるかもしれませんし、そうでないかもしれません。

于 2008-10-21T08:49:32.387 に答える
-1

md5 ハッシュはほぼ一意ですが、完全に一意ではないため、主キーとして使用しないでください。暗号使用のために減価償却されます。キーの衝突の可能性は低くなりますが、数十億行の非常に大きなデータベースがある場合でも、衝突の可能性はいくらかあります。ハッシュを主キーとして使用することを主張する場合は、他のより良いハッシュを使用してください。主キーに一意でない値を使用することはできません。かなり大きなテーブルがある場合は、使用しないでください。テーブルが小さい場合は使用することもできますが、お勧めしません。

于 2016-02-27T04:57:01.880 に答える