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

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

5 голосов
/ 12 декабря 2008

Я пытаюсь создать работающую зашифрованную подпись для веб-службы 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 .)

Ответы [ 4 ]

3 голосов
/ 12 декабря 2008

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

  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

2 голосов
/ 13 декабря 2008

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

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

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

1 голос
/ 12 декабря 2008

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

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

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

1 голос
/ 12 декабря 2008

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

Как это могло 

secret key hex: abcd...1234

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

_ascii_to_hex("blahblahblah")

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

...