在这种情况下使用 RSA 加密是否足够安全/可能？
不久前我发现了RSA加密/解密，并且有了一些小经验。目前我正在用 C# 开发一个应用程序，它必须向我的服务器发送一些敏感信息。我可以在 C# 程序中本地加密该信息，将其发送到服务器，然后解密（使用 PHP 脚本）吗？这足以确保除了服务器和客户端之外没有人可以看到原始信息吗？
编辑：客户端（C# 应用程序）不必解密任何信息，因此私钥将仅存储在远程网络服务器（当然是服务器端）上。
Not a long time ago I discovered RSA Encryption / Decryption and I have some little experience. Currently I'm developing an application in C# which has to send to my server some sensitive information. Can I encrypt that information locally in C# program, send it to server, and than decrypt it (using a PHP script)? Is that enough to make sure nobody can see the original info excepting server and client?
EDIT: Client (C# app) doesn't have to decrypt any information, so the private key will be stored only on the remote webserver (server-side of course).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
可能的？是的。棘手吗？非常是的。直接使用 RSA 并不容易；您需要小心地正确使用填充，并对数据进行签名以避免数据- 我建议您只需使用 SSL - 在客户端中硬编码可接受的证书，并验证
这是您要连接的服务器的证书。然后 SSL 库将为您处理所有棘手的细节。如果您正在进行某种批量传输，您还可以考虑调用 GnuPG，或使用其他类似的库。
Possible? Yes. Tricky? VERY yes. Using RSA directly is not easy; you need to be careful to use padding properly, sign the data as well to avoid data-manipulation attacks, etc etc.
I would recommend you simply use SSL - hard-code the acceptable certificate in your client, and verify that's the certificate of the server you're connecting to. Then the SSL library will take care of all the tricky details for you. You could also consider invoking GnuPG, or using some other similar library if you are doing some kind of batch-like transfer.
假设您有一个长度合适的密钥（例如 2048 字节）且尚未被泄露，那么它应该可以。
当然，如果有人有足够的决心并且有足够的计算能力和时间，他们可以尝试暴力破解该消息（他们有可能很早就幸运，但可能性不大）。
Assuming you have a good length key (say 2048 bytes) that has not been compromised, then it should do.
Of course, if someone is determined enough and has enough computing power and time they could try and brute force the message (it is possible that they get lucky early on, but unlikely).
是的，只要您不意外发送私钥，它就是安全的:)我做到了，并且没有人能够解密它，至少在合理的时间内无法解密:)
Yes, it is safe as long as you don't accidentally send the private keys :) I did it, and no one was able to decrypt it, at least, not in a reasonable time :)
这正是 SSL 的构建目的。你要重新发明它吗？
当然可能，但是您使用什么公钥？您是将其嵌入到您的应用程序中还是从服务器中提取？前一种方法很容易受到攻击，而后一种方法又回到了 SSL 的作用。
当然，这是传输层安全的重点，保护传输中的信息。只需使用现有的技术来解决这个问题:)
This is exactly what SSL was built to do. Are you re-inventing it?
Certainly possible but what Public key do you use? Do you embed it into your application or pull it from the server? The former approach is vulnerable, the later is back to exactly what SSL does.
Of course, this is the whole point of transport layer security, protecting the information in transit. Just use the technologies that already exist to solve this problem :)
这取决于您期望客户的安全程度。如果您用于加密数据的密钥随应用程序广泛分布，则它可能会落入可以使用该密钥来计算加密的人的手中，然后您的通信将不安全。但是，如果您的应用程序分发给一组选定的使用者，您知道这些使用者不会允许恶意闯入者获取密钥，那么您可以合理地确定您的密钥是安全的。
这里第一个明显的漏洞是暴露的密钥。假设您使用长度合适的密钥，RSA 通常是一个很好的协议。然而，如果你的钥匙暴露了，就像我上面说的那样，所有的赌注都会失败。
It depends on just how secure you expect your client to be. If the key you use to encrypt the data is distributed widely with the application, it may fall into the hands of someone who can use that key to figure out the encryption, and then your communication would not be secure. However, if your application is distributed to a select set of consumers that you know will not allow a malicious interloper to get the key, then you can be reasonably sure that your key will be secure.
The first obvious vulnerability here is the key being exposed. RSA is generally a good protocol assuming you use a good length key. However, if your key is exposed, like I say above, all bets are off.
直接使用加密库几乎从来都不是一个好主意，因为您可能会错过许多棘手的极端情况，这些情况随后会成为安全漏洞。相反，您应该尝试尽可能使用现有的最高水平的技术。例如，如果您的客户端使用 TCP 连接到服务器，您可以轻松地将其替换为 TLS，TLS 或多或少会自动处理加密和解密。如果使用 HTTP 连接，您可以使用 HTTPS。如果您不确定要使用的最佳技术，请尝试告诉我们更多有关您的客户端和服务器如何通信的信息。
It's almost never a good idea to use cryptography libraries directly, because there are lots of tricky corner cases that you are likely to miss, which then become security holes. Instead you should try to use an existing technology at the highest level possible. For example, if your client connects to the server using TCP, you can easily replace it with TLS, which takes care of the encryption and decryption more or less automatically. If it connects using HTTP, you can use HTTPS. If you're not sure the best technology to use, try telling us a little more about how your client and server communicate.
明显的漏洞取决于您如何分发应用程序。如果它是公开分发的，那么它可能会受到中间人的攻击。它的工作原理是这样的：攻击者会编写一个看起来像你的一样工作的模仿品，但使用他们的密钥将数据发送到他们的服务器。然后他们的服务器解密数据，用您的密钥重新加密并将其发送到您的服务器。任何回复均以类似方式处理。
对于最终客户端来说，唯一可能看到的差异可能是接收回复的时间稍微长一些——但如果你保持机器轻载，否则他们很可能永远不会知道/注意到。
The obvious vulnerability would depend on how you distribute the application. If it's distributed openly, it could be open to a man in the middle attack. It would work something like this: the attacker would write an imitation that appears to work like yours, but uses their key to send the data to their server. Their server then decrypts the data, re-encrypts it with your key and sends it to your server. Any reply is handled similarly.
To the end client, the only difference that's at all likely to be visible might be slightly greater greater time to receive replies -- but if you keep the machine lightly loaded otherwise, there's a pretty fair chance they'd never know/notice.
您是否看过 XML-RPC （通过 https 或其他一些 ssl 方式） - 这也将消除为服务器端编写解析器的需要，因为几乎每种编程语言都有某种客户端/服务器 RCP 包。通常最好使用已建立的安全通信协议。 Vanilla 加密非常适合保护本地空间中的数据（例如加密硬盘或文件），但一旦开始获取和发送，常规 RSA 中就会出现一系列全新的漏洞。 （中间人攻击、欺骗等）
还可以扩展您的加密货币查找 Diffie-Hellman 密钥交换和椭圆曲线加密货币
Have you looked at XML-RPC (over https, or some other flavor of ssl) - this will also eliminate the need to write a parser for your server side as almost every programing language has some sort of client/server RCP package. Its generally better to use an established secure communication protocol. Vanilla crypto its good for securing data in the local space (ala encrypting a hard drive or file) but once you begin to get and send there is a whole new host of vulnerabilities in regular RSA. (Man in the Middle attacks, spoofing etc)
Also to expand your crypto-fu look up Diffie-Hellman key exchange and Elliptic Curve crypto