我正在一个安全性为零（纯文本数据库存储）的遗留项目中工作，并且对开发时间和修补现有数据库结构的能力存在真正的限制。他们要求我加密某些值。
经过大量研究，我决定使用AES-256-CBC加密。我决定使用硬编码的单个IV，因为所有要加密的密钥都是完全唯一的，而且如果不是绝对必要的话，我们不能承担增加额外列来存储IV的开销。但是现在他们想加密包含稀疏重复值（例如10,000行，可能有20-30个重复项）的附加列。
似乎在加密此附加列时最明显的缺陷是重复值将共享相同的加密值，因此破解一个会导致破解重复项。他们根本不关心这个，因为这个价值不是特别“有价值”。但是我已经读到，黑客有可能更好地预测您如何使用相同的IV +值对来加密数据，这随后可能导致更容易解密不相关的值。我应该向他们传达这是一个合理的关注吗？给定开发时间和修改现有数据库结构的能力的限制，这是否是值得考虑的巨大风险？
您至少可以做几件事情，每件事情都需要不同的实现工作。
正如彼得已经提到的-您可以在密文的开头粘贴IV。希望这不会超出为该列定义的总长度限制。注意：由于以下原因，密文的长度会更大：1）CBC模式2）IV长度3）BASE 64或您使用的任何编码。
您可以从同一记录中的另一个键属性派生IV，该键属性是唯一的且不会更改。
有时有必要在数据库中使用确定性加密（使用相同的静态IV进行加密）。当在某些SQL WHERE条件中需要使用列值时，通常会发生这种情况。如果是这种情况，请使用一些静态IV值并接受后果。
这不是crypto.stackexchange.com的问题，因为它与API的编程等不直接相关？
无论如何，我想知道您是在为谁捍卫您的（纯文本）数据？
您正在尝试减轻这种加密的风险，例如：
此加密功能可能在未来数月和数年内被其他开发人员重用于其他数据库领域，甚至其他应用程序，因此为什么不通过从哈希函数的结果中得出必要的IV位来设计其安全重用。 ：SHA-3）在以下串联的输入上：
免责声明：我不是加密专家，所以请不要相信我，没有任何保证。