Page 1 of 1

IRCC 0.34 mod : enhanced Vigenere chat encryption

Posted: Wed Jul 04, 2018 5:39 pm
by floppy121
Finally I have implemented IRCC chat encryption:
it is the enhanced Vigenere with 64-byte key length! :D
( could try increasing CRPT_KEY_LEN up to 128-byte,
just don't forget to change RANDOM_BUFFER_SIZE )


The files attached to this post - are outdated, so get a floppy from the latest post below;
but the build & usage instructions - are the same and should work for new IRCC as well.


1) User interface
Spoiler:To enable the encryption, user types /crpt [64-byte key] command, and to disable - just /crpt
While the encryption is enabled: in addition to encrypting user's messages before sending them,
IRCC will try to decrypt all the incoming messages from the other users. If the other users
are not using the encryption (or using a different key) their messages will not be readable

When the encryption is enabled, max length of a message is 64 characters:
edit1 edit_box max size becomes limited by CRPT_KEY_LEN = 64
After a user disables the encryption, will be restored back to USERCMD_MAX_SIZE = 400

Currently this encryption supports 7-bit ASCII symbols: 32-126 code range.
Using the encryption key it transforms 32-126 symbols into the other 32-126 symbols.
"Invalid symbols", e.g. 2-byte Russian characters, currently will not be encrypted/decrypted
( I am printing a warning note about this when a user is enabling the encryption )
Encryption key would not be accepted if there are such invalid characters in it,
as well as if the key is shorter or longer than CRPT_KEY_LEN = 64

Also, your messages will be expanded with random chars + shifted "clockwise",
to slightly improve the encryption strength! Read a message below for more details:
Possible to enable/disable it with " /expd " and " /shft " commands
2) Implementation details
Spoiler:This encryption/decryption applies to all the 8 possible operations:

* sending a message (encrypting)
* sending a /me message (encrypting)
* sending a private /msg mesage (encrypting)
* sending a private /ctcp message (encrypting)

* receiving a message (decrypting)
* receiving a /me message (decrypting)
* receiving a private /msg message (decrypting)
* receiving a private /ctcp message (decrypting)

Spent a lot of time to locate and properly insert the crpt_my_msg and dcrpt_a_msg calls
inside these 8 places of IRCC code - much more time than on the encryption itself
(the encryption/decryption code is very simple and should be easy to verify)
In addition, there is a change_my_msg call - could expand/shift user message before its encryption

While the encryption is enabled, IRCC will not call any function in response to CTCP message,
(to avoid disclosing the system time or IRCC client type to the attacker), instead will try to decrypt
and just print it. After disabling the encryption it will respond to new CTCP messages like its intended

In addition:

* after user disables the encryption - we are erasing the encryption key which has been used
^^^ local change which is specific only for that "IRCC 0.31vcrpt" edition

* after user closes a chat tab we are erasing all its' chat history stored in RAM
before freeing this memory to OS

^^^ already merged to the official IRCC 0.31

* after user correctly closes IRCC (by clicking X in a window bar) before exiting a program
we are erasing all the chat histories of the not-closed-yet chat tabs, as well as the connection details

^^^ already merged to the official IRCC 0.31
Spoiler:If an encrypted message will start with " / " service character - perhaps this may cause some error (either a message delivery failure or a program crash, have not investigated yet) ; luckily, a likehood of this situation is just 1/(126-32) = ~1%
Spoiler:Despite my best efforts to clear everything by implementing all this "clearmem code",
after I closed IRCC client and dumped Kolibri's VirtualBox virtual machine RAM using this instruction: ... x-machine/
discovered a couple of places in RAM dump where some remaining IRCC buffers were still stored! :roll:

In particular:


Code: Select all

