使用URI的md5哈希作为数据库中的主键的优缺点

我正在构建一个数据库,该数据库将存储一系列对象(例如科学论文,标本,DNA序列等)的信息,这些对象都在线存在并且可以通过URL或诸如DOI的标识符来识别.使用这些GUID作为对象的主键似乎是一个合理的想法,我跟随美味和Connotea使用GUID的md5哈希.如果将鼠标悬停在美味或Connotea书签上的编辑或删除按钮上,您将在浏览器状态栏中看到md5哈希值.例如,http:// stackoverflow /的书签是

http://delicious.com/url/e4a42d992025b928a586b8bdc36ad38d

其中e4a42d992025b928a586b8bdc36ad38d是http:// stackoverflow /的md5哈希值.

有没有人对这种方法的利弊有看法？

对我来说,这种方法的优势(与使用由数据库本身生成的自动递增主键相反)是我必须在对象之间进行大量链接,并且通过使用md5哈希,我可以将这些链接外部存储在文件中(比如,作为数据挖掘/抓取的结果),然后将它们批量导入数据库.同样,如果必须从头开始重建数据库,则对象的URL不会更改,因为它们使用md5哈希.

我会欢迎任何关于这听起来是否明智的想法,或者是否还有其他(更好的？)方法.

这很好.

在所有实际情况下,MD5的意外碰撞是不可能的(为了获得50%的碰撞几率,你必须每秒散布60 亿个 URL ,每秒钟,100年).

这是一个不太可能的机会,由于未检测到的硬件故障比实际碰撞导致数据混乱的可能性高出几倍.

即使存在针对MD5的已知冲突攻击,目前也不可能针对散列URL进行故意的恶意冲突.

您需要故意与另一个URL的哈希冲突的冲突类型称为前映像攻击.没有已知的针对MD5的前映像攻击.截至2017年,没有任何研究甚至接近可行性,因此即使是一个资金充足的攻击者也无法计算一个会散列到数据库中任何现有URL的哈希值的URL.

对MD5唯一已知的碰撞攻击对于攻击类似URL的密钥没有用.它的工作原理是生成一对只相互碰撞的二进制blob .blob将相对较长,包含NUL和其他不可打印的字节,因此它们极不可能像URL一样.

在浏览stackoverfow之后,我发现了一个早期问题GUID/UUID数据库密钥的优点和缺点,它涵盖了很多这方面的内容.