Hi y'all,
I was looking at the source code to try and write some documentation about how to implement new modules and something caught my eye when looking at the COMPARE_M_SCALAR macro defined in OpenCL/inc_scalar.cl.
This macro takes 4 inputs. Now when we look at the file OpenCL/m00000_a0-oure.cl, the macro is called (line 59) with 4 integers of type u32. This is expected because m00000 is MD5 and the output of MD5 is 4 "words" of 32 bits (see rfc 1321 https://tools.ietf.org/html/rfc1321 ). However, when looking at the code in OpenCL/m00100_a0-pure.cl (also line 59) the macro is also called with 4 integers of type u32 even though the output of SHA1 (m00100 corresponds to SHA1) is 160 bits and therefore require 5 "words" of 32 bits. It looks to me like the fifth word is not used for the comparison at all.
Does this mean that Hashcat is actually using only a part of the produces SHA1 hash to do the comparison ?
To be fair, I'm guessing the use-case of Hashcat being to recover passwords, it is probably safe to assume that there are no two SHA1 hashes that share the same first 132bits and are produced by two strings within a reasonable range of length for passwords.
Is this really what's happening or did I miss something ?
Thank you in advance for your replies.
I was looking at the source code to try and write some documentation about how to implement new modules and something caught my eye when looking at the COMPARE_M_SCALAR macro defined in OpenCL/inc_scalar.cl.
This macro takes 4 inputs. Now when we look at the file OpenCL/m00000_a0-oure.cl, the macro is called (line 59) with 4 integers of type u32. This is expected because m00000 is MD5 and the output of MD5 is 4 "words" of 32 bits (see rfc 1321 https://tools.ietf.org/html/rfc1321 ). However, when looking at the code in OpenCL/m00100_a0-pure.cl (also line 59) the macro is also called with 4 integers of type u32 even though the output of SHA1 (m00100 corresponds to SHA1) is 160 bits and therefore require 5 "words" of 32 bits. It looks to me like the fifth word is not used for the comparison at all.
Does this mean that Hashcat is actually using only a part of the produces SHA1 hash to do the comparison ?
To be fair, I'm guessing the use-case of Hashcat being to recover passwords, it is probably safe to assume that there are no two SHA1 hashes that share the same first 132bits and are produced by two strings within a reasonable range of length for passwords.
Is this really what's happening or did I miss something ?
Thank you in advance for your replies.
