我正在构建一个数据库，用于存储一系列对象(例如科学论文、标本、DNA 序列等)的信息，这些对象都存在于网上并且可以通过 URL 或诸如此类的标识符进行识别作为DOI .使用这些 GUID 作为对象的主键似乎是一个合理的想法，我已经关注了 delicious和 Connotea使用 GUID 的 md5 散列。如果将鼠标悬停在 delicious 或 Connotea 书签中的编辑或删除按钮上，您将在浏览器状态栏中看到 md5 哈希。例如，http://stackoverflow/ 的书签是
http://delicious.com/url/e4a42d992025b928a586b8bdc36ad38d
其中 e4a42d992025b928a586b8bdc36ad38d a 是 http://stackoverflow/ 的 md5 哈希值.
有人对这种方法的优缺点有看法吗？
对我来说，这种方法(与使用数据库本身生成的自动递增主键相反)的一个优点是我必须在对象之间做很多链接，并且通过使用 md5 哈希，我可以在外部存储这些链接在一个文件中(例如，作为数据挖掘/抓取的结果)，然后将它们批量导入到数据库中。同样，如果必须从头开始重建数据库，则对象的 URL 不会更改，因为它们使用 md5 哈希。
我欢迎就这听起来是否合理，或者是否有其他(更好的？)方法来提出任何想法。
最佳答案
完全没问题。
MD5 的意外冲突在所有实际场景中都是不可能的(要获得 50% 的冲突机会，您必须每秒散列 6 十亿 URL，每秒, 100 年)。
由于未检测到的硬件故障导致数据困惑的可能性比实际碰撞导致数据困惑的可能性高出万亿倍，这种可能性微乎其微。
即使存在针对 MD5 的已知碰撞攻击，但目前不可能针对哈希 URL 进行故意的恶意碰撞。
您需要故意与另一个 URL 的哈希冲突的冲突类型称为原像 攻击。没有已知的针对 MD5 的原像攻击。截至 2017 年，还没有接近可行性的研究，因此即使是资金雄厚的坚定攻击者也无法计算出一个 URL，该 URL 将散列为数据库中任何现有 URL 的散列。
唯一已知的针对 MD5 的碰撞攻击对攻击类似 URL 的 key 没有用处。它的工作原理是生成一对仅相互碰撞的二进制 Blob 。 blob 将相对较长，包含 NUL 和其他不可打印的字节，因此它们极不可能与 URL 类似。
关于database - 使用 URI 的 md5 散列作为数据库主键的优缺点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/221165/