非对称加密算法中如何分配公钥？
非对称加密算法有两个密钥：
- 公钥和
- 私钥
对于客户端和服务器的概念，需要服务器端的公钥来解密客户端的消息。
所以我的问题是我们如何在客户端和服务器之间共享公钥？
我使用的是JAVA，所以如果你的示例包含java代码，这对我来说没问题，或者如果有任何图片信息，这将非常好的。
谢谢你！
There are two keys in asymmetric encryption algorithm
- public key and
- private key
For the concept of client and server, it need to public key on server side to decrypt client's message.
So my question is how can we share public key between client and server?
I am using JAVA, so if your example contains java code this will ok for me, or if any pictorial info, this will very ok.
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果客户端之前没有见过服务器，因此他不知道需要什么公钥，则必须使用第三方中介来验证所涉及的身份。在 P2P 场景中，您拥有所谓的“密钥签名方”，人们在其中交换公钥通过面对面的会面。
如果人们已经彼此认识，那么即使通过不安全的渠道，您也可以使用类似 Diffie-Hellman 交换您的身份，您可以根据您已有的有关该人身份的信息进行验证。
在常见的 HTTPS 场景中，客户端可能还不知道服务器，但服务器会提供由相互信任的第三方验证的证书，以确认其身份。例如，Paypal 可能会向您提供一份证书，上面写着“VeriSign 同意我就是我所说的那个人。”，如果您信任 VeriSign，这个所谓的“信任网络”意味着您会相信 Paypal 就是他们所说的那样。他们是。
在客户端-服务器场景中，服务器需要其私钥和公钥 - 公钥用于加密返回客户端的消息，私钥用于解密客户端发送给他的消息。
服务器通常不知道用户是谁（从密码学角度来说），客户端可能会为其发送的每个请求创建一个新的证书和公钥/私钥对。 这篇 IBM 文章中详细介绍了更改此设置的方法。在通常的 HTTPS 场景中最终发生的是私钥和公钥加密的混合；您可以在这篇相关的SO帖子。
祝你好运！
If the client hasn't met the server before, so he doesn't know what public key to expect, one must use a third party intermediary to validate the identities involved. In P2P scenarios, you have what are called "key signing parties", where people exchange public keys through meeting face-to-face.
If the people already know eachother, then, even through an insecure channel, you can use algorithms like Diffie-Hellman to exchange your identities, which you can validate against the information you already had about the identity of that person.
In a common HTTPS scenario, the client may not already know the server, but the server presents a certificate, validated by a mutually-trusted third party, that acknowledges his identity. For instance, Paypal might present you with a certificate that says "VeriSign agrees I am who I say I am.", and if you trust VeriSign, this "web of trust" as it's called means you'll trust Paypal are who they says they are.
In your client-server scenario, the server needs both its private and public key - the public key is used for encrypting the messages going back to the client, and the private key is used to decrypt the messages the client is sending to him.
The server doesn't usually know who the user is (cryptographically speaking), the client may make a new certificate and public/private keypair for each request it sends. A way to change this is detailed in this IBM article. What ends up happening in usual HTTPS scenarios is a mixture of private and public key encryptions; you can read more about that in this related SO post.
Good luck!