ORL*_*ORL 1 java encryption aes
我正在尝试用java编写一个简单的密码管理器.我想使用AES 256位加密使用存储的密码加密文件.此外,我希望用户能够使用密码解密文件.当在线阅读其他帖子时,他们几乎都强调单纯使用密码作为密钥是不安全的,他们提到使用随机盐来增加安全性.但我不明白在生成密钥时如何使用随机盐.如果我从用户的密码和随机盐创建密钥,那么当他们尝试解密他们的文件时,我怎么知道盐是什么?这让我完全糊涂了.
目前,我在每一步使用恒定盐通过几个不同的哈希值运行密码.这是否足够安全,或者我错过了什么?任何有关如何从密码安全生成密钥的帮助将不胜感激!提前致谢.
记住盐不是秘密.您只需将其附加到加密数据即可.盐的目的是防止某人使用通用密码加密的常见数据片段的预先计算字典作为"破解"加密文件的方法.
通过确保盐是随机的并将其与密码相结合,您可以消除字典攻击的可能性,因为(有效)黑客没有机会使用您的"salt +密码"预先加密数据库.(作为初学者,请参阅我的一个教程中的这个页面,了解基于密码的加密中的盐.)
您还(有效地)消除了冲突问题:如果在两个文件中使用相同的数据块在加密版本中看起来相同,则在两个文件上使用相同的密码可能会给攻击者提供内容的线索.
但是,您通常还需要采取其他预防措施,因为典型的密码通常不会包含太多 熵.例如,8个完全随机的小写字母将产生大约40位的熵; 遵循典型英语模式的8个小写字母将产生大约20比特的熵.换句话说,在2 ^ 256个可能的密钥中,实际上典型的用户将在2 ^ 20-2 ^ 40范围内的一些小部分中进行选择.在精明的用户的情况下,情况变得更好,但你将不太可能接近256位的熵.(考虑到在"密码短语"中,每个字符将有大约2.5-3位的熵,所以一个30个字符的密码短语给你大约75位的熵 - 说实话,有多少人使用任何东西比如一个30个字符的密码?使用'完整'范围的可打印ASCII的8个完全随机的字符会给你一点64位以下.)
缓解这种情况的一种方法是使用计算复杂的单向函数来转换密码(使用盐附加),这样黑客就可以花费更长的时间来尝试他们想要猜测的每个密钥.再次,请参阅此页面了解更多详情.
为了让您大致了解基于密码的文件加密的缺陷,您可能还想看看我几年前写过的Arcmexer库,其中包含一个名为isProbablyCorrectPassword()的方法.结合用于生成候选密码的字典/算法,您可以使用它来衡量上述方法的有效性(因为ZIP文件加密使用这些技术的组合).
| 归档时间: |
|
| 查看次数: |
2708 次 |
| 最近记录: |