Php 哪种河豚算法最'；正确'；？

我运行的是WindowsServer2K8（也许这就是问题的一半？），不管怎样，我从不同语言的不同Blowfish模块中获得了不同的值。是否有一个可以作为标准

对于以下示例，假设密钥为

password

，明文为

12345678

a。将算法设置为

Blowfish

mode

ECB

和

Base64对选中的输出进行编码，得到
2mADZkZR0VM=
。我一直在用这个作为我的参考点，不管是明智的还是不明智的

b。下面的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);

这将输出带有PADDING_NONE的
2mADZkZR0VM=
（与上面的“a”比较好）。然而，当padding设置为
padding\u AUTO
时，它会输出
2mADZkZR0VOZ5o+S6D3OZw==
，至少在我看来，这是一个bug，因为纯文本有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;

然后我得到与上面的“a”匹配的
2mADZkZR0VM=
。但这个模块的问题是，必须将内容分割成8字节的块进行编码；它没有自己的chunker

d。如果我使用源代码at（我在最近的一个PHP-ext项目中使用过），那么我得到的答案与“a”相同。我倾向于最信任这段代码，因为它在SSLeay和OpenSSL中使用

e。DI管理中带有
PKCS#5
填充的
BlowfishEx.EXE
给出了
2mADZkZR0VOZ5o+S6D3OZw==
，这与带有
padding\u AUTO
的Crypt:：ECB结果相同。当填充设置为
None
时，我会得到与“a”匹配的
2mADZkZR0VM=

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

但问题依然存在：是否有一个值得信赖的河豚参考平台？
你的问题似乎不在于他们是否正确地实现了河豚算法。在“无填充”变体中，它们似乎都产生相同的结果

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

因此，当您收到填充了PKCS7的材料时，您将对块进行解密，然后查看解密输出中的最后一个字节，并从块中删除那么多字节。如果末尾没有填充块，接收器通常会查看实际数据的最后一个字节，并且不管该字节包含什么值，都会去掉那么多字节（尽管如果该数字大于8，它可能会告诉您有问题）。在任何情况下，为了确保正确的操作，必须始终至少有一个字节的填充。在你的例子中，这意味着输入被扩展到16个字节而不是8个。
这很公平，但所有这些都声称是Schneier算法的实现。相关：我不明白，如果它们都使用相同的填充设置生成相同的结果，那么如何选择“正确性”呢？完全正确。如果你没有填充8字节的明文，那么在解码端，你就无法分辨7字节的明文加上一个字节的填充和8字节的明文碰巧是相同的。非常感谢。这是很有道理的，并且非常清楚地说明了问题。对你来说，这绝对是一个巨大的绿色记号！