我使用.NET中的Rijndael / AES加密提供程序实现了加密功能。我对该算法的“理解”表明，只要Key和IV没有受到损害，那么数据就是安全的。不过，我已经阅读过一些网站，其中盐渍密码是最佳做法。对我来说的困惑在于，似乎只有基于哈希函数的加密才需要腌制。 使用Rijndael或AES时的最佳做法是什么，应该使用什么值（明文，密钥，IV）？
答案 0 :(得分：5)
如果使用相同的密钥和相同的IV加密不同的数据集，则相同的明文始终会生成相同的加密文本。如果多个用户拥有相同的密码，他们也将拥有相同的加密密码，从加密数据中可以明显看出他们的密码是相同的。
如果在每次加密之前向明文添加salt，则相同的密码将导致不同的加密字符串，因为（通常）在每种情况下都使用不同的盐。
因此，如果对所有密码加密使用相同的密钥和IV，则场景与使用散列函数时相同，并且使用salt具有相同的优点。如果为每次加密使用不同的密钥或IV，则相同的密码会生成不同的加密文本，并且您没有这些问题。在这种情况下，腌制不会改善任何事情。
答案 1 :(得分：4)
IV 是盐。在网络上发送密文或将密文保存到磁盘时，将IV添加到密文是完全安全的。确保IV由每个消息的加密强伪随机数生成器生成。
在强加密中，仅秘密是密钥。 IV不是秘密，也不是密文。
但是，如果您使用相同 IV 使用相同的密钥进行多个加密（“会话IV”），那么您必须保护IV，就像保护钥匙一样。
答案 2 :(得分：3)
盐只对哈希有意义;它会阻止预先计算的词典。
使用salt进行加密没有任何价值。
答案 3 :(得分：2)
如果密钥是从密码派生的，则密钥派生算法应包含salt。主流算法（例如PBKDF2）可以。
对于加密部分，已建立的操作模式都包括IV，在某种程度上，它本身类似于盐。在加密之前没有必要进一步随机化数据。
答案 4 :(得分：1)
IV对公众知识是安全的，通常您希望为每个加密操作生成一个新的。如果您每次都使用相同的密码，那么您将为相同的加密值生成相同的密文。这有点像WEP加密被破解的方式。 （http://en.wikipedia.org/wiki/Initialization_vector）
散列您要加密的值对您没有多大帮助。 IV已经在密文中引入了随机因子，并且您不希望必须从解密值中解析盐。
正如SLaks所提到的，salting仅对哈希有用。为了进一步说明这一点，对于要与另一个哈希进行比较的哈希值，查看两次输入哈希函数的值是否相同是有用的。盐可防止人们经历的字典攻击（又称Rainbow表），并预先计算了几个输入的哈希值。盐意味着必须为每个盐值生成计算表。
你可以用盐值做更多的事情，但这只是一个例子。