C# 公钥验证 Perl 私钥并用作 AES 密钥？可能和/或可行吗？
我在想是否有可能和/或可行的混淆和安全性，如下所示：
- 客户端与服务器启动会话（这意味着发送并接受了有效的登录名和密码）
- 服务器用私钥加密随机密码然后将使用 Rijndael 的方法进行数据加密，并将两者发送回客户端（密码是加密的随机密码和 Rijndael 的加密数据，这是我们希望客户端工作的内容）
- 客户端将收到两者，验证密码以查看它是否使用我们的密钥对加密，如果是，它将用于解密数据。
据我所知，Rijndael 在密码大小方面有一些限制，所以这是否可能（考虑加密随机密码的输出）？
是否有其他方法与我在这里的想法或试图描述的接近？
这值得吗？
我想要这样的东西的原因主要是为了让任何试图重现我们的服务器与客户端通信的人变得更加困难，除了我们使用智能组装之外。我希望你们关注上面的问题，忘记打包我的代码等。如果可能的话，将其视为客户端/服务器通信安全混乱。
此致。
i was thinking if it is possible and/or viable for obfuscation and security to do as the follow:
- Client start session with Server (which means a valid login and password was sent and accepted)
- Server encrypt a random password with it is Private Key that will then be used into a data encryption using Rijndael's method and send both back to the client (The password which is the encrypted random password and the Rijndael's encrypt data which is what we want for the client to work)
- Client will receive both, verify the password to see wether it was encrypt with our pair of keys or not if so it will be used to decrypt the data.
From what i see, Rijndael has some restrictions as of the password size, so would this be even possible (considering the output of the encrypted random password) ??
Is there antoher approuch that would be close to what i was thinking or trying to describe here ?
Is this even worthed ?
The reason i wanted something like this is mostly to make it harder for anyone trying to reproduce what our server communicates with the client, aside from that we use Smart Assembly. I would like you guys to focus on the questions above and forget about packing my code etc. Think of this as a client / server communication security messure if possible.
Best regards.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我可以解决第一部分。如果服务器使用其私钥对密钥进行加密，则任何拥有其公钥的人都可以对其进行解密。这为中间人攻击留下了一个巨大的漏洞。换句话说，如果我截取了与你相同的令牌，我现在就知道了与你相同的密钥。这意味着我可以看到所有来回的流量。
安全性的关键始终是这个初始密钥交换问题。您可能希望采用行业标准方法，例如用于实际密钥交换的 Diffie-Hellman。希望有帮助
I can address the first part. If the server encrypts a key with their private key, ANYONE with their public key will be able to decrypt it. This leaves a gaping hole open for a man-in-the-middle attack. In other words, if I intercept the same token you do, I now know the same key that you know. This means that I can see all the traffic that is going back and forth.
The crux of security has always been this initial key-exchange problem. You may want to employ an industry-standard approach, like Diffie-Hellman for the actual key exchange. Hope that helps