NICK kolibri_user..USER kolibri_user 8 * : tetten..join #kolibri..PRIVMSG #kolibri :Hi friends..
PRIVMSG #kolibri :im going to enable this feature now..PRIVMSG #kolibri :TUX`^..
PRIVMSG #kolibri :PWjl`]lj`LQ]'`I \capqWN\nvYX.Sz0q..PRIVMSG #kolibri :TMSXYM..
PRIVMSG benjaoming :Y_L[RPN..
^^^ although my messages are encrypted in this buffer, of course that is not OK.
If I boot a spying OS like Windows 10 after that, it could possibly leak these chats


Code: Select all

:kolibri_user!~kolibri_u@MY_IP_ADDRESS_AND_HOST QUIT :..ERROR :Closing Link: MY_IP_ADDRESS_AND_HOST
()..{This channel is connected to a channel on Learning Equality's Slack 333 kolibri_user #kolibri benjaoming!~benjaomin@HIS-IP-ADDRESS 1510086898.. 353 kolibri_user = #kolibri :kolibri_user kalite-slack CanoeBerry2 366 kolibri_user #kolibri :End of /NAMES list..
^^^ contains the ip addresses and hostnames, also the usernames of people
hidnplayr wrote:Were these buffers addressed in kernel space? (address 0x80000000++)
It's very likely to be the socket buffer which is also not cleared on shutdown
my Kolibri virtual machine was set up as 32 MB RAM to reduce a size of RAM dump I need to search through, so the whole memory was 32 MB = 0x200_0000 size (max address = 0x1FF_FFFF). Buffers have been noticed at the following offsets: 0x04D_0800 , 0x0DA_8000 , 0x0DB_0000 , (and maybe there are some others which I haven't found yet or forgot to write down). I guess a couple at 0x0D*_**** is at the Kernel space. I couldn't check this while in Kolibri because I don't know how to search RAM there or if there's any good Kolibri RAM viewer... Kolibri Debugger is inconvenient as a RAM viewing tool - displays just 6 rows and only within the memory space of that program (everything else is "??")
3) Future plans
Spoiler:3.1) Erase the last remains of chat / private info left inside the RAM when a user exits IRCC

3.2) Find a good way to encrypt the 2-byte characters, preferably by making them 1-byte to maintain
the encryption strength: I already have a good idea, by the interface it will be similar to layout switching,
but I'll have to throw away 33-26 = 7 rarely used most-replaceable letters from the Russian alphabet, in example

Code: Select all

Ё => Е ; Э => Е ; Й => И ; Ы => И ; Ь => ` ; Ъ => ` ; Щ => Ш
If the users would want to speak on Russian, they'll "switch a layout" - e.g. by entering " /swlt " -
and their Russian letters will be converted to the English char 1-byte ASCII codes before the encryption; after the
encryption/transmission/receive/decryption they will be converted back to the Russian 2-byte chars and printed

3.3) Improve the encryption strength:

3.3.1) By making this enhanced Vigenere more stronger. Some ideas:

[*][/b]adding the randomly enough characters to the end of message to fill all the 64 bytes
and then shifting the real message by the random offset inside this "random generated garbage"

IMPLEMENTED ! :D see viewtopic.php?f=11&p=70874#p70886

[*][/b] if a sum of chars is odd, rotate a message before encrypting, and the recipient will rotate it back if a sum of decrypted chars is odd
^ still thinking about it, maybe will implement...

Almost all of these algorithms (implemented and already debugged) in C are here -
I just needed to find a good enough pseudorandom function before rewriting these algorithms to FASM X86 assembly.
Recently we had a small discussion about PRNG functions here - viewtopic.php?f=2&t=3729 ,
and I decided to take HMAC from Kolibri's tiny TLS library -
( initially tried "СЛОН 0.42" from Xakep (Hacker) journal - - but it was buggy )

3.3.2) If ^^^ is not giving enough encryption strength despite our best efforts,
replace the "crpt_my_msg" and "dcrpt_a_msg" functions by a strong encryption algorithm:
either AES256 cipher from Kolibri's tiny TLS library, or a stronger Serpent cipher
with 256-bit length key -
Serpent is stronger than Rijndael, so Serpent should have won the AES contest and is preferable;
also I've seen that somebody implemented it at X86 assembly (should be converted to FASM)

3.3.3) Even stronger, wrap that powerful cipher ("Serpent-256" or AES256,
whatever has been implemented at the previous step)
inside our Vigenere! If that powerful cipher
is producing a ciphertext that is indistinguishable from random noise, and you'll wrap it in a Vigenere,
that will make a frequency-based attacks (how the Vigenere is cracked) totally useless,
so the attacker would be unable to extract the AES or Serpent-256 ciphertext
from the openly transmitted "Vigenere-on-top" ciphertext
4) Build instructions
Spoiler:[*][/b] Download all the IRCC sources from Kolibri SVN here - ... a6b94343ce
- and move them to a new ./IRCC directory

