我需要在哈希列中添加盐。此散列列也用作其中一个表中的索引。出于显而易见的原因，我不想对所有值使用相同的硬编码盐。
每次为给定的字符串生成唯一的相同盐值的最佳方法是什么，所以当我对值进行哈希处理时，我会得到相同的输出（帮助我使用哈希值进行搜索）。
更新：感谢大家的投入。更多细节 - 我必须加密数据库中的一列。该列也用于搜索表中的行，加密后我们不能使用它来搜索，因为我们有可能在以后更改加密密钥。现在为了解决这个问题，我们考虑在表中添加一个哈希列，我们可以在其上执行搜索（因为我们不打算更改哈希算法，我们总是可以将其用于搜索目的）。为了使这个散列列更安全，我们考虑向它添加盐。由于 Salt 应该是随机的，我们将无法每次都为相同的值生成相同的哈希函数，除非我们对所有行使用相同的 Salt。所以这就是为什么我试图找出一种方法，每次都可以为相同的字符串生成相同的盐。
仅将哈希值用作索引或作为外键应该没有问题（只需在哈希值中包含盐），但我理解，您想重新查找该行，只有原始（未哈希）值。
这永远行不通，永远不能使用具有适当加盐哈希的列来查找行。这通常意味着设计存在缺陷，散列值不应该是您必须搜索的东西。一个例子：要验证密码，您应该搜索用户名，然后您可以使用找到的密码哈希验证密码。
如果您确定需要搜索此哈希值，那么您唯一的选择是不使用盐（或对所有值使用相同的盐），或加密该值（没有 IV 的双向加密）。当然，这两个选项都比正确散列值的保护更弱。
更新：根据您的更新，您已经在数据库中拥有加密值。这意味着，您可以搜索它，而无需哈希值。只需在进行查询之前加密抢手的值。
这样做会破坏使用盐的目的。为了达到其预期目的，盐应尽可能随机。
想想看——你可以使用字符串的散列作为“salt”，然后再次将原始字符串和“salt”一起散列。但生成的哈希仍然是原始字符串的派生词。虽然这可能只为简单的彩虹表提供一点安全性，但这还不够。
http://en.wikipedia.org/wiki/Rainbow_table#Defense_against_rainbow_tables
salt 可以与 salted+hashed 值存储在同一个表中。当您插入新记录时，生成一个新的随机盐，盐+散列值，并将散列值和盐保存在该记录中。
Salt 不需要特别安全，因此您可以使用非加密散列（可能是FNV 散列）从字符串中派生盐。然后，您可以使用加密散列（如 SHA-256）与盐一起生成安全散列值。非加密哈希还具有更快的优势。