使用 MD5 从密码生成加密密钥？
我正在编写一个简单的文件加密程序。主要作为学术练习，但也可能供将来认真使用。所有繁重的工作都是由第三方库完成的，但以安全的方式将各个部分组合在一起对于非密码学家来说仍然是一个相当大的挑战。基本上，我已经让一切都按照我认为应该的方式工作了。
我使用 128 位 AES 进行加密，密钥长度为 128 位。我希望用户能够输入可变长度的密码，因此我决定使用 MD5 对密码进行哈希处理，然后使用哈希值作为密钥。我认为这是可以接受的——密钥总是应该是秘密的，所以没有理由担心碰撞攻击。
现在我已经实现了这个，我遇到了几篇文章表明这是一个坏主意。我的问题是：为什么？如果选择了一个好的密码，那么密码本身就应该足够强大，除非通过非凡的（阅读：目前不可行的）蛮力努力，否则永远不会泄露密钥，对吗？我是否应该使用 PBKDF2 之类的东西来生成密钥，或者这对于除了最极端的加密应用程序之外的所有应用程序来说都太过分了？
I'm writing a simple program for file encryption. Mostly as an academic exercise but possibly for future serious use. All of the heavy lifting is done with third-party libraries, but putting the pieces together in a secure manner is still quite a challenge for the non-cryptographer. Basically, I've got just about everything working the way I think it should.
I'm using 128-bit AES for the encryption with a 128-bit key length. I want users to be able to enter in variable-length passwords, so I decided to hash the password with MD5 and then use the hash as the key. I figured this was acceptable--the key is always supposed to be a secret, so there's no reason to worry about collision attacks.
Now that I've implemented this, I ran across a couple articles indicating that this is a bad idea. My question is: why? If a good password is chosen, the cipher is supposed to be strong enough on its own to never reveal the key except via an extraordinary (read: currently infeasible) brute-force effort, right? Should I be using something like PBKDF2 to generate the key or is that just overkill for all but the most extreme cryptographic applications?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这篇关于密钥强化的文章可能会对您有所帮助。基本上，您希望使密钥更强（比密码中的熵更大），并使其从密码中可靠地派生起来非常耗时。
This article on Key strengthening might help you. Basically you want to make the key stronger (more entropy than in a password) and make its derivation from the password reliably time consuming.
好吧，由于您的帖子很笼统，让我陈述一些一般性的事情：
MD5、SHA-0、SHA-1 都是损坏的哈希值，您不应该将它们用于任何加密目的，请使用 SHA-2。< /p>
通常，您应该使用众所周知且有记录的方法从密码中获取密钥（您没有提及哪种语言，请说明您正在使用哪种语言）。
在进行任何类型的安全编程时，最重要的事情是，在做任何事情之前，严格记录您的“威胁模型”。这基本上是您试图阻止的所有攻击的列表，以及您将如何阻止的攻击，以及您无法阻止的攻击类型。这样做非常有趣，您将了解所有攻击和其他有趣的事情。
Well, as your post is general, let me state a few general things:
MD5, SHA-0, SHA-1 are all broken hashes, and you should not use them for any cryptographic purpose, use SHA-2.
You should, generally, use well-known and documented approaches to derriving keys from passwords (you don't mention what language, please say which one you are using).
When doing any sort of security programming, the most important thing to do is, before you do anything, strictly document your 'threat model'. This is basically a listing of all the attacks you are trying to prevent, and how you will do it, and also what sort attacks you can't prevent against. It's quite fun to do, and you'll get to learn about all the attacks and other interesting things.
新问题的答案是：您绝对应该使用 PBKDF2 之类的东西来生成密钥。
我假设您将拥有一个密码（至少 10 个字符、上下数字和标点符号，对吧？），然后它将生成 AES-256 密钥。该密钥将用于加密/解密文件。您希望使用 PBKDF2 之类的工具来降低获取您文件的人通过暴力攻击找出您的密钥/密码的能力。使用 PBKDF2（和随机盐！）之类的东西会增加破坏文件加密的成本。
我真正建议您将其用作玩具，而不是来保护您真正关心的东西。如果您不是安全专家，您就会犯错误，甚至专家（以及很多专家）也会犯错误：http://www.sslshopper.com/article-ssl-and-tls-renegotiation-vulnerability-discovered.html
The answer to your new question is: you should definitely be using something like PBKDF2 to generate the key.
I assume you are going to have a password (at least 10 chars upper lower numbers and punctuation right?) that will then generate an AES-256 key. The key will be used to encrypt/decrypt the file(s). You want to use something like PBKDF2 in order to decrease the ability for someone who gets your file to figure out your key/password through brute force attacks. Using something like PBKDF2 (and a random salt!) increases the cost of breaking the encryption on the file.
What I really recommend is that you use this as a toy and not to protect something you really care about. If you are not a security expert, you are going to make mistakes, even the experts (and lots of them together) make mistakes: http://www.sslshopper.com/article-ssl-and-tls-renegotiation-vulnerability-discovered.html