[*][/b] Do not forget about the external dependencies! ircc.asm, lines 107-112

Code: Select all

include "../../"
include "../../"
include "../../"
include "../../"
include "../../"
include "../../develop/libraries/box_lib/trunk/box_lib.mac"
[*][/b] Get these dependencies and move them to a new IRCC's subdirectory, e.g. ./IRCC/external

[*][/b] Verify SHA256 checksum of ./ archive and extract it. You will get these 4 files:

Code: Select all

ircc.asm  ircc.ini
Copy these files on top of the official files, with replacement

[*][/b] Change the ircc.asm, lines 111-116 to

Code: Select all

include "./external/"
include "./external/"
include "./external/"
include "./external/"
include "./external/"
include "./external/box_lib.mac"
[*][/b] Download TLS-Library-RNG from viewtopic.php?f=2&t=3736
and place it inside your IRCC directory: ./IRCC/TLS-Library-RNG

---> Now you got the ircc_0.31_vigenere_13july2018 sources, which could be built separately from Kolibri OS.
These sources are archived as ircc_0.31_vigenere_13july2018.7z using the following commands:

Code: Select all

mv ./IRCC/ ./ircc_0.31_vigenere_13july2018/
7z a -m0=Deflate ./ircc_0.31_vigenere_13july2018.7z ./ircc_0.31_vigenere_13july2018/
[*][/b] Get a fresh KolibriOS from here -
Create a new directory, move either latest-distr.7z or latest-img.7z here,
then extract it with 7za x ./latest-img.7z command to get kolibri.img

[*][/b] Mount this kolibri.img file to a /mnt directory

Code: Select all

sudo mount -o loop kolibri.img /mnt
[*][/b] Create a new directory IRCC inside this floppy

Code: Select all

sudo mkdir /mnt/IRCC/
[*][/b] Not enough place to copy the sources, so lets remove the official IRCC

Code: Select all

sudo rm /mnt/NETWORK/IRCC
[*][/b] Now copy ircc_0.31_vigenere_13july2018.7z inside of it

Code: Select all

sudo cp YOUR_PATH/ircc_0.31_vigenere_13july2018.7z /mnt/IRCC/
[*][/b] Copy DOCKY.INI settings file to your convenient location

Code: Select all

[*][/b] Open DOCKY.INI and change line 8 to

Code: Select all

[*][/b] Unmount kolibri.img now, it is ready:

Code: Select all

sudo umount /mnt
Its how I got kolibri_r7300_vigenere.img (r7300 is a current SVN revision)
5) Usage instructions
Spoiler:[*][/b] Boot kolibri_r7300_vigenere.img: virtual machine, real PC from a floppy or USB drive,
or right from the coreboot open-source BIOS - viewtopic.php?f=25&t=3446
(only if your computer supports it, check the Supported_Motherboards page for more info - )

[*][/b] Open EOLITE and go to IRCC directory - /rd/1/IRCC/

[*][/b] Double click ircc_0.31_vigenere_13july2018.7z archive to open it with uNZ, and Extract to /tmp0/1 (without / at the end)

[*][/b] Click RAM disk /tmp0/1 at the left panel, and go inside the ircc_0.31_vigenere_13july2018 directory

[*][/b] Open IRCC.ASM with TINYPAD text editor, and click Run -> Compile (CTRL+F9). Executable file IRCC should appear in the same directory, but if it does not appear - open BOARD debug board to see whats wrong

[*][/b] Now you could launch IRCC either by double clicking or from DOCKY left dock panel, luckily we have set up a correct path to IRCC executable at DOCKY.INI a few steps ago - /tmp0/1/ircc_0.31_vigenere_13july2018/ircc

[*][/b] To enable the encryption, type /crpt [64-byte key] command, and to disable - just /crpt
While the encryption is enabled: in addition to encrypting your messages before sending them,
IRCC will try to decrypt all the incoming messages from the other users. If the other users
are not using the encryption (or using a different key) their messages will not be readable

[*][/b] If you ever need to debug this app, edit the sources then open IRCC.ASM with TINYPAD to put some debug info to the buffers/registers, insert int 3 at the relevant places, then launch it at MTDBG Kolibri Debugger with Run -> Run in debugger (F10). Press g to run to the next int 3, type d ADDRESS to check the data at this address, and type help for more info. Please note that while int 3 is inserted, you could not just Run -> Run (F9) because it will crash at this int 3 instruction
Attached files:

