mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2004
Posts: 1,949
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,949
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,230
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,230
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: 1,949
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,949
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.


Link Copied to Clipboard