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