故意创建两个文件以具有相同的哈希值？
如果有人故意尝试修改两个文件以具有相同的哈希值，有什么方法可以阻止他们？ md5和sha1可以防止大多数情况吗？
我正在考虑编写自己的哈希值，我想即使我做得不好，如果用户不知道我的哈希值，他也可能无法欺骗我的哈希值。
防止这种情况的最佳方法是什么？
If someone is purposely trying to modify two files to have the same hash, what are ways to stop them? Can md5 and sha1 prevent the majority case?
I was thinking of writing my own and I figure even if I don't do a good job if the user doesn't know my hash he may not be able to fool mine.
What's the best way to prevent this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果哈希冲突是主要问题，则 MD5 通常被认为是不安全的。 同样，SHA1 不再被美国政府视为可接受。
is正在进行竞赛，以寻找替代哈希值算法，但目前建议使用 SHA2 系列 - SHA-256、SHA-384 或 SHA-512。 [更新：2012 年 10 月 2 日 NIST 已选择 < a href="http://en.wikipedia.org/wiki/Keccak" rel="noreferrer">SHA-3 为算法 Keccak.]您可以尝试创建自己的哈希值 - 它可能不如 MD5，并且“通过模糊实现安全性”同样不可取。
如果您想要安全性，请使用多种哈希算法进行哈希。 能够使用多种算法同时创建具有哈希冲突的文件是极其不可能的。 [并且，根据评论，让我明确表示：我的意思是发布文件的 SHA-256 和 Whirlpool 值 - 不是组合哈希算法来创建单个值，而是使用单独的算法来创建单独的值。 通常，损坏的文件将无法匹配任何算法； 如果有人成功地使用一种算法创建了碰撞值，则在其他算法之一中产生第二次碰撞的机会可以忽略不计。]
公共时间戳使用一系列算法。 例如，请参阅 sqlcmd-86.00。 tgz 为例。
MD5 is generally considered insecure if hash collisions are a major concern. SHA1 is likewise no longer considered acceptable by the US government. There
iswas a competition under way to find a replacement hash algorithm, but the recommendation at the moment is to use the SHA2 family - SHA-256, SHA-384 or SHA-512. [Update: 2012-10-02 NIST has chosen SHA-3 to be the algorithm Keccak.]You can try to create your own hash — it would probably not be as good as MD5, and 'security through obscurity' is likewise not advisable.
If you want security, hash with multiple hash algorithms. Being able to simultaneously create files that have hash collisions using a number of algorithms is excessively improbable. [And, in the light of comments, let me make it clear: I mean publish both the SHA-256 and the Whirlpool values for the file — not combining hash algorithms to create a single value, but using separate algorithms to create separate values. Generally, a corrupted file will fail to match any of the algorithms; if, perchance, someone has managed to create a collision value using one algorithm, the chance of also producing a second collision in one of the other algorithms is negligible.]
The Public TimeStamp uses an array of algorithms. See, for example, sqlcmd-86.00.tgz for an illustration.
如果用户不知道您的哈希算法，他也无法验证您在实际签署的文档上的签名。
最好的选择是使用生成最长哈希值的公钥单向哈希算法。 SHA-256 创建一个 256 位哈希，因此伪造者必须（平均）尝试 2255 个不同的文档，然后才能创建与给定文档匹配的文档，这是非常安全的。 如果这对您来说仍然不够安全，还有 SHA-512。
另外，我认为值得一提的是，保护自己免受伪造数字签名文档侵害的一种低技术含量的好方法是简单地保留您签名的任何内容的副本。 这样，如果出现争议，您可以证明您签署的原始文件已被更改。
If the user doesn't know your hashing algorithm he also can't verify your signature on a document that you actually signed.
The best option is to use public-key one-way hashing algorithms that generate the longest hash. SHA-256 creates a 256-bit hash, so a forger would have to try 2255 different documents (on average) before they created one that matched a given document, which is pretty secure. If that's still not secure enough for you, there's SHA-512.
Also, I think it's worth mentioning that a good low-tech way to protect yourself against forged digitally-signed documents is to simply keep a copy of anything you sign. That way, if it comes down to a dispute, you can show that the original document you signed was altered.
这里有一个难度等级（对于攻击者来说）。 找到两个具有相同哈希值的文件比生成一个匹配给定哈希值的文件更容易，如果您不必遵守形式/内容/长度限制，则后者更容易做到。
因此，如果可以使用定义良好的文档结构和长度，那么无论您使用什么底层哈希，都可以让攻击者的生活变得更加困难。
There is a hierarchy of difficulty (for an attacker) here. It is easier to find two files with the same hash than to generate one to match a given hash, and easier to do the later if you don't have to respect form/content/lengths restrictions.
Thus, if it is possible to use a well defined document structure and lengths, you can make an attackers life a bit harder no matter what underling hash you use.
你为什么要尝试创建自己的哈希算法？ SHA1HMAC 有什么问题？
是的，哈希值有重复。
任何比明文短的哈希值必然会减少信息。 这意味着会有一些重复。 哈希的关键是重复很难进行逆向工程。
考虑 CRC32——通常用作哈希。 这是一个 32 位的数量。 因为宇宙中有超过2^32条消息，那么就会出现CRC32的重复。
同样的想法也适用于其他哈希。
Why are you trying to create your own hash algorithm? What's wrong with SHA1HMAC?
Yes, there are repeats for hashes.
Any hash that is shorter than the plaintext is necessarily less information. That means there will be some repeats. The key for hashes is that the repeats are hard to reverse-engineer.
Consider CRC32 - commonly used as a hash. It's a 32-bit quantity. Because there are more than 2^32 messages in the universe, then there will be repeats with CRC32.
The same idea applies to other hashes.
这称为“哈希冲突”，避免这种情况的最佳方法是使用强哈希函数。 MD5 相对容易人为构建冲突文件，如此处所示。 同样，我们知道有一种相对有效的计算方法冲突的 SH1 文件，尽管在这种情况下“相对有效”仍然需要数百小时的计算时间。
一般来说，MD5 和 SHA1 的破解成本仍然很高，但并非不可能。 如果您真的很担心，请使用更强的哈希函数，例如 SHA256。
除非您是一位非常专业的密码学家，否则自己编写实际上并不是一个好主意。 大多数简单的想法都已被尝试过，并且存在针对它们的众所周知的攻击。
如果您确实想了解更多信息，请查看 Schneier 的应用密码学。
This is called a "hash collision", and the best way to avoid it is to use a strong hash function. MD5 is relatively easy to artificially build colliding files, as seen here. Similarly, it's known there is a relatively efficient method for computing colliding SH1 files, although in this case "relatively efficient" still takes hunreds of hours of compute time.
Generally, MD5 and SHA1 are still expensive to crack, but not impossible. If you're really worried about it, use a stronger hash function, like SHA256.
Writing your own isn't actually a good idea unless you're a pretty expert cryptographer. most of the simple ideas have been tried and there are well-known attacks against them.
If you really want to learn more about it, have a look at Schneier's Applied Cryptography.
我认为提出自己的哈希算法不是一个好的选择。
另一个不错的选择是使用Salted MD5。 例如，MD5 哈希函数的输入在传递给 MD5 函数之前会附加字符串“acidzom!@#”。
Slashdot 上也有很好的读物。
I don't think coming up with your own hash algorithm is a good choice.
Another good option is used Salted MD5. For example, the input to your MD5 hash function is appended with string "acidzom!@#" before passing to MD5 function.
There is also a good reading at Slashdot.