是什么使哈希算法“安全”？

19

阅读了这个有趣的问题之后，我觉得我对如果需要使用哪种不安全的哈希算法有了一个很好的了解，但不知道为什么我可能会改用安全算法。

那有什么区别呢？输出不只是代表散列对象的随机数吗？是什么使某些哈希算法安全？

security  hashing 
— 食品法典
source
8
这个问题更适合IT Security SE网站。
— 伯纳德
@Bernard如果是这种情况，那我很好，但是我的问题不是真正关于如何或何时使用安全哈希，而是什么使安全哈希算法与不安全算法区分开来。在我看来，这似乎是一个编程问题，但是我没有浏览IT Security SE，所以也许在那也行得通。
— CodexArcanum 2012年
2
关于IT安全性，已经提出了一个非常类似的问题
— ChrisF

Answers:

34

每个加密哈希函数都需要三个属性H：

  • 前像性：给定h，应该是很难找到的任何值x有h = H(x)。

  • 第二原像电阻：考虑到x1，应该很难找到x2 != x1有H(x1) = H(x2)。

  • 抗碰撞性：它应该是很难找到两个值x1 != x2与H(x1) = H(x2)。

使用在（字符串的）哈希表的通用编程语言中使用的哈希函数，通常不给出任何哈希表，它们仅提供：

  • 弱的耐碰撞性：对于随机（或“通常”）选择的域值，碰撞的机会很小。这没有说明攻击者有意尝试创建冲突或试图查找原像。

上面的三个属性是（每个）加密哈希函数的设计目标。对于某些功能（例如MD4，SHA-0，MD5），已知此操作失败（至少部分失败）。假定当前的一代（SHA-2）是安全的，并且在竞赛之后，下一代（SHA-2）目前正在标准化过程中。

对于某些用途（例如密码哈希和从密码派生的密钥），实际使用的值的域x是如此之小，以至于使用常规（快速）安全哈希函数可以强行强制使用此空间，而此时我们还希望：

  • 缓慢执行：给定的情况下x，它需要一些最少（最好是可配置）的资源来计算该值H(x)。

但是对于大多数其他用途，这是不想要的，而是想要：

  • 快速执行：给定x，计算的值H(x)是尽可能快的（同时仍然安全）。

有一些构造（例如PBKDF2和scrypt）可以通过经常迭代从快速函数创建慢速哈希函数。

有关更多详细信息，请查看我们的姊妹网站Cryptography Stack Exchange上的hash标签。

— 帕洛·埃伯曼
source
3

安全意味着某人想要通过使用冲突来使您陷入错误（即，两个源被散列为相同值的事实）将会遇到困难。

一些特点：

  • 知道哈希值，很难建立一个哈希值达到该值的文件（变体，将给出新文件的一部分以及所需的哈希值）

  • 构建两个散列为相同值的不同文件很困难（变体，给出了部分文件）

— 程序员
source
3

主要区别非常简单：普通散列是为了最大程度地减少意外冲突的数量，以至于在不降低整个过程速度的前提下，可以做到这一点。

一种安全的散列，旨在防止冲突，即使有人尽力引起冲突。你一般不希望交易的任何碰撞的可能性更快的操作。实际上，故意使操作变慢本身具有一些安全好处，即使不会使发现冲突变得更加困难。

对于后者的示例：如果计算哈希值需要50毫秒，则它对普通用户的登录不会产生实质性影响（即，大多数用户登录时不会注意到50毫秒的差异）。同时，如果攻击者想进行字典攻击，那么每秒只能产生20个散列是一个严重的障碍。换句话说，出于某种原因，对于安全哈希，越慢越好。

— 杰里·科芬
source
3
在密码散列函数的领域中，有两个重要的子组：快速子组（用于消息身份验证，签名等），和慢速子组-用于密钥派生和密码散列。不要混合使用，两者都有应用程序。
— 圣保罗Ebermann
实际上，还有一些散列函数旨在使冲突最大化：Soundex是一个示例。显然，这使它成为非常糟糕的安全哈希函数。
— 约尔格W¯¯米塔格
@JörgWMittag：不仅因为安全的哈希值而cr脚，而且与哈希表一起使用也很差。再说一次，虽然肯定有点像散列，但我还是犹豫将Soundex称为散列函数，只是因为它的意图和用途与普通散列函数完全不同。
— 杰里·科芬
@JerryCoffin：我想这取决于定义。例如，英文Wikipedia页面仅说哈希函数是将较大的（可能无限）任意值映射为较小的有限（通常是标量）值的算法或子例程。而德语Wikipedia页面上说“哈希”（德语：“ zerhacken”）是必不可少的部分，即避免冲突和映射值的分布是关键。Soundex非常满足第一个定义，但不满足第二个定义。
— 约尔格W¯¯米塔格
3

阅读此http://www.codinghorror.com/blog/2012/04/speed-hashing.html，它将比我能解释的要好得多。这是本文中两个最重要的标题，它们直接解决了您的问题：

  • 安全哈希被设计为防篡改
    • 只需一点点更改输入数据就可以从根本上改变其输出
  • 安全哈希被设计为缓慢

最后是他的TL; DR部分：

如果您是用户：

