mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Considering this would be the 4th time that the hashed-string-length has changed, if you prefer not to change how the key parameter is hashed, and just document the limit in /help, I'd rather have the suggested 'k' switch that allows inputting the key/iv as hex strings, and we can hash our own key and IV without using MD5.

When $encode generates a hashed key due to using 'c' without the 'l' switch, it is hashing only the first 612 bytes of the key parameter. This behavior appears to have changed over the versions, related to prior related fixes, and affects both the RandomIV and Salted__ hashing methods at the same length. This does not affect ECB mode, where the 'l' switch determines whether the key parameter is limited to 56 or 72. So this should only affect users who are hashing very long strings into being their key, in an attempt to offset the usage of MD5.

Through v7.51 the same syntax hashed only the first 256 bytes of the Key Parameter. Then in v7.52 as a side-effect of fixing how literal keys longer than 56 were handled, only the first 56 bytes of the key parameter were hashed. Then, when the limit of hashing only the first 56 bytes was fixed, it changed to the current behavior of hashing only the first 612 bytes.

This next example demonstrates using a fixed Parm4 string, where increasing the length of the key parameter ceases to change the key at lengths exceeding 612. And forum readers should not be worried about all strings in the column having the same beginning, since that's where the header is.
Code
alias blowfish612 {
  var %i $iif($version <= 7.51,246,$iif($version < 7.56,46,602)) , %j 1, %string $str(abcdefghij,400) , %prev
  while (%j isnum 1-20) {
    var %key $left(%string,%i)
    var %line $encode(Message,mcir,%key,Fixed_IV) $&
      $encode(Message,mcs,%key,SameSalt)
    echo $iif(%line === %prev,4) -ag %i : %line
    var %prev %line | inc %i | inc %j
  }
}


Joined: Dec 2002
Posts: 5,434
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,434
Thanks for your bug report. This is by design. The key is limited to what, as far as I can tell, is a reasonable maximum length. I will change the next beta to halt and report an error if someone tries to use a key longer than that, unless you think there is a practical use for longer keys? When implementing features, I can always make a parameter take the maximum possible line length but, in general, I prefer to set a reasonable maximum length for most parameters.

Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Limiting the length of non-literal hashed/salted key strings to 612 should be more more than plenty. As long as an error is generated instead of skipping part of the input, that's great.

As for it being practical, meh. I wouldn't have noticed if I hadn't been using a scheme that had a fixed user-defined Salt paired with key parameter strings that were always differing, but only in the last few characters. I found them sometimes encrypting the same message identically, which turned out to be caused by the unique portion being beyond position 612. Once $encode warns rather than truncating, there should be no problem for users to stay within the lines. Now that I know of the limit, I've modified what I was doing to avoid this happening again.

Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
This is working as expected for keys containing only printable text, but the input is being rejected if longer than 2148 characters, while the string being hashed is limited to 2148 bytes, which can be shorter than the input string if it contains codepoints above 127. I went back to check v7.71 again, and the 612 limit was bytes not a $len.

Keeping the limit at 2148 bytes is fine, though it would be great if it triggers the bad parm error instead of truncating.

Below is a slight modification of the original alias which also lets you specify the string from which %i characters are taken.

* The 1st command's key contains only from the 1-127 codepoint range and rejects the string longer than 2148 before it starts repeating
* The 2nd command's key contains only from the 128-2047 codepoint range, and shows the ciphertext repeating once the length exceeds 1074 characters = 2148 bytes
* The 3rd command's key contains only from the 2048+ codepoint range, and shows the ciphertext repeating once the length exceeds 716, and the repeating pattern is the result of hashing a string that's been truncated in the middle of the 3-byte UTF8 encoding of a text character.

Code
//blowfish612 2140 $str($chr(  77),4000)
//blowfish612 1065 $str($chr(2047),4000)
//blowfish612  705 $str($chr(2048),4000)

alias blowfish612 {
  var %i $iif($version <= 7.51,246,$iif($version < 7.56,46,$iif($version < 7.72,602,2140))) , %j 1, %string $str(abcdefghij,400) , %prev
  if ($1) var %i $1 | if ($2) var %string $2
  while (%j isnum 1-20) {
    var %key $left(%string,%i)
    var %a $encode(Message,mcir,%key,Fixed_IV) , %b $encode(Message,mcs,%key,SameSalt)
    var %line %a %b $&
      $decode(%          a,mcir,%key,Fixed_IV) $decode(          %b,mcs,%key,SameSalt)
    echo $iif(%line === %prev,4) -ag %i : %line
    var %prev %line | inc %i | inc %j
  }
}


Link Copied to Clipboard