ECB and CBC modes shouldn't support decrypting each other's messages

[maroonbells]

FiSH should either eliminate the default way it enables CBC and ECB modes to interact with each other, or offer a blow.ini option to disable it. The current behavior weakens the security strength of FiSH by not making it obvious when 1/few nick(s) in channel defines the key without the cbc: prefix used by the majority, causing all their messages to be ECB without anyone else being the wiser.

The 'cbc:' prefix for a key is affecting ONLY how the message is encrypted. However, it's still allowing people to read CBC and ECB messages, regardless how their own key is set. When someone's key is set as 'cbc:abc', they're able to ALSO read ECB messages created with key 'abc', and when their key is set as the ECB 'abc', they're ALSO able to read CBC messages created with key 'cbc:abc'. In effect, the DLL is using the presence of the '*' prefix to choose whether to decrypt by adding/removing/keeping the 'cbc:' prefix of the key you're using.

Since FiSH only displays messages in their decrypted form, this makes it too easy for someone to use 'key' as their key instead of 'cbc:key', with nobody else in channel being aware of this unless someone runs a bot which doesn't have FiSH enabled for that channel, so they can check to see whether all encrypted messages begin with the '*' flag.

Because the key needs to have the 'cbc:' prefix in order to avoid creating messages with the ECB behavior, it easy for people to accidentally set their key incorrectly without it, without having themselves or the rest of the channel being the wiser, since everyone can still decrypt each other's messages.

If not made the default, there should at least be an option for FiSH to either decode only messages matching their own key, or include a warning that the message uses a different feedback mode than their own key uses. It would be easy to add a change to the .mrc script to recognize a blow.ini option to reject creating a key without the 'cbc:' prefix, but that doesn't prevent someone else from creating and sending ECB messages.

In addition to the normal reasons why it's better to use another feedback mode besides ECB, the ECB messages are more likely to become too long for the shorter 510 network message limit where IRCv3 isn't being used. CBC messages are encoded using mime which encodes 3 binary as 4 text for a 133% overhead, while ECB messages are encoded using a proprietary encoding which encodes 8 binary as 12 text for a 150% overhead. Even though the CBC encoded messages are longer than the ECB messages due to including the IV, once the plaintext message is longer than 80, the ECB messages are longer, and the extra ECB length increases as the plaintext's length increases, making it be much more likely to run afoul of the 510 line length limit for channel messages.

This enabling behavior doesn't extend completely to the Export functions, but this is an example where a CBC message is created with the "*" prefix, yet "FiSH_decrypt_msg" is able to decrypt that using an ECB key that doesn't have the cbc: prefix.

//var -s %enc $dll(FiSH_10.dll,FiSH_encrypt_msg,cbc:key this is a CBC message) | echo -a decrypted by ECB key: $dll(FiSH_10.dll,FiSH_decrypt_msg,key %enc)

[SlMaker]

It's a real security issue as a mIRC user does not have any chance to know if the others in the channel really use the more secure CBC mode or the worse ECB mode.
So you might think you're on the safe side because you can communicate with all people in the channel but you might be the only one using CBC without knowing it. So this behaviour should be completely removed for higher security or at least mark all incoming/outgoing messages with the mode used.