如何为单个文件实现密码保护？
我正在编写一个小桌面应用程序，该应用程序应该能够加密数据文件并使用密码进行保护（即，必须输入正确的密码才能解密）。 我想要加密的数据文件是独立的和可移植的，所以认证必须嵌入到文件中（或者我假设）。
我有一个看似可行的策略，似乎是基于我所知道的逻辑（这可能恰好是危险的），但我不知道它是否是一个好的设计。 所以告诉我：这是疯了吗？ 有没有更好/最好的方法来做到这一点？
基本上，我从推行网站密码的常用方式（当你不使用OpenID时）推断，即将用户密码的（盐渍）散列存储在数据库中，并且从不保存实际密码。 但是因为我使用散列用户密码作为对称加密密钥，所以我无法使用相同的值进行验证。 所以我再次对它进行哈希处理，基本上像对待另一个密码一样对待它，并将双重哈希值保存在数据文件中。 这样，我可以将该文件带到另一台PC，并通过输入密码进行解密。
那么这种设计是否合理安全，还是绝望天真，还是介于两者之间？ 谢谢！
编辑：澄清和后续问题重新：盐。
我认为盐必须保密才能有用，但是你的答案和链接意味着情况并非如此。 例如，由erickson（下面）链接的这个规范说：
因此，这里定义的基于密码的密钥推导是密码，盐和迭代计数的函数，其中后两个量不需要保密。
这是否意味着我可以将salt值存储在与散列键相同的位置/文件中，并且仍然比在散列时根本不使用盐更安全？ 这是如何运作的？
更多的上下文：加密文件并不意味着与其他人共享或解密，它实际上是单用户数据。 但我想将它部署在我无法完全控制的计算机上的共享环境中（例如在工作中），并且能够通过简单地复制文件来迁移/移动数据（这样我就可以在家中使用它工作站等）。
密钥生成
我建议使用PKCS＃5版本2.0中定义的公认算法（如PBKDF2）从密码生成密钥。 它与您概述的算法类似，但能够生成更长的对称密钥以用于AES。 您应该能够找到一个为不同算法实现PBE密钥生成器的开源库。
文件格式
您也可以考虑使用加密消息语法作为文件的格式。 这需要您进行一些研究，但同样需要使用现有的库，并且可以与其他软件（如启用了S / MIME的邮件客户端）进行更平稳的互操作。
密码验证
关于您希望存储密码的散列，如果您使用PBKDF2生成密钥，那么可以使用标准密码散列算法（大盐，一千次哈希）来获得不同的值。
或者，您可以计算内容上的MAC。 密码上的散列冲突更可能对攻击者有用; 对内容的散列冲突可能毫无价值。 但它可以让合法的收件人知道密码被用于解密。
加密盐
Salt有助于防止预先计算的字典攻击。
假设攻击者拥有可能密码的列表。 他可以散列每一个，并将其与受害者密码的散列进行比较，并查看它是否匹配。 如果清单很大，这可能需要很长时间。 他不想在他的下一个目标上花费那么多时间，所以他将结果记录在一个“字典”中，一个散列指向其相应的输入。 如果密码列表非常长，他可以使用彩虹表等技术来节省一些空间。
但是，假设他的下一个目标淹没了他们的密码。 即使攻击者知道盐是什么，他的预先计算表也毫无价值 - 盐会改变每个密码产生的散列。 他必须将所有密码重新打散到他的列表中，并将目标盐粘贴到输入中。 每种不同的盐都需要不同的字典，如果使用了足够的盐，攻击者将无法为所有字典存储字典。 交易空间节省时间不再是一种选择; 攻击者必须回退哈希每个他想攻击的目标列表中的每个密码。
所以，没有必要保持盐的秘密。 确保攻击者没有与该特定盐对应的预先计算的字典就足够了。
正如Niyaz所说，如果您使用强算法的高质量实现（如SHA-265和AES）进行哈希和加密，则这种方法听起来很合理。 此外，我会推荐使用Salt来减少创建所有密码哈希字典的可能性。
当然，阅读布鲁斯·施奈尔的应用密码学从来都不是错的。
如果您正在使用强大的散列算法（SHA-2）和强大的加密算法（AES），那么使用此方法将会很好。
链接地址: http://www.djcxy.com/p/21523.html上一篇: How to implement password protection for individual files?
下一篇: Is "double hashing" a password less secure than just hashing it once?