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:
Ё => Е ; Э => Е ; Й => И ; Ы => И ; Ь => ` ; Ъ => ` ; Щ => Ш
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 ! 
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 -
https://pastebin.com/Ph0kGkUSI 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
Register
Login
FAQ
Search
Members
