我正在尝试用 java 编写一个简单的密码管理器。我想使用 AES 256 位加密使用存储的密码加密文件。此外，我希望用户能够使用密码解密文件。当在线阅读其他帖子时，几乎所有人都强调简单地使用密码作为密钥是不安全的，他们提到使用随机盐来增加安全性。但我不明白在生成密钥时如何使用随机盐。如果我从用户的密码和随机盐创建密钥，那么当他们尝试解密他们的文件时，我怎么知道盐是什么？这让我完全糊涂了。
目前，我在每一步都使用常量盐通过几个不同的哈希来运行他们的密码。这足够安全还是我错过了什么？任何有关如何从密码安全地生成密钥的帮助将不胜感激！提前致谢。
【问题讨论】：
标签： java encryption aes
请记住，盐不是秘密。您可以将其附加到加密数据中。加盐的目的是防止有人使用预先计算的由常用密码加密的常用数据组成的字典作为“破解”加密文件的一种方式。
通过确保盐是随机并将其与密码相结合，您就消除了字典攻击的可能性，因为（实际上）黑客不可能拥有预先存储的数据数据库- 用你的“盐+密码”加密。 （作为初学者，请参阅此页面，来自我的一个教程，salts in password-based encryption。）
您还（有效地）消除了冲突的问题：如果在两个文件中使用相同的密码，如果两个文件中出现的相同数据块看起来像在加密版本中也是如此。
不过，您通常仍需要采取其他预防措施，因为典型密码通常不包含太多熵。例如，8 个完全随机的小写字母会产生大约 40 位的熵； 8 个遵循典型英语模式的小写字母会产生大约 20 位的熵。换句话说，在 2^256 个可能的键中，实际上典型用户会在 2^20-2^40 范围内的一小部分中进行选择。对于精明的用户，情况会好一些，但您不太可能接近 256 位的熵。 （考虑在“密码短语”中，每个字符大约有 2.5-3 位熵，所以 30 个字符的密码短语给你大约 75 位熵——老实说，有多少人使用任何东西像 30 个字符的密码？；使用“完整”范围的可打印 ASCII 的 8 个完全随机的字符将给你 64 位以下。）
稍微缓解这种情况的一种方法是转换密码（附加盐）使用计算复杂的单向函数，这样它就会被黑客攻击多一点时间来尝试他们想猜测的每个键。再次，see this page for more details。
为了让您大致了解基于密码的文件加密的缺陷，您可能还想看看我几年前写的Arcmexer library，其中包括一个名为 isProbablyCorrectPassword() 的方法。结合用于生成候选密码的字典/算法，您可以使用它来衡量上述方法的有效性（因为 ZIP 文件加密使用了这些技术的组合）。
【讨论】：
使用这个库：http://www.jcraft.com/jsch/
这里有一个很好的 AES 示例：
http://www.jcraft.com/jsch/examples/AES.java.html
很多大牌都用这个包，Maven、Eclipse等
【讨论】：