我的数据库中有很长的内容。我喜欢加密它。我可以使用 xor 但这不是很安全，因为可以看到模式并且可能会显示 xor 值。IIRC AES 有一个密钥和一个初始化向量 (IV)，可以将其视为种子（在谈论随机数时）。我相信IV应该是随机制作的。当使用密钥加密相同的数据时，会出现不同的模式。
我如何安全地加密 64 位？我怀疑它可能不是真正安全的 w/oa 随机 IV/种子。但我不想存储它。目前我能想到的另一个选项是拥有一个加密 RNG 并运行它说 10000 次，如果该值是第 10000 个索引，那么 xor 值。但在性能方面，这并不能扩展。
我如何正确安全地加密 64 位而不为每个 64 位存储额外的位？我在想也许用 (seed xor index) 喂一个加密 RNG 运行它 X 次，然后用它的值 xor。但我感觉有人有更好的主意？
AES的块大小为 128 位，因此如果您使用它，您最终将加密与有意义的数据一样多的填充。
您可以使用DES（或者最好是3DES），因为它的块大小是 64 位。
初始化向量对攻击者来说应该是难以预测的，但它实际上并不像密钥那样是秘密的，因此可以通过算法来选择它；例如，参见ESSIV算法，该算法用于为磁盘加密生成每个扇区的 IV。您可以使用相同的方案——只需将“扇区号”替换为类似于记录的唯一 ID 号之类的东西——因此您实际上不必存储 IV，只需在解密时使用算法重新生成它。（但如果您修改了记录的唯一 ID，请确保使用新的 IV 进行解密和重新加密！）
如果您使用ECB 模式进行加密，则可以完全避免使用 IV ，但这并不是一个好主意。对于给定的密钥，在 ECB 模式下，相同的明文始终加密为相同的密文，因此攻击者即使无法确定实际值，也可以在两条记录中看到您的密码相同。假设您没有为每条记录使用不同的键，您希望为每条记录使用不同的 IV。
如果你有某种索引，你可以使用 CTR 模式加密，索引作为 NONCE。在这种情况下，您可以安全地使用 AES。请注意，有一个重要的警告：如果您第二次使用相同的 NONCE，那么您会泄漏纯文本（因为您可以检索密钥流）。如果攻击者可以及时查看您的系统，这也可能适用于将新值加密到数据库中。