The previous suggestions for $encode Blowfish can pretty much be boiled down to just this main request that can't be scripted around, which is having some kind of 'k' switch that makes the Blowfish 3rd and 4th parameters be seen as the hex encoding of binary byte strings, rather than seeing them as text.

--

My main interest in this would be using the hex inputs as a literal key and literal IV, and it wouldn't need to be supported as the hex encoding of the input to the MD5 hashing, unless it's easiest to have all switch combos handle string lengths the same way regardless if 'k' were used.

With this switch, the 612 hash limit wouldn't need to be fixed other than just documenting it in /help, since it would be pointless to use a literal binary key that just gets fed to the MD5 hash.

This change would make it possible to script a better method of hashing strings into a literal-hex-key and literal-hex-iv, instead of the historical method using MD5. So if this switch was valid only with the 'clir' 'e' 'el' syntaxex, that'd be fine, unless it's easier to just have all formats be identical except for the inputs seen as hex instead of text.

If using the 'k' switch, the Parm4 IV would be 16 hex digits forming the user-defined 8-byte string, and the key would be seen as being binary encoded as hex, and could be a binary string loaded the same way that ECB mode handles the 56 or 72 byte limit.

But other than being able to handle the input string as pure binary, nothing should need to change for how things are handled when the 'k' switch isn't used.

Once I see such a 'k' switch implemented, I can post some brief demo commands that show several simple ways that encoding with hex key/iv can easily interact with $decode the way $decode currently behaves. Other than $decode also handling the hex key the same way.

The 'k' switch for hex encoding of both key and IV parms solves issues:

  • #1 Allowing all IV strings to be defined with the 4th Parameter.
    .
    Approximately 1/37 of 8 byte strings randomly created in the absence of the 4th parm contain 0x00 bytes which are followed by a different byte value, and these cannot be defined using the 4th paramater as a text string.
    .
  • #2 Currently can't define literal keys if they're not UTF8 text. Bruce Schneier's Blowfish page has 59 different test vectors, and only 4 of the 59 test keys is valid UTF8 text, and none of those is normal text in the printable range.
    .
  • #3 Allows a script to create a replacement for the default key hashing design, without needing to add another switch to define an improved hash.

    The key hashing methods are calculated correctly according to the intended design, but they're an archaic method, and a superior replacement can be scripted (moreso if HMAC itself starts accepting binary keys). An example is how $encode(string,mcir,abc,12345678) does hash the 'abc' key into a 56-byte non-UTF8 binary key, but it's a key where the first 16 bytes is the $md5(abc) string, and there are never any hashed messages keys where the 1st 16 bytes are identical to each other, but where the remaining 40-of-56 can be anything other than 1 specific string.


Once there's such a 'k' switch, I can post example scripts of how to use 'k' when scripting a superior replacement for the current methods of hashing non-literal keys, as well as doing a scripted substitute for some of the other earlier feature requests, where they were intended to help shrink the length of the ciphertext, which helps longer plaintext messages squeeze within the length of an IRC message, in spite of the needed mime encoding that lengthens the message to be a little longer than 4/3rds as long as the plain text.