/post/3 Back

Encryption method for new TRCS update (tronl)

Posted 2026-09-03 01:39:39
Remember that relay chat server and client from a few months ago? I've been working on a new version that uses netcat and epoll to allow for threadless multi-client and multi-channel communication.

I wanted to add some form of option that lets you enable an encryption filter over your sent messages that would not be built into the server seeing as the server does not hold any messages (unlike the prior version which held a queue backlog of last N messages).

This new version uses an epoll which lets the kernel itself queue and send messages, this improved relay system tends to be faster than the prior versions. Messages show up nearly instantly and at most have a few ms of delay, this would not ever be more than a second (relevant).

The encryption method I've used uses a time-based salt and password scheme using AES-256-GCM from OpenSSL library. This method will seed a randomiser with the current time (to the second) this means that every second a new randomised string can be generated, if for example two clients used the encryptor within the same second then both machines would get the same random string. This random string is used in place of the password, in my implementation a 64-byte string of random ascii characters is generated. The user is able to enter a 16-byte salt along with this if need be. This method works because granted that a message is sent and received in the same second, both sides can technically generate the correct salt required to decrypt/encrypt the message.

Now the server itself supports plaintext and everything in between. the server does not explicitly apply encryption is what I'm trying to say. This is planned to be done through a filter program which you pipe the client into. The server is currently compatible with the NetCat (nc) client, encryption would be as easy as using NetCat and then simply piping the output into the encryption filter like so: nc localhost 8080 | tronl_dec "my_salt"

tronl_dec is the decryption filter and the given string is the 16-byte salt that is totally optional tronl_dec will take any outputted values (from netcat stream) and decrypt them using the given salt.

This does not work without messages being encrypted first, this can be done by piping the prior command out of tronl_enc like so:

tronl_enc "my_salt" | nc localhost 8080 | tronl_dec "my_salt"

Now tronl_enc will wait for input, encrypt it, send it to the server through netcat, then messages outputted from the netcat stream will be decrypted and placed on screen.

The final question is; how does the encryption filter determine if messages can be decrypted? When the plaintext is encrypted, the unicode is obfuscated which (if printed normally like any other string) will result in random unicode box errors and random non-unicode characters. This is painful and unsafe to transport to the server so first it is encoded to hexadecimal which converts everything over to alphanumeric ascii. The first character represents the mode, if its equal to 0F then the decryptor knows to decrypt.

Unix pipes are so useful!