问题标签 [blowfish]

我正在用 php 制作一个 IRC 机器人来读取频道的内容。机器人做得很好。但是消息是用河豚加密加密的。我有钥匙，我在下面尝试了 PHP 的代码，但没有成功。

如需更多帮助，加密是通过 drftpd 站点机器人完成的。

我可以找到这个链接http://trac.drftpd.org/browser/branches/jpf/src/plugins/org.drftpd.plugins.sitebot/src/org/drftpd/plugins/sitebot/OutputWriter.java?rev=1721

用 Java 编写的，所以可能一些 Java 人也可以提供帮助。

我正在使用MCRYPT_DEV_RANDOM和MCRYPT_DEV_URANDOM作为河豚加密的一部分，但我注意到它每次都输出相同的随机数字。它因机器而异，但在每台机器中都是相同的。

• 这是正常的吗？
• 它会影响我用它生成的初始化向量 (IV) 的强度吗？

以下是一些更改了键值和有效负载的示例代码：

这在 PHP 中可以很好地加密和解密，但是 Java 和 .NET 的值不同，更糟糕的是，我无法从 Java 或 .NET 中解密结果。当我尝试从 java 中解密这些值时，我得到一个开始正确的字符串，但在中途结束时变成了垃圾。如果有人想知道，我在 Windows XP 中使用 5.3x。

虽然我是 STFW，但我注意到几个线程，其中最后的评论提到了由于打字问题而导致 base64 搞砸结果的事情，我想知道这是不是因为结果如此接近，前 50 个左右的字符匹配，然后事情转到@#$!。

我还阅读了几个关于块大小和填充的线程，但似乎没有人同意填充应该是什么。我真的需要知道Java是否正在填充文本，默认块大小是多少，填充是什么？见下文：

java开发人员正在做：

我已经在这方面花费了太多时间，这里有人有什么想法吗？谢谢。

/dev/urandom当我偶然发现这个有趣的花絮时，我正在寻找一种更快的替代方法：

生成非常好的非随机但几乎随机位的一个好技巧是使用 /dev/random 的熵来播种快速对称流密码（我最喜欢的是河豚），并将其输出重定向到需要它的应用程序。

这不是一种初学者技术，但使用两行或三行 shell 脚本和一些创意管道很容易设置。

Schneier 对安全性的进一步研究得出了这样的评论：

如果您要“注入熵”，有很多方法可以做到这一点，但更好的方法之一是将其“传播”到高速流密码中，并将其与非确定性采样系统相结合。

如果我错了，请纠正我，但这种生成随机位的方法似乎比/dev/urandom速度和安全性要好。

所以，这是我对实际代码的看法：

此速度测试需要 400MB 的零，并使用带有由伪随机可打印字符组成的 448 位密钥的河豚对其进行加密。这是我上网本的输出：

400+0 条记录 400+0 条记录 419430400 字节 (419 MB) 复制，14.0068 秒，29.9 MB/秒

真实 0m14.025s 用户 0m12.909s 系统 0m2.004s

那太棒了！但它有多随机？让我们通过管道将结果发送到ent：

熵 = 每字节 8.000000 位。

最佳压缩会将此 419430416 字节文件的大小减少 0%。

419430416 个样本的卡方分布为 250.92，随机超过该值的概率为 50.00%。

数据字节的算术平均值为 127.5091（127.5 = 随机）。Pi 的 Monte Carlo 值为 3.141204882（误差 0.01%）。序列相关系数为 -0.000005（完全不相关 = 0.0）。

这看起来不错的样子。但是，我的代码有一些明显的缺陷：

1. 它/dev/urandom用于初始熵源。
2. 密钥强度不等于 448 位，因为只使用可打印字符。
3. 密码应定期重新播种以“散布”熵。

所以，我想知道我是否走在正确的轨道上。如果有人知道如何修复这些缺陷中的任何一个，那就太好了。另外，如果不是/dev/urandom、sfill、badblocks或 DBAN，您能否分享您用来安全擦除磁盘的内容？

谢谢！

