IRCC 0.34 mod : enhanced Vigenere chat encryption
Posted: Wed Jul 04, 2018 5:39 pm
Finally I have implemented IRCC chat encryption:
it is the enhanced Vigenere with 64-byte key length!
( could try increasing CRPT_KEY_LEN up to 128-byte,
just don't forget to change RANDOM_BUFFER_SIZE )
https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher
NOTE:
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.
USER INSTRUCTIONS:
1) User interface
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:
viewtopic.php?f=11&t=3734&p=70874#p70886
Possible to enable/disable it with " /expd " and " /shft " commands
2) Implementation details
* 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 ERRATA WARNING
after I closed IRCC client and dumped Kolibri's VirtualBox virtual machine RAM using this instruction:
https://www.andreafortuna.org/forensics ... x-machine/
discovered a couple of places in RAM dump where some remaining IRCC buffers were still stored!
In particular:
1. ^^^ 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
2. ^^^ contains the ip addresses and hostnames, also the usernames of people
3) Future plans
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:
[*][/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 ! 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 - https://pastebin.com/Ph0kGkUS
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 - http://board.kolibrios.org/viewtopic.php?t=3290#p65710
( initially tried "СЛОН 0.42" from Xakep (Hacker) journal - https://xakep.ru/2005/01/20/25272/ - 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 - https://en.wikipedia.org/wiki/Serpent_(cipher)
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
- and move them to a new ./IRCC directory
[*][/b] Do not forget about the external dependencies! ircc.asm, lines 107-112 [*][/b] Get these dependencies and move them to a new IRCC's subdirectory, e.g. ./IRCC/external
[*][/b] Verify SHA256 checksum of ./ircc_0.31_vigenere_13july2018_diff.zip archive and extract it. You will get these 4 files: Copy these files on top of the official files, with replacement
[*][/b] Change the ircc.asm, lines 111-116 to
[*][/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:
[*][/b] Get a fresh KolibriOS from here - http://builds.kolibrios.org/eng/
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 [*][/b] Create a new directory IRCC inside this floppy [*][/b] Not enough place to copy the sources, so lets remove the official IRCC [*][/b] Now copy ircc_0.31_vigenere_13july2018.7z inside of it [*][/b] Copy DOCKY.INI settings file to your convenient location [*][/b] Open DOCKY.INI and change line 8 to [*][/b] Unmount kolibri.img now, it is ready: Its how I got kolibri_r7300_vigenere.img (r7300 is a current SVN revision)
5) Usage instructions
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 - https://coreboot.org/status/board-status.html )
[*][/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: 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 - http://board.kolibrios.org/viewtopic.php?p=80204#p80204
it is the enhanced Vigenere with 64-byte key length!
( could try increasing CRPT_KEY_LEN up to 128-byte,
just don't forget to change RANDOM_BUFFER_SIZE )
https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher
NOTE:
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.
USER INSTRUCTIONS:
1) User interface
Spoiler:
To enable the encryption, user types /crpt [64-byte key] command, and to disable - just /crptWhile 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:
viewtopic.php?f=11&t=3734&p=70874#p70886
Possible to enable/disable it with " /expd " and " /shft " commands
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:
https://www.andreafortuna.org/forensics ... x-machine/
discovered a couple of places in RAM dump where some remaining IRCC buffers were still stored!
In particular:
1.
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..
If I boot a spying OS like Windows 10 after that, it could possibly leak these chats
2.
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
:hobana.freenode.net 333 kolibri_user #kolibri benjaoming!~benjaomin@HIS-IP-ADDRESS 1510086898..
:hobana.freenode.net 353 kolibri_user = #kolibri :kolibri_user kalite-slack CanoeBerry2
benjaoming..:hobana.freenode.net 366 kolibri_user #kolibri :End of /NAMES list..
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 "??")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
Spoiler:
3.1) Erase the last remains of chat / private info left inside the RAM when a user exits IRCC3.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
Ё => Е ; Э => Е ; Й => И ; Ы => И ; Ь => ` ; Ъ => ` ; Щ => Ш
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]
and then shifting the real message by the random offset inside this "random generated garbage"
IMPLEMENTED ! 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 - https://pastebin.com/Ph0kGkUS
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 - http://board.kolibrios.org/viewtopic.php?t=3290#p65710
( initially tried "СЛОН 0.42" from Xakep (Hacker) journal - https://xakep.ru/2005/01/20/25272/ - 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 - https://en.wikipedia.org/wiki/Serpent_(cipher)
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
Spoiler:
[*][/b] Download all the IRCC sources from Kolibri SVN here - http://websvn.kolibrios.org/listing.php ... 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 "../../macros.inc"
include "../../proc32.inc"
include "../../dll.inc"
include "../../network.inc"
include "../../struct.inc"
include "../../develop/libraries/box_lib/trunk/box_lib.mac"
[*][/b] Verify SHA256 checksum of ./ircc_0.31_vigenere_13july2018_diff.zip archive and extract it. You will get these 4 files:
Code: Select all
ircc.asm ircc.ini serverparser.inc userparser.inc
[*][/b] Change the ircc.asm, lines 111-116 to
Code: Select all
include "./external/macros.inc"
include "./external/proc32.inc"
include "./external/dll.inc"
include "./external/network.inc"
include "./external/struct.inc"
include "./external/box_lib.mac"
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/
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
Code: Select all
sudo mkdir /mnt/IRCC/
Code: Select all
sudo rm /mnt/NETWORK/IRCC
Code: Select all
sudo cp YOUR_PATH/ircc_0.31_vigenere_13july2018.7z /mnt/IRCC/
Code: Select all
sudo cp /mnt/SETTINGS/DOCKY.INI YOUR_PATH
Code: Select all
path=/tmp0/1/ircc_0.31_vigenere_13july2018/ircc
Code: Select all
sudo umount /mnt
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 - https://coreboot.org/status/board-status.html )
[*][/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
Code: Select all
./ircc_0.31_vigenere_13july2018_diff.zip , ./ircc_0.31_vigenere_13july2018.7z , ./kolibri_r7300_vigenere.zip , ./kolibri_r7300_vigenere.img
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 - http://board.kolibrios.org/viewtopic.php?p=80204#p80204