0

好的。所以我最近注册了 Crashplan，它使用 448 位 Blowfish 来加密你发送给他们的数据，我对 Blowfish 的研究越多，听起来 64 位块大小对于他们的卷大小来说是完全不够的将备份。

我读过，尤其是在某些模式下（如 CTR），它对于大数据流完全不够用，并且仅在千兆字节之后就可以与随机数据区分开来？但是，我读过的其他内容似乎表明，如果实施得当，这不是问题。

这样的攻击是否不适用于 Crashplan 的实施？

此外，假设实现尽可能完美，它甚至是温和的“后量子”安全吗？

拥有 Crashplan 的公司的创始人在这里回答了类似的问题：https ://superuser.com/questions/587661/crashplan-truecrypt-overkill

但是，如果 Blowfish 自己的创建者说他很惊讶仍然有人使用它并说你绝对应该使用它，我真的希望他能就他们的实施以及为什么我应该信任它来发送给 Crashplan 的大量数据做出更好的回应改为双鱼。

欢迎其他人也加入进来。我想要尽可能多的信息。我已经很担心我可能会完全停止使用 Crashplan。

4

1 回答 1

6

区分器是一种非常弱的攻击。它不允许攻击者解密数据，它只允许他们找出是加密数据，而不是随机数据。

64 位块的影响很大程度上取决于所选模式。

  • 在 CTR 模式下使用一次性键，问题很小。如果几个 GB 使用相同的密钥加密，则有一个区分符。
  • 使用 CTR 中的多用途键时，问题非常严重。重复使用 IV 对 CTR 来说是致命的。
  • 对于 CBC，它们介于两者之间。

我不相信 Crashplan 的加密，因为：

  • 使用 Blowfish 显示出对加密的不良品味。它没有损坏，但您会发现很少有密码学家会在新产品中使用它。

  • 他们没有记录他们是如何加密的。仅知道使用的原语就无法评估加密。一些我找不到答案的基本问题：

    • 使用哪种模式？
    • 密钥是如何管理的？它们是一次性的吗？多次使用？
    • IV是如何产生的？
    • 密钥是如何从密码中导出的？
    • 数据是如何认证的？带MAC？哪一个？
  • 他们似乎使用自定义加密而不是 SSL 来保证传输安全。用于传输安全的良好加密与文件加密完全不同。因此，他们声称“它是安全传输的。不一定是 SSL，而是使用用于在备份期间加密数据的相同加密技术”有点令人担忧。
于 2013-06-09T09:45:46.263 回答