2

我知道原始的 md5 算法会产生一个 128 位的散列。

在 Mark Adler 的评论之后我有兴趣获得一个好的 64 位哈希。有没有办法使用 OpenSSL 创建基于 md5 的 64 位哈希?(md5 看起来足以满足我的需求)。如果没有,OpenSSL 库中是否有另一种算法可以以不低于 md5 的质量完成这项工作(当然长度除外)?

4

1 回答 1

2

我声称,“哈希质量”与哈希长度密切相关。AFAIK,OpenSSL 没有 64 位哈希算法,所以我的第一个想法很简单,而且很可能毫无价值:

halfMD5 = md5.hiQuadWord ^ md5.lowQuadWord

最后,我会简单地使用具有适当输出的算法,例如 crc64。

一些需要验证的 crc64 来源:


编辑

乍一看,Jenkins 看起来很完美,但是到目前为止,我正试图为它找到一个友好的 c++ 实现,但没有运气。顺便说一句,我想知道,既然这对于数据库的重复检查来说是一个很好的哈希,那么为什么非公共开源库(如 OpenSSL)提供了它的 API?- 地铁

这可能仅仅是因为 OpenSSL 首先是一个加密库,它使用具有适当加密特征的大哈希值。

数据结构的散列算法还有其他一些主要目标,例如散列表的良好分布特性,其中小的散列值用作包含零、一个或多个(冲突)元素的桶列表的索引。

所以关键是,是否、如何以及在何处处理碰撞。在典型的 DBMS 中,列上的索引将自行处理它们。

对应的容器(地图或集合):

唯一约束将另外禁止插入相等的字段内容:


例如,我们有一个表,其中包含文件内容(明文、非加密应用程序)和用于映射或一致性检查的校验和或哈希值。我们要插入一个新文件。为此,我们预先计算哈希值或校验和,并分别查询具有相等哈希值或校验和的现有文件。如果不存在,则不会发生冲突,插入将是安全的。如果存在一个或多个现有记录,则完全匹配的概率很高,而“真实”冲突的概率较低。

  • 如果应该省略冲突,可以向哈希列添加唯一约束并重用现有记录,但可能会出现不匹配/冲突的内容。在这里,您需要一个数据库友好的哈希算法,例如“Jenkins”。

  • 如果需要处理冲突,可以向明文列添加唯一约束。像 crc 这样对数据库不太友好的校验和算法不会对记录之间的冲突产生影响,并且可以根据要检测的某些类型的损坏或其他要求进行选择。甚至可以使用开头提到的 md5 的异或四字。

其他一些想法:

  • 如果明文列上的索引/约束进行映射,则可以使用任何哈希值进行合理快速的查找以找到潜在的匹配项。
  • 没有人会阻止您同时添加映射友好的哈希和校验和。
  • 唯一约束还会添加一个索引,基本上就像上面提到的哈希表。

简而言之,这在很大程度上取决于您想要使用 64 位哈希算法实现什么。

于 2013-03-17T10:03:50.407 回答