我有很多小秘密要加密存储在数据库中。数据库客户端将拥有密钥，而数据库服务器将不处理加密和解密。我所有的秘密都是 16 字节或更少，这意味着使用 AES 时只有一个块。我正在使用常量 IV（和密钥）来使加密具有确定性，我进行确定性加密的原因是能够使用密文轻松查询数据库并确保相同的秘密不会存储两次（通过使列 UNIQUE ）。据我所知，只要密钥是秘密的，这样做应该没有问题。但我想确定：我是对还是错？如果我错了，可以进行哪些攻击？
顺便说一句：哈希在这里毫无用处，因为可能的明文数量相对较少。使用散列，获取原始明文将是微不足道的。
对于长度为n位的消息，理想的密码是2 n个n位序列的排列，在2 n！这样的排列。“key”是选择了哪个排列的描述。
安全块密码应该与理想密码无法区分，其中n是块大小。对于 AES，n=128（即 16 个字节）。AES 应该是一种安全的分组密码。
如果你所有的秘密的长度正好是 16 字节（或小于 16 字节，有一些填充约定明确地将它们扩展到 16 字节），那么你想要一个理想的密码，并且 AES“本身”应该没问题。对于想要应用填充和处理任意长流的常见 AES 实现，您可以通过请求 ECB 模式或具有全零 IV 的 CBC 模式来获得单块加密。
所有关于 IV 的问题，以及为什么首先需要像 CBC 这样的链接模式，都来自多块消息。AES 加密 16 字节消息（不多也不少）：链接模式是关于模拟较长消息的理想密码。如果在您的应用程序中，所有消息的长度正好为 16 个字节（或更短，但您添加了填充），那么您只需要“原始”AES；并且固定的 IV 是对原始 AES 的足够接近的仿真。
但请注意以下几点：
如果您将加密元素存储在数据库中，并且需要在应用程序的整个生命周期内保持唯一性，那么您的密钥就是长期有效的。长时间保密密钥可能是一个难题。例如，长期存在的密钥需要某种存储（可以抵抗重启）。您如何管理死硬盘？你会在充满酸的大锅中摧毁它们吗？
加密确保机密性，而不是完整性。在大多数安全模型中，攻击者可以是主动的（即，如果攻击者可以读取数据库，他可能也可以写入数据库）。主动攻击引发了一系列问题：例如，如果攻击者在数据库中交换了您的一些秘密，会发生什么？还是随机改变一些？与往常一样，加密是最容易的部分（并不是说它真的“容易”，但它比工作的其余部分容易得多）。
如果程序集是公开可用的，或者可以公开使用，则可以通过使用 Reflector 公开使用它的源代码来发现您的密钥和 IV。如果数据真的是秘密的话，这将是主要问题。可以混淆 MSIL，但这只会增加追踪难度；它仍然必须是计算机可消耗的，因此您无法真正加密它。
静态 IV 会使您的实现容易受到频率攻击。请参阅对于 AES CBC 加密，IV 的重要性是什么？