在某些条件下加密哈希是否是单射的?

时间:2011-10-22 11:22:11

标签: language-agnostic hash checksum

对于冗长的帖子感到抱歉,我对常见的crpytographic哈希算法有疑问,比如SHA系列,MD5等。

通常,这种散列算法不能是单射的,因为产生的实际摘要通常具有固定长度(例如,SHA-1下的160位等),而要消化的可能消息的空间实际上是无限的。

但是,如果我们生成的消息摘要最多只要生成摘要,那么常用的散列算法的属性是什么?它们在这个有限的信息空间中是否可能是单独的?有没有算法,即使在比特长度比摘要的比特长度短的消息上也会产生冲突?

我实际上正在寻找一种算法,具有这个属性,即,至少在原则上,即使对于短输入消息,也可能产生冲突哈希值。

背景:我们有一个浏览器插件,对于访问过的每个网站,都会发出服务器请求,询问该网站是否属于我们的某个已知合作伙伴。但当然,我们不想窥探我们的用户。因此,为了难以生成某种冲浪历史记录,我们实际上并不发送访问过的URL,而是发送一些清理版本的哈希摘要(目前为SHA-1)。在服务器端,我们有一个众所周知的URI哈希表,它与收到的哈希值相匹配。我们在这里可能存在一定的不确定性,因为我们认为无法跟踪用户的功能,而不是错误。

由于显而易见的原因,这个方案非常模糊,并且承认误报以及不匹配的URI应该有。

所以现在,我们正在考虑将指纹生成更改为具有更多结构的内容,例如,而不是散列完整(已清理)的URI,我们可能会改为:

  1. 将主机名拆分为“。”的组件。并单独散列
  2. 检查“。”中组件的路径。并单独散列
  3. 将生成的哈希值加入指纹值。示例:使用此方案散列“www.apple.com/de/shop”(并使用Adler 32作为哈希)可能会产生“46989670.104268307.41353536 / 19857610/73204162”。

    然而,由于这样的指纹具有很多结构(特别是与普通的SHA-1摘要相比),我们可能会不小心再次计算用户访问的实际URI(例如,使用预先计算的“常用”compont值的哈希值表,例如“www”)。

    所以现在,我正在寻找一种哈希/摘要算法,即使在短消息上也会有很高的冲突率(Adler 32被认真考虑),因此给定组件哈希的唯一概率很低。我们希望,我们施加的额外结构为我们提供了足够的额外信息,以改善匹配行为(即,降低误报率/漏报率)。

3 个答案:

答案 0 :(得分:3)

对于与摘要大小相同的消息,我不相信哈希值是无效的。如果它们是,那么它们将是双射的,这将缺少哈希点。这表明它们对于小于摘要的消息也不是单独的。

如果你想鼓励碰撞,我建议你使用你喜欢的任何哈希函数,然后扔掉它,直到它碰撞到足够的。

例如,扔掉159位SHA-1哈希会给你一个相当高的冲突率。你可能不想扔那么多。

然而,你想要实现的目标本质上是可疑的。您希望能够告诉您网址是您的网址之一,而不是它是哪一个。这意味着您希望您的网址相互冲突,但不希望您的网址与您的网址冲突。哈希函数不会为您执行此操作。相反,因为碰撞将是随机的,因为有更多的URL不是你的(我假设!),任何给定的碰撞级别将导致对URL是否是你的一个或者不是你的URL的混淆。你的哪一个。

相反,如何在启动时将URL列表发送到插件,然后让它只返回一个位,指示它是否正在访问列表中的URL?如果您不想显式发送URL,请发送哈希值(不尝试最大化冲突)。如果您想节省空间,请发送Bloom filter

答案 1 :(得分:1)

由于您愿意接受误报率(即,实际上未被识别为白名单的随机网站),Bloom filter可能就是这样。

每个客户端都会下载包含整个白名单的Bloom过滤器。然后客户端无需与服务器通信,也没有间谍风险。

每个网址2个字节,误报率低于0.1%,每个网址4个字节低于1/4百万。

下载整个过滤器(可能还会对其进行定期更新)是预先大量的带宽投资。但是假设它上面有一百万个URL(这对我来说似乎很多,考虑到你可以在查找之前应用一些规则来规范化URL),这是一个4MB的下载。将其与一百万个32位哈希的列表进行比较:大小相同,但误报率约为4千分之一,因此布隆过滤器会因紧凑而获胜。

我不知道插件是如何与服务器联系的,但是我怀疑你可以在1kB以下完成一个HTTP事务 - 或许更少的保持活动连接。如果过滤器更新频率低于给定用户每4k URL访问次数(或者如果少于一百万个URL,则为较小的数字,或者在400万个误报概率中大于1),这有可能使用 带宽比当前方案少,当然泄漏的信息少得多。

如果您需要立即将新网址列入白名单,它也不能正常工作,不过我认为客户端仍然可以在每个页面请求时点击服务器,检查过滤器是否已更改,如果是,请下载更新补丁

即使Bloom过滤器太大而无法完全下载(也许是因为客户端没有持久存储且RAM有限),我认为你仍然可以通过让客户端计算哪些位来引入一些信息隐藏它需要查看的Bloom过滤器,并要求服务器中的那些过滤器。在客户端中使用缓存的组合(缓存过滤器的比例越高,需要的位数越少,因此告诉服务器的次数越少),请求关注您所关注的实际位的窗口(因此,您不会告诉服务器您需要哪个位,并且客户端要求它实际上不需要虚假位(隐藏噪声中的信息),我希望您可以模糊您正在访问的URL。然而,需要进行一些分析才能证明其实际有效:一个间谍的目标是在您的请求中找到与浏览特定网站相关的模式。

答案 2 :(得分:0)

我的印象是您确实需要public key cryptography,其中您向访问者提供用于对URL进行编码的公钥,并使用密钥解密URL。

JavaScript implementations一点everywhere