加密短字符串时,非随机初始化向量是否仍然不好?

时间:2016-06-09 08:28:44

标签: java encryption aes

我们使用Java中的AES 256 CBC PKCS5PADDING加密,必须从Oracle下载库,并使用生成的字节数组的Base64编码。我已经读过静态通用初始化向量大大降低了安全性,因为以chars开头的文本在加密时看起来会相同。对于短字符串(12个数字字符),这仍然是正确的吗?

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

示例(左侧是明文,右侧是加密字符串)

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

虽然与问题分开,但要抢先一些建议:我们需要能够根据明文字符串进行查找并能够解密。我们可以同时执行散列和加密,但如果它不会显着提高安全性,则会更加避免使用散列和加密。

1 个答案:

答案 0 :(得分:2)

  

我已经读过静态公共初始化向量很糟糕,因为可以从加密字符串中导出密钥。

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

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

  

我们需要能够根据明文字符串进行查找。

所以你想构建某种假名数据库?如果这是你的要求,盐和你的情况下随机IV添加的功能实际上是你特别不想要的功能。根据您的其他要求,您可以在这里使用静态IV。但对于一般的假名,建议使用专用的假名。在您的情况下,数据似乎是原子的。但是在例如地址数据的一般情况下,您希望分别对名称,邮政编码,城市以及您的假名的其他任何内容进行散列,以允许更具体的查询,并保持对信息流的访问来自您严格控制的数据。