我记得有个人告诉我，如果我让他改变4个字节，他可以让一个文件有他想要的任何校验和（CRC-32）。
我听说提到腌制哈希。我想知道是否有人将他的文件匹配我的文件会腌制MD5或SHA-1哈希更改结果，以便两个文件不再冲突？或者它只更改结束哈希值？
答案 0 :(得分：6)
您正在混合两种不同的哈希值用法：
检查以防止随机（非恶意）错误。
计算用于存储密码，签名消息，证书的加密消息摘要......
CRC是第一个应用程序的不错选择，但完全不适合第二个应用程序，因为它很容易计算碰撞（在数学上说：CRC是线性的）。这是你朋友基本上告诉你的。
MD5和SHA1是用于第二种应用的加密哈希。但是，MD5已被破解，SHA1最近被认为是弱的。尽管如此，即使MD5可以被破解，但需要很长时间才能找到MD5碰撞（几天到几周）。
对于salt，它通过混合一些随机的非机密值来计算加密散列本地，该值称为 salt 。这可以防止计算全局表，从而可以很容易地从散列值计算可能的值（例如密码）。表的计算非常昂贵，但如果没有盐，成本将通过许多破解的密码进行摊销。
答案 1 :(得分：4)
如果您使用的哈希值不是CRC-32，则攻击（针对CRC-32）无关紧要 - MD5和SHA-1不易受到此类攻击（尚未受到攻击）。
当前针对MD5的攻击是攻击者使用相同哈希创建两个文档的地方。
Salts用于密码验证 - 它们可以防止攻击者对密码数据库执行脱机攻击 - 每个用户的密码在散列之前都有一个附加到纯文本的盐 - 然后是预先计算的明文彩虹表＆lt; - ＆GT;散列文本是没用的。
答案 2 :(得分：1)
如果摘要函数已被泄露，则向哈希函数添加salt实际上并没有任何用途，因为必须公开盐才能使用，并且攻击者也可以调整其文件以将其考虑在内。
此问题的解决方案是使用安全散列函数。 MD5已经显示易受哈希冲突的影响，但我相信SHA-1还没有（到目前为止）。
答案 3 :(得分：0)
Salting通常用于密码哈希以避免字典攻击。有很多基于Web的反向哈希字典，您可以在其中输入哈希值（例如：1a79a4d60de6718e8e5b326e338ae533）并返回文本：“example”。用盐，这几乎是不可能的。如果您使用随机盐前置密码，则字典攻击会变得更加困难。
至于冲突，我认为您不必担心具有相同md5或sha1哈希的整个文件。这并不重要。哈希的重要用途是证明您收到的文件与文件权威人员批准的文件相同。如果向文件中添加salt，则需要发送salt，以便用户可以验证哈希值。
这实际上使得更容易攻击者欺骗您的文件，因为他可以提供假盐和假文件。用户通常可以判断文件是否伪造，因为它不再符合预期的目的。但是，用户应该如何知道正确的盐和攻击者的盐之间的区别呢？