为什么 HMAC SHA-1 使用相同的输入返回不同的摘要？

Question

我正在尝试为 Amazon S3 Web 服务构建一个工作加密签名，使用 Objective C 编写一个连接库。

我在 ObjC 代码中遇到了 HMAC SHA-1 摘要问题，所以我将其放在一边并查看在现有的工作 Perl 代码中，尝试解决摘要创建问题。

我正在测试 Net::Amazon::S3 包的 s3ls 命令的 HMAC SHA-1 摘要输出，并将其与 _encode 进行比较我提取并放入其自己的 perl 脚本

#!/usr/bin/perl -w                                                                                                                                                                                    

use MIME::Base64 qw(encode_base64);
use Digest::HMAC_SHA1;
use String::Escape qw( printable unprintable );

sub _ascii_to_hex {
    (my $str = shift) =~ s/(.|\n)/sprintf("%02lx", ord $1)/eg;
    return $str;
}

sub _encode {
    my ( $aws_secret_access_key, $str ) = @_;
    print "secret key hex: "._ascii_to_hex($aws_secret_access_key)."\n";
    my $hmac = Digest::HMAC_SHA1->new($aws_secret_access_key);
    $hmac->add($str);
    my $digest = $hmac->digest;
    print "cleartext hex: "._ascii_to_hex($str)."\n";
    print "digest hex: "._ascii_to_hex($digest)."\n";
    my $b64 = encode_base64( $digest, '' );
    print "encoded: ".$b64."\n";
}

my $secret = "abcd1234";
my $cleartext = "GET\n\n\nFri, 12 Dec 2008 10:08:51 GMT+00:00\n/";
_encode($secret, $cleartext);

中的子例程： 这是该脚本的示例输出：

$ ./testhmac.pl 
secret key hex: 6162636431323334
cleartext hex: 4745540a0a0a4672692c2031322044656320323030382031303a30383a353120474d542b30303a30300a2f
digest hex: 63308f9b8a198440d6d8685a3f3f70d0aab02f68
encoded: YzCPm4oZhEDW2GhaPz9w0KqwL2g=

我正在测试的是，如果我将相同的密钥和明文输入到相同的 _encode 函数中在 Net::Amazon::S3 包中，我应该看到完全相同的密钥、明文和摘要字节。

事实上，我得到了相同的密钥和明文字节。

但我得到了一些不同的摘要（当然还有 base64 编码），例如：

$ s3ls --access-key=foobar --secret-key=abcd1234
...
secret key hex: 6162636431323334
cleartext hex: 4745540a0a0a4672692c2031322044656320323030382031303a30383a353120474d542b30303a30300a2f
digest hex: c0da50050c451847de7ed055c5286de584527a22
encoded: wNpQBQxFGEfeftBVxSht5YRSeiI=

我已经验证了密钥和明文是两个脚本的相同输入。 两个脚本中的编码子例程实际上是相同的（除了传递给子例程的未使用的参数，我从自定义版本中删除了该参数）。

如果输入字节和 _encode 子例程相同，什么会导致 HMAC SHA-1 摘要在两种情况下的计算方式不同？

（我还根据 RFC 2201 中的测试用例验证了这两个脚本。）

Answer 1

我发现在比较中使用哈希时遇到的主要问题是：

1. 确保两次比较中的数据和密钥相同
2. 确保两次比较中的数据和密钥采用相同的字符编码
3. 确保密钥和文本传递相同在这两个脚本中，即哪个是关键，哪个是文本（这已经不止一次地吸引了我）。

尝试使用 Digest::SHA 模块为您创建哈希并将结果与​​其进行比较。

use Digest::SHA qw(hmac_sha1_hex);
my $hash = hmac_sha1_hex($data, $key);

请参阅文档 http://perldoc.perl.org/Digest/SHA.pdf

Answer 2

两个脚本中的编码子例程实际上是相同的（除了传递给子例程的未使用的参数，我从自定义版本中删除了该参数）。

由于您不是比较摘要本身，而是比较摘要的 Base-64 编码版本，因此我建议备份一个步骤并检查摘要本身。 Base-64 编码例程可能不正确。

如果您无法比较摘要本身，请在两个程序中使用相同的编码例程，看看您会得到什么。

Answer 3

恐怕我在这里帮不了什么忙，但你发布的内容肯定有问题。 您的示例脚本为我产生不同的输出，并且您发布的输出确实不可能正确。

。

secret key hex: abcd...1234

结果

_ascii_to_hex("blahblahblah")

当然，整个 ascii_to_hex 的事情与你的问题完全无关，但它表明你应该仔细检查你的

Answer 4

分而治之？

RFC 中的测试向量是最好的起点。 两种情况都通过了吗？ 你尝试过哪些？ 如果某些工作和其他工作没有，最可能的问题是两个 API 之一不正确地编组键输入（有符号数组与无符号数组、字符集转换等）

顺便说一句，当您的示例是时，它真的很难帮助您废话。 正如其他人提到的，blah blah 的十六进制表示不是 abc..123。 让我想知道您的示例中还有哪些不准确的地方？