确保您所有的密码都是12个字符或更多，最好是更多。我建议采用密码短语，它不仅比密码（如果不是键入密码）更容易记住，而且由于其长度太短，因此可以防止暴力破解。

如果您是开发人员：

专门使用bcrypt或PBKDF2可以对需要保护的所有内容进行哈希处理。这些新的哈希值经过专门设计，难以在GPU上实现。不要使用任何其他形式的哈希。几乎所有其他流行的哈希方案都容易受到商品GPU阵列的暴力破解，而这种GPU每年只会变得更快，更并行，更易于编程。

— 内特
source
4
杰夫在第二点上错了……而对于某些用途（例如密码哈希和从密码派生的密钥），您希望变慢；对于其他用途（如消息身份验证，签名等），则要快（安全）。哈希函数很好。
— 圣保罗Ebermann
您是正确的Paŭlo。哈希的性能取决于哈希的应用。但是，慢速哈希总是比快速哈希更安全。使用快速哈希的原因是如果您可以牺牲性能的安全性。
— Nate 2012年
2
@Nate“更安全”始终是模棱两可的，但是即使在最慈善的应用程序中，“慢散列总是比快速散列更安全”是绝对错误的。在许多应用程序中，哈希的速度无关紧要。
— 吉尔斯（Gilles）'所以
@吉尔斯你能举个例子吗？这对我来说确实听起来很真实，但是更多细节会有所帮助。
— Nate 2012年
2
@Nate哈希的最明显的应用是验证数据的完整性：通过安全但可能是低带宽的通道传输哈希，通过不安全的通道传输可能较大的有效负载，然后检查接收到的有效负载是否具有预期的哈希。哈希在签名方法中也很重要（在此方法中，您不仅要验证完整性，而且要验证谁向您发送数据）。哈希密码是个例外。
— 吉尔斯（Gilles）'所以
2

“安全”散列是一种散列，如果没有用于创建散列的消息的先验知识，则认为难以以公式化，可复制的方式“欺骗”散列。由于该信息通常是秘密的，因此需要散列，因此这是旨在用于身份验证的散列函数的良好特性。

如果在给定消息M，哈希函数hash（）和hash（M）产生的哈希值H（长度为比特L）的情况下执行以下任何一项操作，则通常认为哈希是“安全的” O（2 L）时间：

  • 给定hash（）和H，产生M（原像电阻）
  • 给定hash（）和M，则产生一个不同的M 2，使得hash（M 2）==H。（抗弱碰撞）
  • 给定hash（），产生任何M 1和M 2，使得hash（M 1）== hash（M 2）。（抗碰撞能力强）

此外，“安全”哈希必须具有哈希长度L，使得2 L计算机执行给定当前硬件的可行步骤数不可行。一个32位整数散列只能有21亿个值。前映像攻击（查找产生特定哈希值H的消息）可能需要一段时间，但对于许多计算机而言，尤其是在政府机构授权破损代码的计算机中，这并非不可行。此外，根据概率，创建和存储随机消息及其哈希的算法将在尝试仅77,000条消息后，为每条新消息查找重复的散列有50％的机会，并且有75％的机会碰到仅在110,000之后重复。在尝试大约50亿个值之后，即使是64位哈希也仍然有50％的机会发生冲突。这就是生日攻击小哈希的力量。相比之下，十亿个数字（1.5 * 10 34）。

大多数证明的对加密哈希的攻击都是冲突攻击，并且证明了能够在不到2 L的时间内生成冲突消息的能力（大多数仍然是指数时间，但是将指数减少一半可显着降低复杂度，因为它使256位哈希像128位一样容易解决，128位哈希像64位一样容易解决，等等）。

除了较小的哈希值之外，其他可能导致哈希值明显不安全的因素还有：

低工作量-设计供哈希表使用或用于其他“校验和”类型目的的哈希通常设计为在计算上不昂贵。这使得暴力攻击变得容易得多。

“粘滞状态”-散列函数易于产生输入模式，其中当给定特定的附加输入字节时，到目前为止，所有输入的当前散列值不会更改。具有“粘性状态”使冲突易于查找，因为一旦识别出产生“粘性状态”哈希的消息，通过附加使哈希保持其“粘性状态”的输入字节，生成具有相同哈希值的其他消息就变得很简单。 ”。

扩散-消息的每个输入字节都应以同样复杂的方式分布在散列值的字节之间。某些哈希函数会对哈希中的某些位产生可预测的变化。这再次使碰撞创建变得微不足道；在给定产生散列的消息的情况下，可以通过向消息引入仅影响可预测变化的位的新值来轻松创建冲突。

— 基思
source
0

对即将完成的任务使用正确的算法。

CRC用于错误检测/纠正。

诸如SHA2之类的加密消息摘要被用作加密构造（数字签名，MAC，密钥派生/密码散列函数）和安全协议的构造块。

在哈希表/字典/地图中使用SipHash。

正如以下CVE条目所证明的，不应在哈希表中使用所谓的不安全哈希算法：CVE-2003-0364，CVE-2011-4461，CVE-2011-4838，CVE-2011-4885，CVE-2011- 4462，CVE-2011-4815，CVE-2012-0840，CVE-2012-5371，CVE-2012-5374，CVE-2012-5375

— 尔万·莱格朗
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.