Is it safe enough / possible to use RSA Encryption in this case?

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).

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.

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 :)

Currently I'm developing an application in C# which has to send to my server some sensitive information.

This is exactly what SSL was built to do. Are you re-inventing it?

Can I encrypt that information locally in C# program, send it to server, and than decrypt it (using a PHP script)?

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.

Is that enough to make sure nobody can see the original info excepting server and client?

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 :)

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.

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.

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