编辑：更新代码以使用河豚作为流密码。

我知道作为一个程序员很少有人这样做，但我实际上需要它并且根本不需要它，所以有人需要将这个小函数密码学python转换为delphi。

-

我很多次，因为我尝试在 Delphi 中做，总是向我展示不同的结果，然后做得更好，并要求了解 python / delphi 的人

非常感谢！

我被要求将登录表单指向一个外部站点，其中登录和密码应该出现在 URL 中，并且密码应该是 Blowfish 加密的。我得到了一个“密钥”，其格式为："nnn-nnnssssssssssssssssssssssssnnnnnn"其中 n 是一个数字，s 是一个字母（其中 24 个）。

从 PHP 文档看来，要使用 crypt() 触发 Blowfish 加密，需要以特定格式提供盐，以“$2a$”开头，但这不是我提供的密钥的格式。这是否意味着我需要提供自己的盐？如果是，那么提供给我的钥匙有什么意义？

我正在创建一个类似于 phpmyadmin（数据库管理 UI）的应用程序。用户需要根据数据库对自己进行身份验证，并且应用程序需要以某种方式存储凭据。SSL 不是所有安装的选项。

• 想法 1：用户发送凭据，应用程序存储用户名并使用预定义的 Blowfish 密钥 (config.ini.php) 加密密码 - 这就是 phpMyAdmin 所做的。
• 想法2：登录表单创建随机的blowfish密码（javascript），用户发送登录凭据，应用程序加密用户/密码并将它们存储在会话中的服务器端，密钥存储在cookie中并为每个请求发送。

想法 1：如果服务器安全受到破坏，就会出现问题。（密钥在配置中，会话数据在 /tmp 中）
想法 2：中间人攻击的问题。（发送密钥+凭据）

还有其他建议吗？批评？

最近我有理由比较 Blowfish 算法。我正在比较DI Management的库和 PHP 的mcrypt的输出。我无法让他们以任何方式同意。

这使我进行了一次有趣的追逐。根据Bruce Schneier 网站上的这篇帖子，Blowfish 代码的早期版本中存在符号扩展错误，并且似乎 DI 管理代码实现了预错误报告代码。

错误报告中的简介部分说，

每当 key[j] 的最高有效位是“1”时，它就会阻塞。例如，如果 key[j]=0x80，则 key[j]，一个有符号字符，在与数据进行 OR 运算之前将符号扩展为 0xffffff80。

blf_InitialisebasBlowfish.bas中函数的等效代码是

错误报告建议对 C 代码进行以下修复：

我在 VB6 中实现为

事实上，我已经编写了它以便使用这两种方法，然后放入一个断言来检查值是否相同，即：

当 aKey(j) 包含 255 时，我得到一个断言错误。

我读对了这种情况吗？是出现符号扩展错误还是我看到不存在的错误？

奇怪的是，DI 管理代码附带的测试似乎在有和没有这种变化的情况下都能正常工作（这可能意味着我对两种算法之间等价性的搜索可能取决于其他东西。）

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

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

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

湾。以下 Perl 代码使用Crypt::ECB和MIME::Base64

这2mADZkZR0VM=与 PADDING_NONE 输出（与上面的 'a.' 相比很好）。但是，当填充设置为PADDING_AUTO它输出2mADZkZR0VOZ5o+S6D3OZw==时，至少在我看来，这是一个错误，因为纯文本有 8 个字符长并且不需要填充。

C。如果我使用Crypt::Blowfish如下

然后我得到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 的作者也有同样的建议。

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

我有一个通过 UDP 进行时间敏感通信的应用程序（如视频流或游戏）。数据包可能会丢失，不需要重新传输。

我应该使用什么密码来加密数据报？

在欧洲央行模式下，我倾向于河豚。我知道ECB模式有问题，但我需要支持丢失的数据包，所以加密不能依赖以前的块。是否有更好的密码或模式可以用来减少ECB 模式的问题并仍然允许丢失数据包？

（我想保持一切纯 Java，所以我不能使用 DTLS。）