我正在运行Windows Server 2k8（也许这只是问题的一半？）无论如何，我从各种语言的不同Blowfish模块中获得不同的值。有没有可以作为标准的依据？
对于以下示例，假设密钥为password，明文为12345678。
一个。将Online Encrypt Tool算法设置为Blowfish模式ECB并Base64 Encode the output选中2mADZkZR0VM=会产生Crypt::ECB。我一直在使用这个作为我的参考点，无论是明智还是其他。
湾以下Perl代码使用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_AUTO PADDING_NONE（与上面的'a。'相比较）。但是，当padding设置为2mADZkZR0VOZ5o+S6D3OZw==时，它会输出Crypt::Blowfish，这在我看来至少是一个错误，因为明文长度为8个字符且不需要填充。
℃。如果我使用#! 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=然后我得到BlowfishEx.EXE匹配'a'。以上。但是这个模块的问题是必须将事物分成8个字节的块进行编码;它没有自己的chunker。
d。如果我在http://linux.die.net/man/3/bf_ecb_encrypt处使用源代码（我在最近的一个PHP ext项目中使用了代码），那么我会得到与“a”相同的答案。我倾向于最信任这个代码，因为它在SSLeay和OpenSSL中使用。
即DI管理Blowfish: a Visual Basic version PKCS#5填充2mADZkZR0VOZ5o+S6D3OZw==的{{1}}给出PADDING_AUTO，与None的Crypt :: ECB结果相同。将填充设置为2mADZkZR0VM=后，我得到{{1}}，其匹配'a。'
我已经部分回答了我自己写的问题：看起来我只需修改DI管理的VB6项目代码。也许对Crypt :: ECB的作者提出同样的建议。
但问题仍然存在：是否有值得信赖的河豚参考平台？
答案 0 :(得分：9)
您的问题似乎与他们是否正确实施Blowfish算法无关。在“无填充”变体中，它们似乎都产生相同的结果。
这就留下了一个问题，即是否应该填充8字节输入。答案很简单：PKCS＃7要求输入中始终至少添加一个填充字节。原因很简单：在接收端，需要一种明确的方法来删除填充。在PKCS＃7的情况下，填充字节的值始终是需要由接收者剥离的填充的字节数。
因此，当您收到用PKCS7填充的材料时，您解密该块，然后查看解密输出中的最后一个字节，并从块中删除那么多字节。如果没有最后一个填充块，接收器通常会查看实际数据的最后一个字节，以及该字节恰好包含的值，剥去那么多字节（虽然它应该告诉你如果数字是大于8）。在任何情况下，为了确保正确操作，必须始终至少有一个填充字节。在您的情况下，这意味着输入扩展到16个字节而不是8个。