交换对称密钥
我有一个 WinForms 客户端，它将加密数据发送到 Web 服务。 WinForms客户端创建一个Symmetric RijndaelManaged sessionKey，并且还有一个“硬编码的RSA非对称公钥”。
我正在使用 EncryptedXml 类，这使得打包我的数据变得非常容易。
Web 服务具有“硬编码”的私钥和公钥，并且可以成功解密 SessionKey，然后使用它来解密我发送的实际数据。
这几乎是由 EncryptedData 类自动处理的。
我遇到的问题是，在 Web 服务端，当我想要回复时，我似乎无法弄清楚如何获取发送过来的 SessionKey。
在 Web 服务端进行任何解密之前，我可以看到加密的会话密钥，但在解密 XML 后，它就消失了（因此我没有任何用于回复的会话密钥）。
有什么想法如何获得这个未加密的密钥吗？
I have a WinForms client that is sending encrypted data to a web service. The WinForms client creates a Symmetric RijndaelManaged sessionKey and also has a "hard-coded RSA asymmetric public key".
I am using the EncryptedXml class which makes it really easy to package up my data.
The Web Service has both the private and public keys "hardcoded" and can successfully decrypt the SessionKey and then use it to decrypt the actual data I am sending.
This is pretty much handled automatically by the EncryptedData class.
The problem I am having is that on the Web Service end when I want to reply, I can't seem to figure out how to get the SessionKey that was sent over.
Before I do any decrypting on the Web Service side, I can see the encrypted session key, but after I decrypt the XML, it's gone (and therefore I don't have any session keys for my reply).
Any ideas how I can get this unencrypted key?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您看不到会话密钥的原因是它会自动解密并使用。通常它被视为 XML 的一部分。如果您想获取它，只需使用
encryptedxml.decryptencryptedkey
你应该没问题。请注意，对于所有不太重要的安全警告，此处表示的代码容易受到中间人攻击，并且在较小程度上容易受到填充预言机攻击。不过，它应该有助于阻止大多数窃听尝试。
最后，重复使用会话密钥也被认为是非常糟糕的安全实践。如果您重用它，至少考虑使用 IV，例如每个后续消息的计数器。
The reason that you cannot see the session key is that it is automatically decrypted and used. Normally it is considered part of the XML. If you want to get at it, just use
encryptedxml.decryptencryptedkey
And you should be alright. Note that for all the less important security warnings, the code represented here is vulnerable to both man in the middle attacks and to a lesser extend to padding oracle attacks. It should help against most eavesdropping attempts though.
Finally, reusing a session key is considered pretty bad security practice too. If you reuse it, at least consider using an IV, e.g. a counter for each followup message.