encryption - 如何对单个文件实现密码保护？

Question

我正在编写一个小桌面应用程序，它应该能够加密数据文件并用密码保护它(即必须输入正确的密码才能解密)。我希望加密的数据文件是独立且可移植的，因此必须将身份验证嵌入文件中(或者我假设)。

根据我所知道的，我有一个看起来可行且合乎逻辑的策略(这可能足以造成危险)，但我不知道它是否真的是一个好的设计。所以告诉我:这疯了吗？有没有更好/最好的方法来做到这一点？

第 1 步:用户输入明文密码，例如“我的难密码”

第 2 步:应用程序对用户密码进行哈希处理，并使用该值作为对称 key 来加密/解密数据文件。例如"MyDifficultPassword"--> "HashedUserPwdAndKey"。

第 3 步:应用程序对第​​ 2 步中的哈希值进行哈希处理，并将新值保存在数据文件头(即数据文件的未加密部分)中，并使用该值来验证用户的密码。例如"HashedUserPwdAndKey"--> "HashedValueForAuthentication"

基本上，我是从实现网站密码的常用方法(即当您不使用 OpenID 时)推断出来的，即将用户密码的(加盐)哈希存储在您的数据库中，并且从不保存实际密码.但是由于我使用散列用户密码作为对称加密 key ，所以我不能使用相同的值进行身份验证。所以我再次对其进行哈希处理，基本上将其视为另一个密码，并将双重哈希值保存在数据文件中。这样，我可以将文件带到另一台 PC 上，只需输入我的密码即可对其进行解密。

那么这种设计是相当安全的，还是天真无望的，还是介于两者之间？谢谢!

编辑:澄清和后续问题:盐。
我认为盐必须保密才能有用，但您的答案和链接暗示情况并非如此。例如， this spec由埃里克森(下)链接 说:

Thus, password-based key derivation as defined here is a function of a password, a salt, and an iteration count, where the latter two quantities need not be kept secret.

这是否意味着我可以将盐值存储在与散列 key 相同的位置/文件中，并且仍然比在散列时完全不使用盐更安全？这是如何运作的？

更多上下文:加密文件不打算与他人共享或解密，它实际上是单用户数据。但我想将它部署在我无法完全控制的计算机上的共享环境中(例如在工作中)，并且能够通过简单地复制文件来迁移/移动数据(这样我就可以在家中使用不同的工作站等)。

Answer 1

key 生成

我建议使用公认的算法，例如 PKCS #5 version 2.0 中定义的 PBKDF2从您的密码生成 key 。它类似于您概述的算法，但能够生成更长的对称 key 以用于 AES。您应该能够找到为不同算法实现 PBE key 生成器的开源库。

文件格式

您也可以考虑使用 Cryptographic Message Syntax作为文件的格式。这需要您进行一些研究，但同样有现有的库可供使用，并且它开辟了与其他软件更顺畅地互操作的可能性，例如启用 S/MIME 的邮件客户端。

密码验证

关于您存储密码哈希的愿望，如果您使用 PBKDF2 生成 key ，您可以为此使用标准密码哈希算法(大盐，一千轮哈希)，并获得不同的值。

或者，您可以计算内容的 MAC。密码上的哈希冲突更有可能对攻击者有用；内容上的哈希冲突可能毫无值(value)。但它可以让合法的接收者知道错误的密码被用于解密。

密码盐

Salt有助于阻止预先计算的字典攻击。

假设攻击者有一个可能的密码列表。他可以对每个哈希值进行哈希处理，并将其与受害者密码的哈希值进行比较，看看是否匹配。如果列表很大，这可能需要很长时间。他不想在下一个目标上花费太多时间，所以他将结果记录在一个“字典”中，其中哈希指向其相应的输入。如果密码列表非常非常长，他可以使用 Rainbow Table 之类的技术。节省一些空间。

但是，假设他的下一个目标将他们的密码加盐。即使攻击者知道盐是什么，他的预计算表也毫无值(value)——盐会改变每个密码产生的哈希值。他必须重新散列他列表中的所有密码，将目标的盐添加到输入中。每种不同的盐都需要不同的字典，如果使用了足够多的盐，攻击者将没有空间为所有盐存储字典。交易空间以节省时间不再是一种选择；攻击者必须回退到对他想要攻击的每个目标的列表中的每个密码进行哈希处理。

所以，没有必要对盐保密。确保攻击者没有与该特定盐对应的预先计算的字典就足够了。