Официальный форум KolibriOS
Текущее время: Сб июл 21, 2018 3:24 am

Часовой пояс: UTC+03:00

Начать новую тему  Ответить на тему  [ 3 сообщения ] 
Автор Сообщение
 Заголовок сообщения: IRCC 0.31 mod : enhanced Vigenere chat encryption
СообщениеДобавлено: Ср июл 04, 2018 5:39 pm 
Не в сети

Зарегистрирован: Пн дек 05, 2016 11:04 am
Сообщения: 113
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 )

Source code + the build instruction - are at the end of this message!
They are compatible with IRCC 0.31 current version, as of 13 July 2018
(part of kolibri r7300, check if there were IRCC changes after that)

1) User interface
Спойлер: Показать
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
Спойлер: Показать
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 [i](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[/i]
^^^ already merged to the official IRCC 0.31
Спойлер: Показать
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:
discovered a couple of places in RAM dump where some remaining IRCC buffers were still stored! :roll:

In particular:

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

: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 писал(а):
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
Спойлер: Показать
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
Ё => Е ; Э => Е ; Й => И ; Ы => И ; Ь => ` ; Ъ => ` ; Щ => Ш
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:

[*]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

[*] 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
Спойлер: Показать
[*] Download all the IRCC sources from Kolibri SVN here - ... a6b94343ce
- and move them to a new ./IRCC directory

[*] Do not forget about the external dependencies! ircc.asm, lines 107-112
include "../../"
include "../../"
include "../../"
include "../../"
include "../../"
include "../../develop/libraries/box_lib/trunk/box_lib.mac"
[*] Get these dependencies and move them to a new IRCC's subdirectory, e.g. ./IRCC/external

[*] Verify SHA256 checksum of ./ archive and extract it. You will get these 4 files:
ircc.asm  ircc.ini
Copy these files on top of the official files, with replacement

[*] Change the ircc.asm, lines 111-116 to
include "./external/"
include "./external/"
include "./external/"
include "./external/"
include "./external/"
include "./external/box_lib.mac"

[*] 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:
mv ./IRCC/ ./ircc_0.31_vigenere_13july2018/
7z a -m0=Deflate ./ircc_0.31_vigenere_13july2018.7z ./ircc_0.31_vigenere_13july2018/

[*] 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

[*] Mount this kolibri.img file to a /mnt directory
sudo mount -o loop kolibri.img /mnt
[*] Create a new directory IRCC inside this floppy
sudo mkdir /mnt/IRCC/
[*] Not enough place to copy the sources, so lets remove the official IRCC
sudo rm /mnt/NETWORK/IRCC
[*] Now copy ircc_0.31_vigenere_13july2018.7z inside of it
sudo cp YOUR_PATH/ircc_0.31_vigenere_13july2018.7z /mnt/NETWORK/IRCC/
[*] Copy DOCKY.INI settings file to your convenient location
[*] Open DOCKY.INI and change line 8 to
[*] Unmount kolibri.img now, it is ready:
sudo umount /mnt
Its how I got kolibri_r7300_vigenere.img (r7300 is a current SVN revision)

5) Usage instructions
Спойлер: Показать
[*] 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 - )

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

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

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

[*] 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

[*] 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

[*] 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

[*] 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 (with SHA256 checksums)
8aa10468e5daa957083a6c7708c2734f94396416d1e4b82103ad967b7b7f4535  ./
74f1f444af75b11d3d98f617b9cdab944ac9684b7391293b0c4a949cbc70c8dc  ./
9a6c410f8bd6c6e9f2a261f54e0190698f9a25acb1bb732c63a2458b83370ba5  ./ircc_0.31_vigenere_13july2018.7z
33e3fb3f92280ef02e55e277e7dc44247f5d9df86384fe6e5451f25e2c645bf7  ./
^^^---> 60a19e809d51097d6fd46616057ba8e4eb31b24d434ba7d5a7f82da3786359d1  ./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 0.31 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

Комментарий к файлу: SHA256 = 74f1f444af75b11d3d98f617b9cdab944ac9684b7391293b0c4a949cbc70c8dc [17.33 КБ]
3 скачивания
Комментарий к файлу: SHA256 = 33e3fb3f92280ef02e55e277e7dc44247f5d9df86384fe6e5451f25e2c645bf7 [1.25 МБ]
4 скачивания
Комментарий к файлу: SHA256 = 9a6c410f8bd6c6e9f2a261f54e0190698f9a25acb1bb732c63a2458b83370ba5
ircc_0.31_vigenere_13july2018.7z [42.47 КБ]
3 скачивания
Комментарий к файлу: SHA256 = 8aa10468e5daa957083a6c7708c2734f94396416d1e4b82103ad967b7b7f4535 [43.13 КБ]
3 скачивания

Последний раз редактировалось floppy121 Пт июл 13, 2018 5:45 pm, всего редактировалось 25 раз.
Вернуться к началу
 Заголовок сообщения: Re: IRCC 0.31 mod : enhanced Vigenere chat encryption
СообщениеДобавлено: Ср июл 04, 2018 6:04 pm 
Не в сети

Зарегистрирован: Пн дек 05, 2016 11:04 am
Сообщения: 113
Some parts of our discussion with hidnplayr about this encryption
Спойлер: Показать
hidnplayr писал(а):
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 писал(а):
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 писал(а):
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
Спойлер: Показать
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" (
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: (blowfish encrypt/decrypt in fasm) (kolibrios hash and crypto lib) (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

Вернуться к началу
 Заголовок сообщения: Re: IRCC 0.31 mod : enhanced Vigenere chat encryption
СообщениеДобавлено: Чт июл 05, 2018 5:28 pm 
Не в сети

Зарегистрирован: Пн дек 05, 2016 11:04 am
Сообщения: 113 - Example of using TLS-Library parts for generating PRNG numbers - (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
Hello friend, how areyou doing?
could be transformed to
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:
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

Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 3 сообщения ] 

Часовой пояс: UTC+03:00

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB