我有一个不可能的任务来解密从客户端发送的 AES/CBC 加密数据包。我做了大量的研究，让我相信如果 IV 是静态的，加密是不安全的。对于这个任务，IV 总是静态设置为 0。有什么办法可以做到这一点？
编辑： 纯文本是来自 Hamlet 脚本的 sn-ps。客户端以随机块的形式发送它们，因此长度甚至不一致。数据包最终可能会重复，但我不能 100% 确定。
【问题讨论】：
标签： java aes encryption
没有钥匙。
具体来说，假设没有填充，每次使用相同的 IV 时会出现的漏洞是，如果您开始对上次加密的相同数据进行加密，则两次都会得到相同的加密字符串。这允许攻击者推断出消息内容的某些信息，尽管它不能帮助他们解密。
【讨论】：
只是为了表示，术语“解密”是指使用密钥的正常操作。如果您没有密钥，这通常称为“破解”、“破解”或“密码分析”。
具有固定初始化向量的 CBC 具有这样的特性，即具有相同起始块的消息（使用相同的密钥加密）也将在密文中显示相同的起始块......这是唯一的弱点。因此，如果您可以让受害者为您的消息加密一些猜测（使用相同的密钥），您可以将其密文与您正在使用的消息中使用的密文进行比较。
当消息是某种固定格式时这更容易，如果消息在有趣的部分之前包含足够的随机数据（这是“穷人的初始化向量”），这将是没有希望的。
其他 CBC 弱点取决于您选择初始化向量并观察其解密验证的所选密文攻击，也可能适用（您将设置第一个密文块并观察第二个块是否具有有效填充）。
【讨论】：
非随机 IV 的主要问题是使用相同密钥加密的两个相同初始块将产生相同的输出。因此，鉴于您对哈姆雷特片段的描述，知道您重复使用相同的 IV，我会执行以下操作：
我也会对其他几个众所周知的短语做同样的事情。即使在我捕获您的文件并在数据库中缓存之前，我也可以大规模并行执行此操作。这种方法的总称是rainbow table。
如果我碰巧知道您消息的前 16 个字节（例如，如果它们是给已知人的电子邮件消息，或者带有已知标头的 HTTP 请求等），我的工作会变得非常轻松。
但是如果您使用随机密钥（或像 PBKDF2 这样的适当 KDF）怎么办？好吧，假设我收到了一些来自您的消息，其中至少有一些具有相同的前 16 个字节（同样，协议中的标头在这里对我有很大帮助）。好吧，第一步是我知道这些消息具有相同的前 16 个字节。这是非常有用的信息。现在我有一个crib 来攻击你的消息。
在 CBC 中重用 IV+Key 并不会完全破坏其安全性（就像在 CTR 模式中重用 Nonce+Key 一样）。但它为攻击者提供了许多有用的工具来简化攻击。
我并不是说这些都可以让您在短时间内解密您的特定密文。但它们都强烈削弱了所谓的 AES 强密码学。
【讨论】：
Zero IV 可能会泄漏有关数据首字节的一些信息，但是，如果它们不同，这应该不是问题（但是，不建议使用）。 例如，OpenPGP 在某些情况下使用零 IV。
【讨论】：