对于通过线路发送密码，哪个更安全：Diffie-Hellman/AES 还是 RSA？ （令我困扰的是 AES 不会掩盖密码长度）
我收到了一些令我怀疑的建议，因此我在这里寻求支持，以便回去质疑这些建议。
有人建议我使用 Diffie-Hellman 来让双方就密钥达成一致，使用密钥生成 AES 密钥，然后使用 AES 加密/解密正在传输的密码。与此处的示例代码非常相似，
当使用此方案时，加密密码的长度与未加密密码的长度相同。我应该担心这个吗？
之前，我使用 RSA，用接收者的公钥对密码进行加密。无论密码长度是多少，这都会导致加密长度为 256。那不是更好吗？
I was given advice that I am suspicious about so I'm looking for support here to go back and challenge the advice.
I was advised to use Diffie-Hellman to get both sides to agree on a secret key, use the secret key to generate an AES key, and then use AES to encrypt/decrypt passwords that are being transmitted. Pretty much like the sample code here
When using this scheme, the length of the encrypted password is the same as the length of the unencrypted password. Should I be worried about this?
Before, I was using RSA, encrypting the passwords with the receiver's public key. This was resulting in an encrypted length of 256 no matter what the password length. Isn't that better?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以用任何数据填充到任何长度。它不一定是随机的。只要全部加密就可以了。我认为这是你最不担心的。
请注意，如果您使用 Diffie-Hellman，您仍然需要对发送的参数进行身份验证，这可能需要使用 RSA 来完成。
替代方法是：
如果你做了所有这些，那么你还必须担心交换是否已重播以使你重用密钥等。
老实说，如果你需要问这个问题，那么你可能没有资格编写加密协议。它们极难做到正确，而且不适合胆小的人。
如果您需要传输大量数据，建议您使用 SSL/TLS 进行交换。 PGP/PKCS#7 如果您只需要发送一条消息。
You can just pad to whatever length with any data. It doesn't have to be random. As long as it's all encrypted. I think though that is the least of your worries.
Note if you use Diffie-Hellman you still need to authenticate the parameters sent, which you probably need to do with RSA.
The alternatives are:
If you do all this, then you have to also worry about whether exchanges have been replayed to make you reuse keys etc.
To be honest if you need to ask this question then you probably are not qualified to write a crypto protocol. They are extremely hard to get right and not for the faint hearted.
Suggest you use SSL/TLS for your exchange if you need to stream a lot of data. PGP/PKCS#7 if you just need to send a single message.
首先：不要发明自己的身份验证协议。时期。如果这样做，即使您使用强加密，您也会出错。有许多现有的有据可查的身份验证协议已经过密码学家的审查，因此被认为是安全的。不要试图“简化”它们，它们已经被简化了。
第二：恕我直言，您永远不应该通过网络发送密码进行身份验证（我不知道有任何身份验证协议可以这样做，包括极其不安全的 NTLMv1 协议）[1]。
如果您决心走上“推出我自己的身份验证方案”之路，那么我将如何使您上面描述的方案更加安全（警告：我不是密码学家 - 我相信存在严重的弱点我在这里描述的内容）：
不要直接发送密码，而是发送密码的单向函数（也称为 OWF，通常实现为 SHA256 或更强的加密哈希）。
换句话说，让服务器向客户端发送盐值，将盐添加到密码中，计算密码+盐值的 OWF 并将 OWF 结果发送到服务器。在服务器上，将盐添加到密码中并执行 OWF 计算。如果结果相同，则密码有效，否则密码无效。
最后，让真正的密码学家对你所做的一切进行审查。他们会发现您实施中的问题，而您必须解决这些问题。他们可能会建议您放弃您的努力，转而采用现有的已发布协议。
[1] AFAIK，您应该在网上发送密码的唯一时间是当您更改密码时，即使如此，您也应该将长度填充到块大小的倍数（包括网络文本中的长度，以便当当你解密它时，你可以区分密码和填充）。
First off: Don't invent your own authentication protocol. Period. If you do, you WILL get it wrong even if you're using strong encryption. There are a number of existing well documented authentication protocols that have been vetted by cryptographers and thus are thought to be secure. Don't be tempted to "simplify" them, they've already been simplified.
Second: IMHO you should never send passwords on the wire for authentication (I'm not aware of any authentication protocol which does, including the hideously insecure NTLMv1 protocol)[1].
If you're dead set on going down the "roll my own authentication scheme" path, here's how I'd make the scheme you described above more secure (Caveat: I'm not a cryptographer - I believe that there are serious weaknesses in what I'm describing here):
Instead of sending the password directly, send a one-way-function (also known as a OWF, often implemented as a cryptographic hash like SHA256 or stronger) of the password.
In other words, have the server send the client a salt value, add the salt to the password, compute the OWF of the password+salt value and send the OWF result to the server. On the server, add the salt to the password and also perform the OWF calculation. If the results are the same, the password is valid, if they're not it's invalid.
And finally have whatever you do reviewed by a real cryptographer. They will find problems in your implementation and you're going to have to fix them. They're likely to suggest that you abandon your effort in favor of an existing published protocol.
[1] AFAIK, the only time you should send the password on the wire is when you're changing the password and even then, you should pad the length to a multiple of the block size (include the length in the cybertext so that when you decrypt it you can distinguish between the password and the padding).
如果可以的话，根本不要通过网络发送密码。相反，请使用 SRP 等方案，该方案使用一个密码对双方进行身份验证。
If you can help it, don't send passwords over the wire at all. Instead, use a scheme like SRP, which authenticates both parties with one password.