2

我正在运行 Windows Server 2k8（也许这是问题的一半？）无论如何，我从各种语言的不同 Blowfish 模块中获得了不同的值。有没有可以作为标准的依据？

对于以下示例，假设密钥是password和明文12345678。

一种。将算法设置为模式并选中的在线加密工具给出. 我一直在使用这个作为我的参考点，无论是否明智。BlowfishECBBase64 Encode the output2mADZkZR0VM=

湾。以下 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_AUTO它输出2mADZkZR0VOZ5o+S6D3OZw==时，至少在我看来，这是一个错误，因为纯文本有 8 个字符长并且不需要填充。

C。如果我使用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 字节的块进行编码；它没有自己的分块器。

d。如果我使用http://linux.die.net/man/3/bf_ecb_encrypt的源代码（我为最近的一个 PHP ext 项目所做的），那么我得到的答案与“a.”相同。我倾向于最信任此代码，因为它在 SSLeay 和 OpenSSL 中使用。

e. BlowfishEx.EXEDI Management's Blowfish: a Visual Basic version with PKCS#5padding中的2mADZkZR0VOZ5o+S6D3OZw==Crypt::ECB 结果与PADDING_AUTO. 将 Padding 设置为None我得到2mADZkZR0VM=与“a”匹配的内容。

我已经部分回答了我自己写这个的问题：看起来我只需要为 VB6 项目修改 DI Management 的代码。也许对 Crypt::ECB 的作者也有同样的建议。

但问题仍然存在：是否有值得信赖的河豚参考平台？

4

1 回答 1

9

您的问题似乎与他们是否正确实施 Blowfish 算法无关。在“无填充”变体中，它们似乎都产生相同的结果。

这就留下了一个 8 字节输入是否应该被填充的问题。这个问题的答案非常简单：PKCS #7 要求总是至少有一个字节的填充添加到输入中。原因很简单：在接收端，需要有一种明确的方式来移除填充。在 PKCS#7 的情况下，填充字节的值始终是接收者需要剥离的填充字节数。

So, when you receive material that's been padded with PKCS7, you decrypt the block, then look at the last byte in the decrypted output, and remove that many bytes from the block. Without a block of padding on the end, the receiver would normally look at the last byte of actual data, and whatever value that byte happened to contain, strip off that many bytes (though it should probably tell you there's a problem if the number is larger than 8). In any case, to assure correct operation, there must always be at least one byte of padding. In your case, that means the input gets expanded out to 16 bytes instead of 8.

于 2010-09-25T16:22:33.857 回答