java - 加密短字符串时，非随机初始化 vector 仍然不好吗？

Question

我们使用 Java 中的 AES 256 CBC PKCS5PADDING 进行加密，并使用必须从 Oracle 下载的库，并对生成的字节数组进行 Base64 编码。我读过静态公共(public)初始化 vector 大大降低了安全性，因为以字符开头的文本在加密时看起来是一样的。对于短字符串(12 个数字字符)仍然如此吗？

我已经加密了一个大集合，但在生成的加密字符串中找不到任何重复出现的子字符串，即使它们以相同的序列开头。

示例(左侧为明文，右侧为生成的加密字符串)

• 555555555501 -> U0Mkd0PPloB5iLBy5jM6nw==
• 555555555502 -> NUHWaFs62LMEeyoGA0mGoQ==
• 555555555503 -> X3/XJNd4TzEsMv7V0bXwqg==

尽管与问题分开，但为了抢占一些建议:我们需要能够基于明文字符串进行查找并能够解密。我们可以同时进行散列和加密，但如果它不能显着提高安全性，则更愿意避免使用它，因为它会增加复杂性。

Answer 1

I have read that static common initialization vector are bad as one can derive the key from encrypted strings.

我很好奇:你在哪里读到的？

对于短(<=16 字节)明文，随机 IV 可以有效地用作 Salt ，即即使明文相同，它也会导致密文不同。这是许多应用中的一个重要功能。但你写的是:

We need to be able to do look ups based on plaintext strings.

那么您想建立某种假名数据库吗？如果这是您的要求，那么盐(以及您的情况下随机 IV 添加的功能)实际上是您特别不想要的功能。根据您的其他要求，您可能可以在这里使用静态 IV。但对于一般的假名，建议使用专用的假名。在你的情况下，数据似乎是原子的。但在一般情况下，例如地址数据，您希望分别对姓名、邮政编码、城市以及您的化名的其他内容进行哈希处理，以便允许更具体的查询，并保持对信息流的访问您的数据受到严格控制。