加密：当我根本不存储密钥时是否需要对密钥进行加盐？
我在整个网络上进行了搜索，包括这里的SO：有很多关于在散列和存储密码之前需要对密码进行加盐的讨论。
如果密码用于计算用于加密的密钥（“基于密码的加密”）：如果您根本不存储密码怎么办？
- [注意：我确实读过：密码、盐和 IV，我需要所有这些吗？ 和 IV 像盐一样工作吗 当然是一个相关的问题：我不确定初始化向量是如何讨论的这里与问题相关]
假设：
对于加密，
- 用户输入主密码，
- 这是 SHA256 哈希值，输出用于 AES256 加密文件，
- 哈希值不是存储（显然主密码也不是）
用于解密
- 用户输入主密码
- 这是 SHA256 哈希值，输出用于解密文件
- 如果解密成功，则密码 - 显然 - 正确
我的问题：
当除了加密文件本身之外不存储任何内容时，在散列主密码之前对主密码进行加盐有什么好处吗？
注意事项：
- 哈希冲突的可能性
- 它可能会减少需要存储盐的
- 。
如果盐丢失/损坏，用户将无法再解密文件
如何检查步骤3中解密成功：这是否需要知道部分文件内容？
- 如果是这样，有多少失礼行为将已知值存储在加密文件中（这并不总是可以防止的 - 攻击者可能会猜测，例如用户的姓氏在文件中的某处被加密 - 这是正确的）。
I searched all over the Net, including here on SO: There is a lot of discussion on the need to salt passwords before hashing and storing them.
In case the password is used to compute a key used for encryption ("Password Based Encryption"): what if you do not store the password at al?
- [Note: I did read SO: Passphrase, Salt and IV, do I need all of these? and Does IV work like salt are certainly a related question: I am not sure how the Initialization Vector discussed there relates to the question here]
Suppose:
For encryption
- the users enters a master password
- this is SHA256 hashed and the output is used to AES256 encrypt a file
- the hash is not stored (and obviously neither is the master password)
For decryption
- The users enters the master password
- This is SHA256 hashed and the output is used to decrypt the file
- If the decryption was successful, the password was - apparently - correct
My question:
When not storing anything except the encrypted file itself, is there any benefit in salting the master password before hashing it?
Considerations:
- it would probably reduce the likelihood of a hash-collision
- it would require the salt to be stored.
if the salt were lost/corrupted the user would not be able to decrypt the file anymore
how to check for successful decryption in step3: does this require part of the file contents to be known?
- if so, how much of a faux-pas is storing a known value in an encrypted file (this cannot always be prevented - an attacker might guess that for example the users last name is encrypted somewhere in the file - an be correct).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您不存储主密码，则无需对其加盐。如果您重复使用主密码来生成大量一次性密码，则需要根据需要对其进行加密和解密存储。
加盐用于长期存储必须多次匹配的用户密码，以便具有相同密码的人不会拥有相同的哈希值，这将有助于窃取文件的攻击者。
Salt 用于长期存储中的散列，IV 用于使用 CBC 模式（或 CTR 模式，也可称为随机数）进行加密。
至于检查您的文件是否已正确解密，只需确保您使用像 PKCS7 这样的填充即可。当最后一个块被解密时，将检查填充以确保其格式正确。如果解密失败，则填充的格式将不正确，并且您应该收到“填充失败”错误。
If you are not storing the master password then there is no need to salt it. If you are reusing the master password to generate a lot of single-use passwords then it will need to be stored encrypted and decrypted as required.
Salting is for long term storing of user passwords that have to be matched more than once so that people with the same password don't have the same hash, which would help an attacker who stole the file.
Salt is for hashing in long term storage, an IV is for encryption using CBC mode (or CTR mode where it can also be called a nonce).
As to checking that your file has decrypted correctly, just ensure that you use a padding like PKCS7. When the last block is decrypted the padding will be checked to ensure it is in the right format. If the decryption failed then the padding will not be correctly formatted and you should get a "Padding failed" error.