考虑和客户端服务器场景，你有两个选择：
哪一个更安全？ 如果公钥来自客户CA商店？它会更安全，而不是在客户端应用程序中绑定它吗？
部署将通过安装程序完成，验证每次运行的版本。
答案 0 :(得分：3)
通过（仅）DH密钥交换，客户端无法知道它实际上是他正在与之交谈的服务器。
所以谈话对窃听者来说是安全的，但是有人可能会伪装成服务器并危及客户端。
答案 1 :(得分：2)
别。
如果您需要在生产代码中解决此类问题，请让专家来做。密码学中存在许多微妙的陷阱，你很可能会成为一个剪辑者。
答案 2 :(得分：1)
可以替换嵌入式密钥。一般来说，如果客户的计算机没有通过非软件方式保护，则无法阻止充分激励的攻击者对您的客户进行黑客攻击。即使是TPM也是no panacea。这个问题变成了一个权衡：攻击者的工时与效用（利润，名望和收益）的获得。授权执行计算的程序的唯一真正安全的方法是在您物理控制的服务器上执行所有可许可的计算;通过选择适当的密钥长度，散列方案，密码和c（我不知道的主题），可以使https或SSL足够安全。
这里的原则实际上相当简单：您需要设计一种情况，在这种情况下，保护其密码/许可证密钥/数据/其他任何内容符合客户的最佳利益。例如。如果您有计算服务器并向客户收取服务器时间，则客户密钥是所有者银行帐户的代理。
答案 3 :(得分：1)
使用公钥方案客户端必须生成密钥，您无法确信此密钥是否已安全生成（有人可以访问系统并将密钥生成器更改为始终使用相同的值，将先前的值增加1，无论如何，所述攻击者可以随时降低您的通信量。公钥加密不是为此目的而设计的。
Diffie-Hellman会更好，但托比亚斯说，如果你自己动手，你可能会受到攻击。
答案 4 :(得分：1)
好的私钥算法通常提供更好的性能（据我记忆的数量级或更多）然后是他们的公钥对应物。从这个意义上讲，Diffie-Hellman比客户端 - 服务器架构的RSA更有效率。
如果你的客户端远远多于服务器，你可以实现一个公钥算法来减少它们之间的交换。
然而，正如许多人所说的那样，你应该考虑就此问题聘请/聘请专家，因为存在许多不同类型的攻击（其中大多数只针对实施而不是算法本身）。如果你还想继续，我只能祝你好运，并指出你应该非常仔细阅读这些资源。
答案 5 :(得分：0)
正如托比亚斯上面提到的，如果你不推出自己的协议会更好。我建议使用TLS的实现，或者至少在TLS上建立协议模型。 TLS提供Diffie-Hellman和基于证书的密钥交换选项。