Почему HMAC SHA-1 возвращает другой дайджест с тем же вводом?

Я пытаюсь создать работающую зашифрованную подпись для веб-службы Amazon S3 и пишу библиотеку подключений с помощью Objective C.

У меня возникли проблемы с дайджестом HMAC SHA-1 в коде ObjC, поэтому я отложу это в сторону и рассмотрю существующий работающий код Perl, чтобы попытаться устранить неполадки при создании дайджеста.

Я тестирую дайджест-вывод HMAC SHA-1 из s3lsкоманды Net::Amazon::S3пакета и сравниваю его с _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=

Я убедился, что секретный ключ и открытый текст являются одинаковыми входными данными для обоих сценариев. Подпрограмма кодирования практически идентична в обоих сценариях (за исключением неиспользуемого аргумента, переданного подпрограмме, которую я удаляю из своей пользовательской версии).

Что может привести к тому, что дайджест HMAC SHA-1 будет вычислен по-разному в обоих случаях, если входные байты и _encodeподпрограмма совпадают?

(Я также проверил два сценария по контрольным случаям в RFC 2201. )

12.12.2008 10:50:35
4 ОТВЕТА
РЕШЕНИЕ

Я считаю, что основные проблемы с хэшами, с которыми я столкнулся при сравнении:

  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

3
12.12.2008 12:16:44
1. Данные («открытый текст») и ключ («секретный ключ») одинаковы в обоих сравнениях 2. Я использую строки UTF8 в обоих случаях 3. Как показывают результаты _ascii_to_hex, байты одинаковы для секрета ключ и открытый текст, используемые в качестве входных данных для экземпляра HMAC Возможно, другой модуль Perl поможет.
Alex Reynolds 12.12.2008 12:58:39
AFAIK, Digest :: HMAC_SHA1 использует Digest :: SHA внутри.
innaM 13.12.2008 12:28:02

Боюсь, я не могу здесь сильно помочь, но определенно что-то не так с тем, что вы написали. Ваш пример сценария производит для меня другой вывод, и вывод, который вы опубликовали, действительно не может быть правильным.

Как это могло

secret key hex: abcd...1234

когда-либо быть результатом этого

_ascii_to_hex("blahblahblah")

Конечно, вся проблема ascii_to_hex не имеет никакого отношения к вашей проблеме, но это показывает, что вы должны перепроверить свои результаты.

1
12.12.2008 11:26:22

Разделяй и властвуй?

Тестовые векторы в RFC - лучшее место для начала. Они прошли в обоих случаях? Какие вы пробовали? Если некоторые из них работают, а другие нет, наиболее вероятная проблема заключается в том, что один из двух API неправильно распределяет входные ключи (подписанные и неподписанные массивы, преобразования кодировок и т. Д.)

Кроме того, действительно трудно помочь вам, когда ваш пример - чепуха. Как уже упоминалось, шестнадцатеричное представление бла-бла не abc..123. Заставляет меня задуматься, что еще в вашем примере неточно?

1
12.12.2008 12:24:17

Подпрограмма кодирования практически идентична в обоих сценариях (за исключением неиспользуемого аргумента, переданного подпрограмме, которую я удаляю из своей пользовательской версии).

Поскольку вы сравниваете не сами дайджесты, а версии дайджестов в кодировке Base-64, я бы рекомендовал сделать резервную копию одного шага и проверить сами дайджесты. Возможно, что процедуры кодирования Base-64 неверны.

Если вы не можете сравнить сами дайджесты, используйте одну и ту же процедуру кодирования в обеих программах и посмотрите, что у вас получится.

2
12.12.2008 21:10:00