我想用js做一个网页加密明文，所以我可以把它发给朋友，他会用同一个网页来解密它。
我们将共享同一个密钥并将其用于多条消息。
我知道在使用 AES CBC 时，每条消息都需要随机 iv，但我喜欢使用 AES CTR。
我将使用 256 密钥，而不是密码。
我有两个问题：
我正在使用 aes-js 和基本的常用操作模式：
https://github.com/ricmoo/aes-js#ctr---counter-recommended
https://github.com/ricmoo/aes-js#cbc---cipher-block-chaining-recommended
我想要最好的安全性。
【问题讨论】：
标签： encryption cryptography aes rijndael block-cipher
首先，没有“无 IV”的 CTR 或 CBC 这样的东西。您可能只是使用全零作为 IV。总有一个 IV。 （CTR 称其 IV 为 nonce。）
CTR 必须永远重复使用 nonce+Key 对。它可以完全破坏加密。这是避免点击率的主要原因，除非您知道自己在做什么。它很难正确使用并且具有可怕的故障模式。 （WEP 现在被认为完全损坏的事实与这个问题密切相关。）我并不是说正确使用时点击率不好；我是说小错误是灾难性的。
CBC不应该从不重复使用 IV+Key，但它没有那么具有破坏性。这是CBC对于非专家来说是一个非常好的选择的主要原因。即使使用不当，也相对安全。然而，重用 IV+Key 对会带来两个主要问题：
标准结构非常适合非专家，因为这些工具可以在许多平台上轻松获得并且相对容易正确使用，如下所示：
Random IV + CBC-ciphertext + HMAC
IV 不是秘密。将其与消息一起发送是标准且正确的。 IV 只能被攻击者无法预测。只要攻击者无法预测（或控制）IV，即使是偶尔的重用也会泄露很少的信息。显然，如果它总是为零，那么预测它是微不足道的。
CBC（以及 CTR）不提供消息的任何身份验证。它可能在运输过程中被修改。如果攻击者知道明文消息，在某些情况下他们可以修改加密消息以便以已知方式解密。例如，如果我知道（或可以猜到）消息为“致 Bob：$100”，则可以在不知道密码为“致 Eve：$100”的情况下修改该消息。身份验证可以防止这种情况。验证 CBC 的方法是使用 HMAC（先加密，然后哈希）。
有关此格式在实践中的示例，请参阅RNCryptor 格式，包括RNCryptor-js。
Maarten 提到了 GCM，我同意它是一种出色的密码学，但我不同意非专家应该使用它。作为一种反模式，它具有与 CTR 相同的危险。如果使用不当，它会完全崩溃（与 CBC 相比，它的安全性损失要平滑得多）。然而，这是一个高度自以为是的话题，GCM 粉丝并没有错。我只是不同意“非专家的标准最佳实践”应该是什么。
对于“我想要最好的安全性”，您绝对需要让安全专家参与进来。选择正确的阻止模式是保护系统最简单的部分，还有许多其他同样重要的陷阱。
【讨论】：
- 我可以多次使用相同的密码，但没有 CTR 而没有 IV？
不，在这种情况下，CTR 将充当多次填充，您将失去大部分安全性。
- 如果我将使用 CBC，以明文形式发送 IV 和加密消息是否安全？
使用 CBC 也不安全，因为您可能会成为填充预言机攻击的受害者。
使用带有 12 字节随机 IV 的 GCM，或者更好地使用带有预共享密钥 (PSK) 的 TLS。
【讨论】：