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