如何实现单个文件的密码保护？

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

我有一个看似可行的策略,看起来很合理,基于我所知道的(这可能只是危险),但我不知道它是否真的是一个好的设计.那么告诉我:这是疯了吗？有更好/最好的方法吗？

第1步:用户输入纯文本密码,例如"MyDifficultPassword"

步骤2:App哈希用户密码并使用该值作为对称密钥来加密/解密数据文件.例如"MyDifficultPassword" - >"HashedUserPwdAndKey".

步骤3:App散列来自步骤2的散列值,并将新值保存在数据文件头(即数据文件的未加密部分)中,并使用该值验证用户的密码.例如"HashedUserPwdAndKey" - >"HashedValueForAuthentication"

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

那么这个设计是合理安全的,还是绝望的天真,或介于两者之间？谢谢!

编辑:澄清和后续问题re:盐.
我认为盐必须保密才有用,但你的答案和链接暗示情况并非如此.例如,由erickson(下面)链接的这个规范说:

因此,这里定义的基于密码的密钥推导是密码,盐和迭代计数的函数,其中后两个量不需要保密.

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

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

密钥生成

我建议使用公认的算法,如PKCS#5版本2.0中定义的PBKDF2,从密码生成密钥.它与您概述的算法类似,但能够生成更长的对称密钥以与AES一起使用.您应该能够找到一个开源库,为不同的算法实现PBE密钥生成器.

文件格式

您还可以考虑使用加密消息语法作为文件的格式.这将需要您的一些研究,但同样有现有的库可供使用,并且它开启了与其他软件(如支持S/MIME的邮件客户端)更顺畅地互操作的可能性.

密码验证

关于您希望存储密码的哈希,如果您使用PBKDF2生成密钥,您可以使用标准密码哈希算法(大盐,一千次哈希),并获得不同的值.

或者,您可以在内容上计算MAC.密码上的哈希冲突更可能对攻击者有用; 内容上的哈希冲突可能毫无价值.但它可以让合法的收件人知道错误的密码用于解密.

密码盐

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

假设攻击者有可能的密码列表.他可以散列每个并将其与受害者密码的哈希值进行比较,看看它是否匹配.如果列表很大,这可能需要很长时间.他不希望在下一个目标上花费那么多时间,因此他将结果记录在"字典"中,其中哈希指向其相应的输入.如果密码列表非常长,他可以使用像彩虹表这样的技术来节省一些空间.

但是,假设他的下一个目标是他们的密码.即使攻击者知道盐是什么,他的预计算表也毫无价值 - 盐会更改每个密码产生的哈希值.他必须重新哈希他列表中的所有密码,将目标的盐粘贴到输入上.每种不同的盐都需要不同的字典,如果使用了足够的盐,攻击者就没有足够的空间来存储所有字典.交易空间以节省时间不再是一种选择; 对于每个要攻击的目标,攻击者必须回退到列表中的每个密码.

因此,没有必要保持盐的秘密.确保攻击者没有与该特定盐相对应的预先计算的字典就足够了.