Code: Select all

./ , ./ircc_0.31_vigenere_13july2018.7z , ./ , ./kolibri_r7300_vigenere.img
You could use WinMerge or kdiff3 / meld utilities to easily review all the changes,
comparing to a directory with the original latest IRCC sources.
I've tried my best to make the sources as clean as possible, with comments,
and of course will be happy to clarify if any questions will arise

new Kolibri floppy with the same encryption added -

Re: IRCC 0.31 mod : enhanced Vigenere chat encryption

Posted: Wed Jul 04, 2018 6:04 pm
by floppy121
Some parts of our discussion with hidnplayr about this encryption
hidnplayr wrote:I understand that the cipher type was chosen for it's ease of implementation. However I don't believe it's very safe against modern attacks (dictionary?)
Yes, you are right - not only its a Vigenere, its implemented without those extra ideas which could have made this weak-by-the-modern-standards-cipher at least slightly stronger. To be honest its more like a "demo encryption" ; much more valuable is how these "crpt/dcrpt" functions have been integrated to your program. At the moment I'm not sure if I would be able to complete all this encryption stuff by myself, so maybe if this "demo encryption" together with its' "interfaces" would be accepted to IRCC its' current shape, if I would be unable to do it by myself, maybe some other people would continue this work and replace the "crpt/dcrpt" functions with some stronger cipher
hidnplayr wrote:Also, quite some work has gone into making IRCC UTF8 capable, it would be better if we could keep it that way
True; I didn't implement UTF8 support because its a bit tricky for that Vigenere (wanted to conceal the Russian letters like I wrote in my previous message, but it required adding the complexity I didn't have time for; and also - if a Vigenere would be replaced by another cipher, then this work might turn out as not-needed)
hidnplayr wrote:How do other clients implement end to end encryption? It would be nice to support some existing protocol so we can chat to existing clients as well..
My goal is to try to achieve a secure communication between two Kolibri IRCC clients, for this usecase: people could put Kolibri floppy image inside their freshly-built coreboot open source BIOS, and they are able to launch Kolibri with its IRCC client right from the BIOS and communicate with each other securely without using HDD's OS. Those who aren't using Kolibri as their main OS, could run it inside the virtual machine to use its' IRCC client, but there's an added security risk: since the host OS could access all the memory of virtual machine, it could also extract the encryption keys and decrypted messages, and even the keyboard keys pressed by a user

Maybe I'm a bit paranoid, but I think there could be weaknesses/backdoors inside the "popular encryption", hidden at some very deep mathematical level and not inside the specific implementation of an algorithm. Also there are cases when the "popular encryption" is weakened for one reason or another: e.g. Serpent didn't won AES contest despite being stronger than Rijndael, just because Rijndael was faster to encrypt/decrypt...
Feedback from hidnplayr regarding the better-encryption-for-IRCC ideas
Spoiler:You seem to be concerned about the data which is available on the wire. (Ethernet)
You cannot possibly hide this data, so any effort on this front seems silly to me. A better approach will be to use SSL/TLS, which most of the public IRC servers today support.
This will only encrypt traffic between the client and server, and not per se to the other client(s).
To solve this completely, and additional cipher, on the protocol level, such as the one you implemented may be used.

I just did some research, and one popular system seems to be "Mircryption" ( ... ircryption)
It encodes the bytes and sends it as base64 string to the server. Too bad they used an by now also outdated encryption algorithm: blowfish.
However, I think this is the way to go, and still believe this "Mircryption" would be nice to have

May you decide to take this on as a challenge, here are some thing that might help you on the way: ... mentation/ (blowfish encrypt/decrypt in fasm) ... 6273e96c69 (kolibrios hash and crypto lib) ... 2Fhttp.asm (base64 encode in fasm in HTTP library) (base64 encode/decode in fasm)

Using blowfish in CBC mode will definitely be more secure then Vigenere, allows UTF8 and at least is some standard.
Last is good because it doesn't rely on 'security through obscurity' and you can talk to other people besides yourself :)

This page has some good information about currently existing methods and a proposal for a new one ... ption.html

Re: IRCC 0.31 mod : enhanced Vigenere chat encryption

