Java AES密钥生成

Question

我正在尝试用Java编写一个简单的密码管理器。我想用AES 256位加密用存储的密码加密文件。此外，我希望用户能够解密的文件与密码。当阅读其他在线帖子时，他们几乎都强调简单地使用密码作为密钥是不安全的，他们提到使用随机盐来增加安全性。但我不明白如何在生成密钥时使用随机盐。如果我从用户的密码和随机的salt创建密钥，那么当他们试图解密他们的文件时，我怎么知道salt是什么呢？这让我完全糊涂了。

目前，我通过几个不同的散列来运行他们的密码，每一步都使用一个恒定的salt。这是否足够安全，还是我错过了什么？任何关于如何安全地从密码生成密钥的帮助将非常感谢！提前道谢。

Answer 1

记住盐不是秘密。您可以将其附加到加密数据中。salt的目的是防止有人使用预先计算好的、用通用密码加密的通用数据块的字典来“破解”加密文件。

通过确保salt是随机的，并将其与密码结合起来，您就排除了字典攻击的可能性，因为（实际上）黑客不可能拥有用您的“salt+密码”预先加密的数据数据库。（作为入门，请参阅我的教程中关于基于密码的加密中的盐的这一页。）

您还（有效地）消除了冲突问题：如果在两个文件中出现的相同数据块在加密版本中看起来相同，那么在两个文件上使用相同的密码可能会给攻击者提供内容的线索。

不过，您通常还需要采取其他预防措施，这仅仅是因为一个典型的密码通常不包含太多熵。例如，8个完全随机的小写字母会产生大约40位的熵；8个服从英语典型模式的小写字母将产生大约20位的熵。换句话说，在2^256个可能的键中，实际上，典型用户将在2^20-2^40范围内的一小部分中进行选择。在一个精明的用户的情况下，情况会变得更好一些，但是你将非常不可能接近256位的熵。（考虑到在“密码短语”中，每个字符大约有2.5-3位熵，所以一个30个字符的密码短语给你大约75位熵--老实说，有多少人使用类似于30个字符的密码？8个完全随机的字符使用可打印ASCII的“全部”范围，给你的熵略低于64位。）

一种稍微缓解这种情况的方法是使用一个计算复杂的单向函数来转换密码（附加salt），这样黑客就会花更长的时间来尝试他们想要猜测的每个密钥。请再次查看此页以了解更多详细信息。

为了大致了解基于密码的文件加密的缺陷，您可能还想看看我几年前编写的Arcmexer库，其中包括一个名为isProbablyCorrectPassword（）的方法。结合用于生成候选密码的字典/算法，您可以使用它来衡量上述方法的有效性（因为ZIP文件加密使用了这些技术的组合）。