4

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

8 Answers8

5

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.

bdonlan
  • 224,562
  • 31
  • 268
  • 324
  • ok, I can create a self-signed certificate for my website but is there a way to force it to be accepted by the C# client even if it does not become from a trusted CA (as I said, self signed)? –  Jul 07 '11 at 20:48
  • @develroot, http://stackoverflow.com/questions/695802/using-ssl-and-sslstream-for-peer-to-peer-authentication . You could also just get a startssl cert or something. – bdonlan Jul 07 '11 at 20:51
  • see also http://stackoverflow.com/questions/5225373/asking-sslstream-to-accept-only-a-certificate-signed-by-a-particular-public-key – bdonlan Jul 07 '11 at 20:52
  • depending on what u want to do u may want XML-RCP (over SSL) - its saved me headaches in the past – JERiv Jul 07 '11 at 21:03
1

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

Oded
  • 489,969
  • 99
  • 883
  • 1,009
1

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

Can Poyrazoğlu
  • 33,241
  • 48
  • 191
  • 389
1

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

csharptest.net
  • 62,602
  • 11
  • 71
  • 89
0

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.

Paul Sonier
  • 38,903
  • 3
  • 77
  • 117
  • yes the application will be used widely and the public key (by reverse engineering or other methods) may become available to a lot of malicious users. But I think that's ok, as long as only I have access to the webserver where the private key to decrypt messages is stored, isn't it? –  Jul 07 '11 at 20:37
0

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.

Aaron
  • 2,013
  • 16
  • 22
0

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.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
0

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

Bruno Rohée
  • 3,436
  • 27
  • 32
JERiv
  • 554
  • 1
  • 4
  • 8