The encryption system

The TF PROTOCOL transmits and receives data encrypted. The client must have the public key of the server. The RSA must be 2048 bit and RSA_PKCS1_OAEP_PADDING padding. The procedure of exchanging keys and generating session keys occurs as follows:

1. The client generates an arbitrary session key which max length cannot exceed 2048 / 8 – 42 bytes, and must be at least 16 bytes.

2. The client encrypts the session key with the server’s public key and sends it.

3. The server decrypts the session key with its own private key.

4. The server sends back OK if the process has been successful, otherwise sends back FAILED, yet in plain text.

If there is an error in this process the connection is terminated by the server.

The encryption session key is an array of at least 16 bytes up to 2048 / 8 – 42 that is generated in a random way and it will be xored with the data sent or received from the server. As soon as the server and the client are in possession of the session key, it must be extracted from it a seed. The seed are the first 8 bytes as a 64bit integer. The algorithm to encrypt and decrypt data with the session key in C looks like this one.

#define KEYLEN 32
char rndkey[KEYLEN] = “the encryption key”;
char data[] = “the data”;
int len = sizeof data;
int decrypt;

int c = 0, keyc = 0;
for (; c < len; c++, keyc++) {
    if (keyc == KEYLEN)
        keyc = 0;
    if (decrypt) {
        /* Unpack received data */
        data[c] = data[c] – (seed >> 56 & 0xFF);
        /* Decrypt received data */
        data[c] ^= rndkey[keyc];
    } else if (encrypt) {
        /* Encrypt data to send */
        data[c] ^= rndkey[keyc];
        /* Pack data to send */
        data[c] = (seed >> 56 & 0xFF) + data[c];
    }
    /* Change seed and encryption key */
    seed = seed * (seed >> 8 & 0xFFFFFFFF) + (seed >> 40 & 0xFFFF);
    if (seed == 0)
        seed = *(int64_t *) rndkey;
    rndkey[keyc] = seed % 256;

From this point forward, all the communication will be encrypted and decrypted with the session key through an algorithm like the above. As the session key changes over time, it must be a copy of those two factors: session key and seed. This allows in a multi- thread environment perform reading and writing operations simultaneously without interference to each other.

It is also required to preserve the session key in its original form, this is, without any transformation. This is a provision in case any extended subsystem requires the original key.

The next step is to send to the server the hash identity. It responds as usual with OK or FAILED exit status.

The summary.

1. The client starts a connection.

2. The client sends the protocol version.

3. The server responds one of these:

   OK

   FAILED 2 : Incompatible protocol.

4. The client sends the session key encrypted with the server’s public key.

5. The server decrypts the session key which will be used to encrypt the rest of the communication. The response is one of these: OK FAILED 25 : Bad public rsa encryption key. From this point on, encrypted.

6. The client sends the hash.

7. The server validates it and responds one of these: OK FAILED 3 : Invalid hash string. Once all the above steps are passed successfully, the communication begins with the command interface. In case of a failure the communication is terminated by the server.