RAR3: caveat if we ever implement support for lengths > 28

As already mentioned over on a hashcat github issue, JTR has the same "false negatives" problem that hashcat had (see https://github.com/hashcat/hashcat/issues/1334#issuecomment-672768259 and https://github.com/hashcat/hashcat/issues/2390).

The fix we applied to hashcat was https://github.com/hashcat/hashcat/pull/2419 , the problem as mentioned in https://github.com/hashcat/hashcat/issues/2390 is that the RAR code uses a special sha1_process_rar29 () function that gives different results if the input/password is > 28 bytes.

An example is this:

$RAR3$*0*c148f4980f2fb9c2*4fe19828696a3e1fa53c6b15bfa8fa0f

password is:

hashcatrockshashcatrockshashcatrocks

whole .rar file in base64:

UmFyIRoHAM6Zc4AADQAAAAAAAADBSPSYDy+5wh/zxGEaKoukRI6UpX25EfkeMSDFY65pDoR7l1eyaazRiBNNWuhNr5Kozf1loyZl6LiBGnQ4HkmkxoGin58ASmg2wBvogvVE3GOg0MQpIyhwwUj0mA8vucJP4ZgoaWo+H6U8axW/qPoP

I would suggest that JTR implements a similar fix, to avoid any false negatives (this seems to affect both the RAR3-hp and RAR3-p hashes).

Thanks

test.rar.zip

Start by locating the RAR code and its special sha1_process_rar29() function, then compare its handling of inputs over 28 bytes with the referenced hashcat fix. Use the supplied RAR3-hp and RAR3-p example, including test.rar.zip, to verify that passwords longer than 28 bytes no longer produce false negatives.