使用 Crypto Api 在客户端和服务器之间进行加密和解密的正确方法是什么？
在经历了许多头痛和人们建议停止之后，我终于设法让我的服务器/客户端应用程序使用这个 API 并创建所需的密钥，即会话和交换。
当我将公钥发送到客户端时，它成功导入密钥并且还将使用该密钥加密消息，但是当我将其传回服务器时；它使用会话密钥解密消息，但消息作为垃圾返回（嗯..需要私钥！）。现在这可能是由于我通过 rpc 将加密消息传回的方式造成的，但有些东西告诉我这是别的东西。理想情况下，我需要的是一个清晰明了的解释，说明我应该用所有这些键做什么，因为我当前获得的信息非常混乱。
我是否将交换公钥传递给客户端，以便它可以加密消息并返回解密。
或者：
我实际上应该使用服务器公钥加密客户端会话密钥，然后返回该密钥吗？ （这对我来说听起来不对，但我洗耳恭听！！！）
请留下评论以转移到另一个 API，或从 MSDN 复制粘贴（我已经阅读了所有内容）。我正在使用 Crypto API，只需要清楚地解释服务器应该将哪些密钥传递给客户端，然后客户端应该做什么并传回，以便我最终可以继续...
After many headaches and people advising to stop, I finally managed to get my Server/Client App to work with this API and create the required keys, i.e. Session and Exchange.
When I send the public key to the client, it successfully imports the key and will also encrypt a message using that key, but when I pass it back to the server; it decrypts the message using the session key but the message is returned as garbage (hmm.. private key is needed!). Now this could be due to way I am passing the encrypted message back via rpc, but something tells me it is something else. Ideally what I need is a clear and plain explanation of what it is I should be doing with all these keys, because the information I am currently getting is quite confused.
Do I pass the exchange public key to the client so it can encrypt a message and return for decryption.
Or:
Should I actually be encrypting the clients session key with the servers public key and then return that? (This doesn't sound right to me, but I am all ears!!!)
Please leave out comments to move to another API, or copy pasties from MSDN (I have already read all that). I am working with the Crypto API and just need a clear explanation of what keys the server should pass to the client, and then what the client should do and pass back so I can finally move on...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来，如果您确实决心坚持使用该 API，那么您就走在了正确的道路上:)
密码学中有两个不同的加密算法系列。 1) 使用对称密钥的密钥和 2) 使用非对称密钥的密钥。对称密钥算法（例如 AES、DES...）非常快，只要有一种安全的方法来确保客户端和服务器具有相同的密钥（即会话密钥）并且没有其他人可以访问，就应该使用对称密钥算法那把钥匙。另一方面，非对称密钥算法（例如 RSA...）（也称为私钥/公钥算法）的计算成本要高得多。它们具有一个只能用于加密数据的密钥和一个只能用于解密数据的第二个密钥。正如您所发现的，这些算法非常适合初始握手和会话密钥交换。服务器创建公钥/私钥对并向客户端发送公钥。任何人都可以拦截它，但是当客户端对会话密钥进行编码并将其发送回时，如果窃听者想要找出会话密钥，则公共密钥就没用了。只有服务器可以解码消息，因为它是唯一持有私钥的实体。因此，您最初的问题是，当消息返回时，您没有使用该对中的私钥，而是使用同步会话密钥，因此得到了垃圾。
本质上，您刚刚实现了 SSL 所做的基本握手（如果使用 OpenSSL 库，您可以轻松地使用很少的代码行来完成）。
执行握手后，您现在在客户端和服务器之间就有了一个安全通道。您可能遇到的唯一问题是，如果有人利用您服务器的 IP 地址并开始假装他们是真正的服务器怎么办？您的客户端会认为他正在与真实服务器通信，它将进行密钥交换并开始发送安全信息，但如果攻击者的 PC 恰好位于另一端，则该信息可能最终会落入恶意手中。
这就是 SSL 使用证书的用武之地。证书是使用公钥/私钥的另一个示例。受信任的机构使用私钥对证书哈希代码进行签名，任何人都可以通过使用证书的附加公钥对证书身份数据来验证证书是否有效。这样即使攻击者接管了您服务器的IP地址，也无法欺骗您服务器的证书。
Sounds like you are on the right track if you really are determined to stick with that API :)
There are two distinct families of encryption algorithms in cryptography. 1) Ones that use symmetric keys and 2) those that use asymmetric keys. Symmetric key algorithms (e.g. AES, DES...) are very fast and should be used as long as there's a safe way to make sure both client and server have the same key (i.e. session key) and no one else can gain access to that key. On the other hand, asymmetric key algorithms (e.g. RSA...), which are also known private/public key algorithms, are much more computationally expensive. They have one key which can only be used to encrypt data and a second key which can only be used to decrypt data. These algorithms, as you found out, are perfect for the initial handshake and session key exchange. The server creates public/private key pair and sends the client the public key. Anyone can intercept it, but when the client encodes the session key and sends that back, pbulic key is useless if an eavesdropper wants to find out the session key. Only the server can decode the message as it is the only entity that is holding the private key. So your initial problem was that when the message came back, instead of using the private key from the pair, you were using synchronous session key and thus were getting garbage.
Essentially you've just implemented the basic handshake that SSL does (and you could easily do with very few lines of code if using OpenSSL library).
Once the handshake is performed you now have a secure channel between the client and the server. The only problem you might have is, what if someone piggy backs on your server's IP address and starts pretending like they are the real server? Your client will think he is talking to the real server, it'll do the key exchange and will start sending secure information, but that information might all end up in malicious hands if an attacker's PC happens to be on the other end.
This is where SSL's use of certificates comes in. Certificates are another example of where public/private keys are used. A trusted authority uses private key to sign certificates hash code and anyone can verify that certificate is valid by using it's attach public key against certificates identity data. This way even if attacker takes over your server's IP address, it won't be able to spoof your server's certificate.