SHA-1、RFC3174 和 RFC4634答案

【问题标题】：SHA-1, RFC3174 and RFC4634SHA-1、RFC3174 和 RFC4634
【发布时间】：2011-01-21 10:24:14
【问题描述】：

社区新手，但对编程并不陌生。

我一直在尝试启动/运行一组哈希函数，但我成功了。但是，我发现了一些奇怪的结果，但我还无法确定。 RFC4634 包含 SHA-1 和 SHA-2 系列的 C 实现，它也可以接受传递的文件以进行散列。 RFC3174 包含一个 C 实现，但不处理文件流。我一直在使用 RFC4634 中的 C 实现来验证文件，但是当我将它们与 SHA-1 提供的哈希值进行比较时，验证过程返回的结果不相似。

知道可能是什么原因吗？

【问题讨论】：

顺便说一句，你可以在Brian Gladman's page 上找到加密算法的良好 C 实现，以防你有更多的运气！它们通常比例如更容易集成。 OpenSSL 的。

标签： c sha1

【解决方案1】：

您是否检查过您是以 ASCII 模式还是二进制模式打开文件？可以在计算哈希之前执行行尾转换。

更新：

我刚刚编译了 RFC4634 shatest 并尝试了一个示例文本文件。只要没有换行符，所有工具都同意。插入换行符后，结果取决于：如果文本文件使用 CR 和 LF（DOS 模式），则 shatest 会产生不同的结果。如果行尾只有LF（UNIX），还是和其他工具一致的。

更新 2：

在RFC4634的文件shatest.c中，在函数hashfile(...)中，设置fopen为二进制模式：

FILE *hashfp = (strcmp(hashfilename, "-") == 0) ? stdin :
        fopen(hashfilename, "rb");
/*                            ^ HERE */

【讨论】：

RFC3174 和 RFC4634 的 SHA-1 实现有区别吗？
不符合 RFC 4634：“此处提供的代码支持任意位长度的输入字符串。来自 [RFC3174] 的 SHA-1 示例代码也已更新以处理任意位长度的输入字符串。”
RFC3174 提供的实现缺乏对文件进行哈希处理的能力。所以我习惯了 RFC4634 中提供的 C 实现，并且哈希输出与给定的哈希不匹配。该代码支持带和不带空格的散列。
您可以使用 RFC4634 实现发布客户端代码吗？
我理解最初的部分，将“abc”描述为消息并用 1 和 423 0 填充它并添加一个带有消息长度的块（64 位）。但是，如果我想要散列更长的消息以及我应该如何解释它，我会感到困惑。