我想分别用AES256 CBC加密哈希映射的键和值。 挑战在于加密密钥，同时保持恒定的查找速度和安全性（主要是针对字典攻击）。
我读到有关盲索引的信息，但是这些索引在创建时需要一定的随机性（盐，随机数），并且查找功能无法在搜索时重新创建随机数。在查找时，我们将需要知道从何处获取特定密钥的随机数，这最终将意味着在其他地方容易受到攻击。
到目前为止，我只能想到两个选择。
首先，一个是不加密密钥，尽管我更愿意这样做。
第二次 是通过应用类似的变换来获得盲目索引
blind_index(key) = encrypt(digest(key))
但是这里的问题是，每个密钥加密都需要一个唯一的初始化向量，这又使我们再次遇到上述问题：使用一张IV表，以便查找功能能够重建盲人搜索时索引，这将相同的问题移到其他地方。
对于第二种方法，我的想法是：由于我总是加密唯一的值（密钥是唯一的，即使它们是彼此的子字符串，例如'awesome'和'awesome_key'，所以它们在加密之前先经过哈希处理，因此看起来它们的“散列和未加密”形式大不相同），我可以对所有加密使用全局IV，查找功能可以轻松访问该全局IV。由于查找功能需要加密密钥，因此只有所有者才能正确计算盲目索引，并且在地图本身中，明文相似的密钥之间不会存在可见的相似性。
第二种方法的最大问题是它违反了从不使用IV进行不止一种加密的想法。我可以混淆IV以“使其更安全”，但这又不是一个好主意，因为IV应该是纯文本的。
有关情况的更多详细信息：
也许我应该使用其他算法（例如EBC）？
谢谢！
答案 0 :(得分：2)
这完全在格式保留加密（FPE）领域。但是，应用起来很困难，并且处理得当的库并不是很常见。 FPE占用一定数量的比特，甚至取一个范围，然后返回相同大小或相同范围的加密值。只要输入值是唯一的（对于哈希表中的键，它们是自定义的），该密文就在给定域中是伪随机的。
如果与纯文本相比，您可以扩展密文，那么您还可以查看SIV模式（AES-SIV或AES-GCM_SIV，它们更易于处理。它们返回字节数组，这可能会变成{{ 1}}，例如通过使用base64编码；否则，您可以包装字节数组并提供自己的String和equals方法，请注意，这些方法会显着扩展您的纯文本；这是经过身份验证的模式。从输入中计算出IV，输入中的任何更改都会再次使密文随机化。
最后，您当然可以简单地使用IV或随机数来生成您的密文并将其添加为值的前缀。但是，请注意，使用相同的IV重新加密更改的值将非常危险，因为您可能会通过重复泄漏信息。在某些模式下，这可能会完全破坏所提供的机密性。因此，您必须防止IV的重复使用。
对于字符串，绝对不建议使用ECB。如果输入是（或可以扩展为）单个块，则单个块加密当然可以工作。