AdiIRC

FYI. The $encrypt/$decrypt pages both say EBC, when they really mean 'ECB' for Electronic Code Book.

The output appears to be the 8_bytes-to-12_text encoding used in FISH, and doesn't offer a binary input/output switch, so until I can make an alias to translate that output to binary, it's hard to verify the test vectors. But I did find edge cases where the password is not handled correctly.

1. $null password crashes:

//echo -a $encrypt(test,$null)
//echo -a $decrypt(test,$null)

2. Codepoints above 127 are used as if $chr(63) "?" is used.

//echo -a #1 $encrypt(test,pass $+ $chr(10004))
//echo -a #2 $encrypt(test,pass $+ $chr(233))
//echo -a #3 $encrypt(test,pass $+ $chr(224))
//echo -a #4 $encrypt(test,pass $+ $chr(63))
//echo -a $decrypt(C9.i6Y5LrozZ,pass $+ $chr(63))

I believe that, when the password is a text string, the correct bytes to use are from UTF-8 encoding the input, or to reject input that isn't 7-bit. If the input is ever binary, such as using a sha1/sha256/sha512 digest, the input should retain the 0x00's and 0x80-0xff's without UTF8 encoding them.

3. Password is expanded to fill the 72-byte internal key incorrectly.

//echo -a $encrypt(test,$str(abcde,1)) input length 5x1=5
//echo -a $encrypt(test,$str(abcde,11)) input length 5x11=55
//echo -a $encrypt(test,$str(abcde,12)) input length 5x12=60

These 3 produce identical outputs. The first two should do that, the 3rd should not. From how it handles the 4 combinations of 71 or 72 a's followed by either 'b' or 'c', it appears $encrypt() is using $left(input,72) then replicating that until length 72 if it's shorter.

The correct method is to use only the first 56 bytes of the input, even if that chops in the middle of a multi-byte UTF8 symbol, then replicate that 1-56 byte string until it has length of 72. Blowfish design requires that at least 16 of the 72 bytes be repeated. It's your call whether to use $left($utfencode(input),56) or to generate an error if the input contains more than 56 bytes (not 56 characters).