我正在做一个安全性为零的遗留项目(纯文本数据库存储(，开发时间和修改现有数据库结构的能力确实受到了限制。他们要求我对某些值进行加密。
经过大量研究，我决定使用AES-256-CBC加密。我决定使用硬编码的单个IV，因为所有加密的密钥都是完全唯一的，如果不是绝对必要的话，我们无法承担添加额外列来存储IV的开销。但现在他们想加密一个包含稀疏重复值的附加列(例如，10000行中可能有20-30个重复值(。
加密这一附加列时最明显的缺陷似乎是重复的值将共享相同的加密值，因此破解一个会导致破解重复的值。他们根本不关心这一点，因为这种价值并不是特别"有价值"但我读到，黑客有可能更好地预测你如何使用相同的IV+值对加密数据，这可能会导致更容易解密不相关的值。这是我应该向他们转达的合理关切吗？考虑到开发时间和修改现有数据库结构的能力的限制，这是一个值得考虑的巨大风险吗？
这难道不是crypto.stackeexchange.com的问题吗？因为它与编程API等没有直接关系。？
不管怎样，我想知道你在为你的(明文(数据辩护吗？
- 应用程序的恶意用户可能在某个时刻使用(SQL(注入
- 可以读取/修改数据库或备份的系统/数据库管理员或主机提供商
您试图通过这种加密来减轻哪些风险，例如：
- 攻击者将记录从数据库的一部分复制到数据库的一个部分，他们可以通过应用程序访问该部分，从而诱使应用程序对其进行加密/解密
- 统计分析(https://en.wikipedia.org/wiki/Frequency_analysis(
这个加密函数可能会在未来的几个月和几年内被其他开发人员重新用于其他数据库字段，甚至其他应用程序，所以为什么不通过以下级联输入从哈希函数(例如：SHA-3(的结果中导出必要的IV位来设计它以供安全重用呢：
- 数据库名称
- 架构名称
- 表名称
- 列名
- 记录的ID/主键
免责声明：我不是加密货币专家，所以不要相信我的话，没有任何保证。
您至少有几件事可以做，每件事都需要不同的实现工作。
-
正如Peter已经提到的，你可以把IV粘在密文的开头。希望这不会超出为该列定义的总长度限制。注意：密文的长度会更大，因为：1(CBC模式2(IV长度3(BASE 64或您使用的任何编码。
-
您可以从同一记录中的另一个密钥属性派生IV，该属性是唯一的并且不会更改。
-
有时有必要在数据库中使用确定性加密(使用相同的静态IV加密(。当列值需要在某些SQL WHERE条件中使用时，通常会发生这种情况。如果是这种情况，只需使用一些静态IV值并接受后果。