0

我想用js制作一个网页来加密明文，所以我可以把它发给朋友，他会用同一个网页来解密它。

我们将共享相同的密钥并将其用于多条消息。

我知道在使用 AES CBC 时，每条消息都需要随机 iv，但我喜欢使用 AES CTR。

我将使用 256 密钥，而不是密码。

我有两个问题：

  1. 我可以在 CTR 中多次使用相同的密码而没有 iv 吗？
  2. 如果我将使用 CBC，以明文形式发送 iv 和加密消息是否安全？

我正在使用 aes-js 和基本的常用操作模式：

https://github.com/ricmoo/aes-js#ctr---counter-recommended

https://github.com/ricmoo/aes-js#cbc---cipher-block-chaining-recommended

我想要最好的安全性。

4

2 回答 2

3

首先，没有“没有 IV”的 CTR 或 CBC 这样的东西。您可能只是使用全零作为 IV。总有一个 IV。（CTR 称其 IV 为 nonce。）

CTR 绝不能重用 nonce+Key 对。它可以完全破坏加密。这是避免点击率的主要原因，除非您知道自己在做什么。它很难正确使用并且具有可怕的故障模式。（ WEP现在被认为完全损坏的事实与这个问题密切相关。）我并不是说正确使用时 CTR 不好。我是说小错误是灾难性的。

CBC永远不应该重复使用 IV+Key，但它并没有那么具有破坏性。这是CBC对于非专家来说是一个非常好的选择的主要原因。即使使用不当，也相对安全。然而，重用 IV+Key 对会带来两个主要问题：

  • 如果两条消息具有相同的前缀，则将前 16 个字节以及进一步的块公开给解密。
  • 相同地加密相同的消息（以及相同的前缀）。这间接泄露了有关消息的大量信息。

标准结构非常适合非专家，因为这些工具在许多平台上都很容易获得并且相对容易正确使用，如下所示：

Random IV + CBC-ciphertext + HMAC

IV不是秘密。将其与消息一起发送是标准且正确的。IV 只能被攻击者无法预测。只要攻击者无法预测（或控制）IV，即使是偶尔的重用也会泄露很少的信息。显然，如果它总是为零，那么预测它是微不足道的。

CBC（以及 CTR）不提供消息的任何身份验证。它可能在运输过程中被修改。如果攻击者知道明文消息，在某些情况下他们可以修改加密消息以便以已知方式解密。例如，如果我知道（或可以猜到）消息为“致 Bob：$100”，则可以在不知道密码为“致 Eve：$100”的情况下修改该消息。身份验证可以防止这种情况。验证 CBC 的方法是使用 HMAC（先加密，然后散列）。

有关此格式在实践中的示例，请参阅RNCryptor格式，包括RNCryptor-js。

Maarten 提到了 GCM，我同意它是一种出色的密码学，但我不同意非专家应该使用它。作为一种反模式，它具有与 CTR 相同的危险。如果使用不当，它会完全崩溃（与 CBC 相比，它的安全性损失要平滑得多）。然而，这是一个高度自以为是的话题，GCM 粉丝并没有错。我只是不同意“非专家的标准最佳实践”应该是什么。

为了“我想要最好的安全性”，那么你绝对需要让安全专家参与进来。选择正确的阻止模式是保护系统最简单的部分，还有许多其他同样重要的陷阱。

于 2018-07-01T17:09:58.720 回答
2
  1. 我可以在 CTR 和没有 IV 的情况下多次使用相同的密码吗？

不，在这种情况下，CTR 将充当多次时间垫，您将失去大部分安全性。

  1. 如果我将使用 CBC，以明文形式发送 IV 和加密消息是否安全？

使用 CBC 也不安全，因为您可能会成为填充预言机攻击的受害者。

使用带有 12 字节随机 IV 的 GCM，或者 - 更好的是 - 使用带有预共享密钥 (PSK) 的 TLS。

于 2018-07-01T16:30:36.260 回答