Posted: Thu Jul 05, 2018 5:28 pm
by floppy121
viewtopic.php?f=2&t=3736 - Example of using TLS-Library parts for generating PRNG numbers

viewtopic.php?f=2&t=3735 - (rus) Functions-"sources of entropy" for a quality RNG

This stuff has been used for improving the encryption strength of Vigenere:

expand user message with the random generated chars to fill all the 64 bytes
( max length of user message while in " /crpt " mode, equal to CRPT_KEY_LEN length of encryption key )
and then shift user message "clockwise" (right shift) to a random offset

The original message

Code: Select all

Hello friend, how areyou doing?
could be transformed to

Code: Select all

1'-4{r>f1A8:i1Hello friend,how areyou doing?fi2r!9Y1g'1q`0fA:sD3
before its' encryption; still easy to read for recipient, but the resulting ciphertext should be harder to crack.

However, user could always enable/disable these improvements by " /expd " and " /shft " commands

During the development I'm using ./ script to quickly update my modded IRCC archive inside a floppy:

Code: Select all

cd ~
rm ./ircc_0.31_vigenere_13july2018.7z
7z a -m0=Deflate ./ircc_0.31_vigenere_13july2018.7z ./ircc_0.31_vigenere_13july2018/
sudo mount -o loop kolibri_r7300_vigenere.img /mnt
sudo rm /mnt/IRCC/ircc_0.31_vigenere_13july2018.7z
sudo cp ~/ircc_0.31_vigenere_13july2018.7z /mnt/IRCC/
sudo umount /mnt
Before launching this script, make sure that nobody is using the floppy .img file. If a virtual machine is running, close it

Re: IRCC 0.31 mod : enhanced Vigenere chat encryption

Posted: Sun Feb 17, 2019 5:00 pm
by floppy121
Release of kolibri-r7583_2019-FEB-05 with ircc_0.31_vigenere_13july2018.7z inside of it:

Code: Select all

d0323b8d092c42a128468b4bed5c17848c3268bab621af4da2eab007b65a0dc5  ./
^^^---> 4ef3061141384ac167f8085aaa89208cd50d840f1da081dafcf8cd8e14e074c1  ./kolibri_r7583_vigenere.img
See the usage instructions at post above - viewtopic.php?f=11&t=3734&p=72748#p70874

IRCC 0.34 mod : enhanced Vigenere chat encryption

Posted: Sun Feb 18, 2024 2:31 pm
by floppy121
FINALLY... a new release of kolibri_r9977_vigenere.img floppy with ircc_r9977_vigenere.7z inside of it:

Code: Select all

658bb9c86371533846891756309834fcac3854c0538fdefa8f1060737f01d106  ./
318566f0000dfdb5947c5c5eeb429d98b9381279e2782321080afc141d7419d0  ./IRCC
750c1b785ad5f2a25e0b432fc8593764fd4621d856dd766f86f28d2861604eeb  ./ircc_r9977_vigenere.7z
cdce2283754a21dc9b3e8537b6acd7ef52047d48e57d9d90f260a3d3c074e2b0  ./kolibrios_r9977_ircc-fix-chars.patch
dd6619b6f2ccb6698322f4a93b28f4ddf7ae19ffb9f0d1d59e0d1dd20930446c  ./kolibrios_r9977_ircc-vigenere.patch
ed5ef330eaada5fa4ed585859654e4bda3ca3eefd817e891bd0fe3454e47078c  ./kolibri_r9977_vigenere.img
ce9b73a785ca2e813e4a292c4fcd0ea8c9838d3bb5cd61cb235993766e6a31cd  ./README.txt

1) KolibriOS floppy upgraded to r9977 version, i.e. it has a working driver by hidnplayr for QCA8172 Ethernet controller of G505S laptop supported by the opensource coreboot BIOS (and without Intel ME / AMD PSP backdoors inside its CPU) -
2) As a part of this upgrade to r9977, IRCC client has been upgraded from 0.31 to 0.34 version
3) On top of r9977, I apply two patches: ircc-fix-chars.patch (more info here) and ircc-vigenere.patch of this thread, rebased for a new IRCC version
4) Now you can just go to main menu and launch this modded IRCC - but I still include the source code archive, so the old instructions still work
5) To make enough room for this stuff, I had to remove the following games: Kosilka, Xonix, Snake, Pipes, Tanks, Rforces, Descent