我得到的建议是我怀疑所以我在这里寻求支持回去挑战建议。
我被建议使用Diffie-Helman让双方就密钥达成一致，使用密钥生成AES密钥，然后使用AES加密/解密正在传输的密码。非常类似于示例代码here
使用此方案时，加密密码的长度与未加密密码的长度相同。我应该担心这个吗？
之前，我使用RSA，使用接收者的公钥加密密码。无论密码长度如何，都会导致加密长度为256。那不是更好吗？
答案 0 :(得分：3)
您可以使用任何数据填充任意长度。它不必是随机的。只要它全部加密。我认为这是你最不担心的事情。
请注意，如果您使用Diffie-Hellman，您仍需要验证发送的参数，您可能需要对RSA进行验证。
替代方案是：
如果你做了这一切，那么你还要担心是否重播了交换以使你重用密钥等。
老实说，如果你需要问这个问题，那么你可能没有资格编写加密协议。他们很难做到正确而不是胆小的人。
如果您需要流式传输大量数据，建议您使用SSL / TLS进行交换。 PGP / PKCS＃7如果您只需要发送一条消息。
答案 1 :(得分：3)
首先：不要发明自己的身份验证协议。期。如果你这样做，即使你使用强加密也会出错。有许多现有的记录良好的认证协议已经由密码学家审查，因此被认为是安全的。不要试图“简化”它们，它们已经被简化了。
第二：恕我直言，你永远不应该在网上发送密码进行身份验证（我不知道任何认证协议，包括可怕的不安全的NTLMv1协议）[1]。
如果您已经开始关注“滚动我自己的身份验证方案”路径，那么我将如何使您在上面描述的方案更安全（警告：我不是密码学家 - 我相信有我在这里所描述的严重缺点：
不是直接发送密码，而是发送密码的单向函数（也称为OWF，通常实现为SHA256或更强的加密哈希）。
换句话说，让服务器向客户端发送salt值，将salt添加到密码中，计算密码的OWF + salt值并将OWF结果发送到服务器。在服务器上，将salt添加到密码中，并执行OWF计算。如果结果相同，则密码有效，如果它们不是无效的。
最后，让真正的密码学家审查你所做的一切。他们将在您的实施中发现问题，您将不得不修复它们。他们可能会建议你放弃努力，转而支持现有的已发布协议。
[1] AFAIK，你应该在线路上发送密码的唯一一次是当你更改密码时，你应该将长度填充到块大小的倍数（包括cybertext中的长度）因此，当您解密它时，您可以区分密码和填充。）
答案 2 :(得分：1)
如果可以提供帮助，请不要通过线路发送密码。相反，请使用SRP等方案，该方案使用一个密码对双方进行身份验证。