问题标签 [md5]

我正在运行一些我用 C 编写的代码，它从其他人编写的散列库（md5.c 和 md5.h）中调用 md5 散列功能。我看到的奇怪行为是：

散列工作完美=我散列一个字符串，它得出的确切散列是我已经验证它与多个其他来源的确切散列。

1. 在我的 OSX 机器上编译和运行时，散列功能可以完美运行，并且计算出的散列完全符合其应有的状态。

2. 相同的代码，在基于 Linux 的服务器上上传和编译没有任何更改，它计算不同的（错误的）哈希。

有没有人知道这到底是怎么可能的？过去一周它一直在疯狂，我不明白为什么这甚至是可能的。我还在另一台机器上对其进行了测试，编译并执行，它运行良好。就在我将它上传到服务器时，哈希不再正确。

可以在以下位置找到散列功能文件：http: //people.csail.mit.edu/rivest/Md5.c

已解决：谢谢大家 这是 64 位架构问题。调试时让我想到这一点真是太烦人了.......

我目前正在实现一个基于 MD5 哈希算法的 RSA 数据安全代码，在 UpdateData 方法中有一段内容如下：

我目前正在尝试了解 if 语句如何评估为真（ mCount[0] 值初始化为 0）。任何帮助将不胜感激。

谢谢

我正在尝试用 MD5 在 C 中做一些事情（后者试图用 SHA1 算法做一些事情）。我的主要问题是我从来没有真正在 C 中做过任何复杂的事情，只是简单的东西（不像指向指针或结构的指针）。

我在这里得到了 md5 算法。

我将文件包含在我md5.c的md5.hC 项目中（使用代码块），但唯一的问题是我并不真正了解如何使用它。我已经阅读并重新阅读了代码，但我不明白如何使用这些函数将“示例”转换为 MD5 哈希。

我有一段时间没有做过 C 编程（主要是 php），所以我有点迷失了。基本上我要问的是一些使用示例。它们是通过md5main.c文件提供的，但我不明白。

我在这里的目标很高吗？我是否应该停止这一切并重新开始阅读 C 书，或者任何人都可以给我一些指示，看看我是否能解决这个问题。

谢谢。

I am taking the MD5 hash of an image file and I want to use the hash as a filename.

How do I convert the hash to a string that is valid filename?

EDIT: toString() just gives "System.Byte[]"

我从来没有在程序主页上检查和比较过 MD5 散列和真正的 MD5 散列。我下载的程序一直有效。

有人可以在下载过程中放置​​自己的代码吗？

有没有办法在使用 Javascript 上传到服务器之前计算文件的 MD5 哈希？

我在 SO 上看到了 一些 问题和答案，表明 MD5 不如 SHA 之类的安全。

我的问题是，在我的情况下这值得担心吗？

这是我如何使用它的示例：

1. 在客户端，我通过附加当前时间和密码，然后使用 MD5 对其进行哈希处理，为消息提供“安全”校验和。所以：MD5(message+time+password)。
2. 在服务器端，我正在使用我对发送时间和客户端密码的了解，对照发送的消息检查此哈希。

在这个例子中，使用 SHA 而不是 MD5 真的更好吗？

在什么情况下，哈希函数的选择在实际意义上真的很重要？

编辑：

澄清一下——在我的例子中，转向 SHA 算法有什么好处吗？

换句话说，在这个例子中，某人在不知道共享密码的情况下发送消息和正确的哈希值是否可行？

更多编辑：

为重复编辑道歉-我不清楚我在问什么。

我正在使用以下代码来计算文件的 MD5SUM -

这正常工作，但如果我遇到一个大文件 (~1GB) - 例如 iso 映像或 DVD VOB 文件 - 我会收到内存不足异常。

不过，我可以在大约 10 秒内计算 cygwin 中相同文件的 MD5SUM。

请建议我怎样才能让它适用于我的程序中的大文件。

谢谢

为了能够检测特定推文的 RT，我计划将每条格式化推文的哈希值存储在数据库中。

我应该使用什么哈希算法。神秘当然不是必需的。只是一种将数据存储为某种东西的最小方法，如果它相同，则可以以一种有效的方式进行比较。

我的第一次尝试是使用 md5 哈希。但我认为可以有更有效的散列算法，因为不需要安全性。

我正在尝试生成用于 Google App Engine 应用程序的唯一 ID，并希望就我正在考虑使用的方法的可行性提供反馈（最后有问题）。我已经阅读了很多关于这个主题的问题，但我不记得遇到过这种特殊的方法。

我想要看起来随机的 ID，例如 MD5 哈希，但我也希望它们很小。沿着 tinyurl 行的四到六个字符将是理想的。ID 将用于用户生成的内容，在我的应用程序的上下文中，例如人们将要编写的测试问题。ID 没有必要看起来是随机的（如果它们看起来像序列 ID 就可以了），但我正在考虑使用的方法适合这一点，所以这不是一个真正的问题。

熟悉 Google App Engine 的人都知道，写入数据存储的成本特别高，如果同一实体组的写入次数过多，可能会导致超时。分片计数器是一种通常用于避免单个全局计数器上的写争用以及随之而来的失败事务的方法。

除了获得短 ID 和避免写入争用之外，我还试图避免生日悖论。我想为有数百万个 ID 的可能性做准备，即使这有点过火了。

我正在考虑按照以下方式使用分片计数器：

• 计数器在用户上分片，因此每个用户都有一个分片。每个计数器对象都有自己的特定于给定用户的计数，当该用户创建新项目时，该计数会增加。无论项目是否成功创建，计数都会增加。
• ID 的基础是以下字符串的 MD5 哈希：“<user-email-address>|<latest-counter-value>”。
• 然后将生成的 MD5 散列截断，最初截断为四个字符。
• 维护单个全局“长度”值。每当前面的步骤导致重复键时（人们想象这会很快发生），长度的值将增加一。新 ID 的 MD5 哈希现在将被截断为“长度”字符，而不是四个字符。
• 我不想公开用户电子邮件地址，这表明某种哈希值将是一个好方法。

我的问题是：我是否正确地认为这将在很大程度上避免由于重复键而导致的写入争用，并且长度字段上的写入争用可能不是问题，尤其是在更长的长度时？谁能描述这里涉及的数学？长度会很快增加到接近 MD5 哈希的长度，从而质疑整个方法的价值吗？使用完整（更长）的 MD5 哈希以使事情更易于维护会更好吗？有什么我忽略的吗？