write/show/using keys not always agree with enforce_max_key_length about mirc_fish_10 HOT 1 OPEN

A continuation of the issue of using a different key than written to disk is a rare edge case where the password itself begins with a case-insensitive version of the string "cbc:".

The key is correctly written to disk, but is incorrectly reported by FiSH_GetKey10 and is incorrectly used when encrypting the message. I only discovered this from testing a script that would create random text strings to be used as passwords. I already knew that the current system prevents an ECB key from beginning with the 'cbc:' string, but I wanted to see what would happen if the string following the cbc: also happened to begin with "cbc:".

Because the syntax assumes that the input string beginning with cbc: always means that's a flag that the following string should be used in CBC mode, the ECB key cannot begin with case-insensitive CBC:, and the first 4 letters of the actual key are stripped from the display by FiSH_GetKey10, and is also excluded from being part of the actual key used to encrypt the message.

This table shows 3 strings for each row:

#1: the input string given to FiSH_WriteKey10
#2: the string actually written to disk by FiSH_WriteKey10
#2: the string displayed by FiSH_GetKey10
#3: the string actually used as the encryption key in CBC mode:

#1			#2		#3		#4
CBC:test		test		cbc:test	test
cbc:CbC:test		CbC:test	cbc:test	test
cbc:CbC:Cbc:test	CbC:Cbc:test	cbc:Cbc:test	Cbc:test
cbc:CbC:		cbc:		cbc:		NOT ENCRYPTED

A work-around could be to check if the input string begins with case-insensitive "cbc:cbc:", then it would insert a bogus cbc: in front of it in order to have the correct key actually being used. However that would not solve the issue where FiSH_GetKey10 displays the key incorrectly, and it would risk running afoul of the length 56 limit should FiSH_WriteKey10 start enforcing the limit against CBC keys according to the enforce_max_key_length setting.

from mirc_fish_10.