Dear Khaled,

in January, I was messing around for several days with Mircryption, which was a non-dll-inject/exe-patch-solution to integrate Blowfish-Channel-En-/Decryption, PM-en-/Decryption and DH1080-key-exchange (as well as the older DH1024) into mIRC.
It didn't work with scripts using on_text events etc. (in case of encrypted texts) but integrated its own Signals:
Code
on *:SIGNAL:MircryptionSignalAll: {

;$1 = event type (input,text,query,notice,action,join,topic,part,kick,quit,nick,mode)
;$2 = target ($chan)
;$3 = speaker ($nick)
;$4 = is $true if text was encrypted or $false if plaintext
;$5- = decrypted text
;/echo TRAPPED MircryptionSignalAll: event: $1 , target: $2 , speaker: $3 , encrypted: $4, firstword = $5, text: $5-
as well as /esay and /emsg to make scripts send encrypted. (maybe also /enotice?)

The compatibility to glftpd's sitebot pzs-ng was so horribly broken, that it refused to send any texts to me or even invite me...
This sitebot can switch between 3 different blowfish implementations, so it might also be worth taking a look how they do it?

I couldn't find a proper "Standard" telling how the key exchange and message en- and decryption should be done properly.
I just found statements like "we do it as implemented by them, because they were first."

It looks like, as long as we stay with ECB, all works fine.
When it comes to CBC, Mircryption uses DH1080_INIT_cbc <pubKey>, but Fish uses DH1080_INIT <pubKey> CBC. They TELL that they want to use CBC.
While other implementations just exchange it as it was ECB (default) mode. And then default to CBC. And detect encrypted messages of style "+OK *<encryptedBytes>===...=" (so starting with *, ending with =s) as CBC.
You can find a summary of my findings in the issue I created in their repo.

My suggestions would be:
- If you want to integrate other key exchange methods than DH1080, use other Notices.
- If other implementations already use some, use those (or at least make you implementation being able to detect and answer properly to those), for compatibility reasons.
- Don't make your users download OpenSSL from somewhere and use the cryptographic implementations from there. better ship it with your Installer. OpenSSL seems to like to just drop compatibility for old Algorithms, when they are no longer secure enough. While users tend to disable cryptography, when it doesn't work. It took me some time to find a version that still works with FTPServers using 0.98, as well with those using the latest
- It would be nice to have a "flag" in the events telling if a text was encrypted or not. Like $4 in MircryptionSignalAll.
- Fish_10 uses a message text suffix to tell "this was encrypted". Mircryption uses different nickname brackets, which I prefer (I once had white brackets for usual messages, green for encrypted ones)
- When you're not sure which new algorithms you would like mIRC to use, mozillla's recommendations and BSI-TR-02102-2 are a good resource (can you just pipe the 2nd one through deepl?)
- Make it backwards compatible. What I mean: When another client doesn't react to your key exchange, use a weaker one and maybe warn the user ("weak key exchange"). If a user answers with ECB finish to a CBC init, just use the ECB one. If he starts texting without the * (cbc indication), just decrypt it and warn. There are already too many implementations that make problems when interacting with each other and the user then just disables it because he doesn't know what's wrong

But that's just my limited view on the topic, you're the boss wink