none
RSA Over TCP Connections RRS feed

  • Question

  • Hello,

    I'm using a connection between server and client over TCP protocol. I want the data that is being transfered to be encrypted via RSA encription. I looked for information about it and found that basicly what I need is a private key and a public key.

    My question is what should I transfer while I'm transfering data, and what should I set manualy in the server and the client codes?

    I believe that I should send with my encrypted data the public key, and set manualy in the client/server section the private key. If yes, how do I send the public key and set the private key? If not, what should I do?

    Thanks!
    (If someone has an example of code it will be great..)

    Saturday, March 31, 2018 1:35 PM

All replies

  • Hello,

     Using UDP or TCP has nothing to do with encryption. Network is the road that

    data travels not the data format, i.e. cars and trucks all travel on roads.  What

    is more important is assigning the Encrypt/Decrypt Keys once the Client/Server

    have made connection. Once Key is created then the data can be encrypted

    or decrypted before sent and received, respectively.  Here is a sample flow;

     

     1. Client/Server make connection and agree on encrypt/decrypt key.

     2. Code a RSA method to encryted/decrypted Data.

     3. TCP uses the Data, regardless of state, for input/output.

     4. Client/Server, step 2 if required.

     5. App does whatever else its coded to do.

     

     Normally, the Server will decide the Key and the Client

    will use that until connection is closed.  You can code

    the Key assignment to your preference. Just as long

    as the Client and Server use the Keys properly or data

    corruption may occur.   Seems simple but depends on

    your project end goal.

     

     Hope this helps :)

    • Edited by User3DX Saturday, March 31, 2018 3:39 PM addenom
    Saturday, March 31, 2018 3:35 PM
  • Thanks, but I still don't understand something aboout the keys.

    When a client starts a connection the server should set a public key and a private key, how does the client get the keys? I mean if I'll just send them as I send the other data there will be no point for the encryption...

    Saturday, March 31, 2018 7:50 PM
  • Hello,

     I see your concern but you are forgetting a vital factor. You are the

    coder. You can code a secondary Key for internal encrypt/decrypt use

    that the end User is unaware of, if applicable.

     

     Think about Game Servers and Client. The Devs have code an internal

    Key that allows the Client to connect a Server for initial communication.

    After that the Server and Client agree on a "new Key" to prevent Packet

    Snooping.  As I have said, depends on the end goal of your project.  The

    more secure then the more layers of code. 

     

     Some software vendors use 2 Keys, Private and Public. The Public Key

    allows the end user to tryout the software with limits, functions or usage

    counter. The Private Key allow the software to unlock all those restriction.

     

     Coding the Server and Client security can be simple or complex. Its all up

    to your goals. To effectively use any encryption, both Server and Client must

    be able to use that Key properly.

     

     GUID is fairly good for random Key generation.  You can mask, using

    XOR, on the GUID object before transmitted.  On the Recv end, will

    XOR GUID for true GUID, But the XOR value must be know by both

    Server and Client. There are all sorts of tricks to hide Keys in Data

    Packets.  This topic can be very lengthy too.

     

     Psuedo Example:

     

     GUID = XYXYXYX-00-AA-ABCXYZ;

     XOR = 135792468; Client/Server use this internally.

     SEED = GUID ^ XOR;

     Transmit SEED to Client. Client will XOR ^ SEED = GUID;

     Now the GUID is known to Server and Client and RSA using GUID

    can be implemented with 99.9% error free.

     

    Hope this helps :)

    Saturday, March 31, 2018 9:44 PM