Какой алгоритм Blowfish является наиболее «правильным»? - PullRequest
Новая
       6

Какой алгоритм Blowfish является наиболее «правильным»?

2 голосов
/ 25 сентября 2010

Я использую Windows Server 2k8 (может, в этом и заключается половина проблемы?) В любом случае, я получаю разные значения из разных модулей Blowfish на разных языках. Есть ли такой, на который можно положиться в качестве стандарта?

В следующих примерах предположим, что ключ password и текст 12345678.

а. Инструмент Online Encrypt с установленным алгоритмом Blowfish mode ECB и Base64 Encode the output дает 2mADZkZR0VM=. Я использовал это в качестве ориентира, мудрого или нет.

б. В следующем коде Perl используются Crypt::ECB и MIME::Base64

use MIME::Base64;
use Crypt::ECB;
$crypt = Crypt::ECB->new;
$crypt->padding(PADDING_NONE);
$crypt->cipher('Blowfish') || die $crypt->errstring;
$crypt->key('password'); 
$enc = $crypt->encrypt("12345678");
print encode_base64($enc);

Это выводит 2mADZkZR0VM= с PADDING_NONE (который хорошо сравнивается с 'a.' Выше). Однако, когда для padding установлено значение PADDING_AUTO, выдается 2mADZkZR0VOZ5o+S6D3OZw==, что, по моему мнению, по крайней мере, ошибка, так как открытый текст имеет длину 8 символов и не нуждается в заполнении.

с. Если я использую Crypt::Blowfish, как показано ниже 

#! c:\perl\bin 
use Crypt::Blowfish;
use MIME::Base64;

my $key;
my $plaintext;

$key = "password";
$plaintext = "12345678";

my $cipher = new Crypt::Blowfish $key; 
my $ciphertext = $cipher->encrypt($plaintext);
my $encoded = encode_base64( $ciphertext );
print $encoded;

тогда я получаю 2mADZkZR0VM=, что соответствует 'a.' выше. Проблема с этим модулем состоит в том, что для кодирования нужно разбить 8-битные блоки; у него нет своего чанка.

* * Д тысячу тридцать один. Если я использую источник в http://linux.die.net/man/3/bf_ecb_encrypt (что я сделал для недавнего проекта PHP ext), тогда я получу тот же ответ, что и «a.». Я склонен доверять этому коду больше всего, так как он используется в SSLeay и OpenSSL.

е. BlowfishEx.EXE в DI Management Blowfish: версия Visual Basic с заполнением PKCS#5 дает 2mADZkZR0VOZ5o+S6D3OZw==, что совпадает с результатами Crypt :: ECB с PADDING_AUTO. Если для Padding установлено значение None, я получу 2mADZkZR0VM=, что соответствует 'a.'

Я частично ответил на свой вопрос, написав это: похоже, мне просто нужно изменить код DI Management для проекта VB6. И, возможно, предложить то же самое автору Crypt :: ECB.

Но остается вопрос: есть ли надежная эталонная платформа blowfish?

1 Ответ

9 голосов
/ 25 сентября 2010

Ваша проблема, похоже, не в том, правильно ли они реализуют алгоритм Blowfish.В варианте «без заполнения» все они, похоже, дают одинаковые результаты.

Это оставляет вопрос о том, следует ли вообще дополнять 8-байтовый ввод.Ответ на этот вопрос довольно прост: PKCS # 7 требует, чтобы к входу всегда был добавлен хотя бы один байт заполнения.Причина этого проста: на приемном конце должен быть недвусмысленный способ удаления отступов.В случае PKCS # 7 значение байтов заполнения всегда равно количеству байтов заполнения, которое необходимо удалить получателю.

Итак, когда вы получаете материал, дополненный PKCS7,Вы дешифруете блок, затем смотрите на последний байт в дешифрованном выводе и удаляете это количество байтов из блока.Без блока заполнения в конце получатель обычно просматривает последний байт фактических данных, и любое значение, которое этот байт содержит, удаляет это количество байтов (хотя, вероятно, оно должно сказать вам, что есть проблема, если числобольше 8).В любом случае, для обеспечения правильной работы всегда должен быть хотя бы один байт заполнения.В вашем случае это означает, что ввод расширяется до 16 байтов вместо 8.

...