如何隐藏应用程序中的密钥？
我有一个 C++ 客户端/服务器应用程序，其中客户端和服务器是我的可执行文件。每次在客户端和服务器之间建立连接时，我都会为该会话生成一个新的加密密钥，并且我希望传输此会话密钥并使用客户端和服务器中内置的静态密钥加密此会话密钥。
但是，在我的可执行文件上运行字符串会显示静态密钥。
如何隐藏客户端和服务器应用程序中嵌入的静态密钥，以便它们不容易被提取，从而允许某人解码我的会话密钥。
I have a C++ client/server application where the client and server are my executable. Each time a connection is made between the client and server, I generate a new encryption key for that session and I wish to transmit this session key and encrypt this session key using a static key that is built into both the client and server.
However, running strings on my executable reveals the static key.
How can I hide the embedded static key in my client and server application so that they are not easily extracted and thus allowing someone to decode my session key.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
他交换密钥的方法“确保”客户端是有效的而不是冒名顶替者。仅使用 DH 安全地交换密钥并不能做到这一点。为了获得相同的功能，他需要实施 PKI 系统。 SSL/TLS 就是为此目的而构建的，它的底层将满足他的需要。
您需要为您的服务器创建一个 CA 并签署客户端证书，以确保它们的真实身份。
His method of exchanging keys "ensures" the client is valid and not an impostor. Just securely exchanging keys using D-H won't do that. In order to get the same functionality he'll need to implement a PKI system. SSL/TLS was built for this purpose which underneath it will do what he needs.
You'll need to create a CA for your server and sign client certificates to ensure that they are who they say they are.
这个问题有一些解决方案，不涉及尝试隐藏密钥（这通常是不可能的）。例如，Diffie-Hellman 密钥交换允许客户端和服务器协商新的秘密会话密钥，而无需通过网络发送它。
There are solutions to this problem that don't involve trying to hide keys (which, in general, is impossible). For example, Diffie-Hellman key exchange allows the client and server to negotiate a new secret session key without ever sending it over the wire.
因此，您计划使用一种特别难以撤消的方法来隐藏您的秘密（可执行文件中的密钥），只有当您知道该方法的秘密时才能撤消该方法，您还需要使用新的超级秘密方法来隐藏该秘密只有当您知道该方法的秘密时才能撤消该操作，我们需要用另一个秘密方法来隐藏该方法，而另一个秘密方法需要我们需要隐藏的另一个秘密......
这是“问题溢出”。我希望你能看到你不会用这种方式解决问题。为每台计算机生成密钥（ssh/sshd 执行此操作）并保护它们。上面同样的问题实际上也适用，因为如果我得到该密钥，它仍然可以进行，但这样您就不会将其硬编码到您的解决方案中，这意味着修复受损的密钥要容易得多。
So, you're planning on hiding your secret (the key in the executable) with an especially hard to undo method that can only be undone if you know the secret of the method, which you also need to hide with a new super secret method that can only be undone if you know the secret of that method, which we need to hide with another secret method requiring another secret that we need to hide...
This is a "problem overflow". I hope you can see you won't solve it this way. Generate the keys per computer (ssh/sshd does this) and protect those. The same problem above actually applies, because if I get that key it's still game up, but this way you don't hard code it into your solution meaning fixing a compromised key is much easier.