Please note, this is a STATIC archive of website hashcat.net from 08 Oct 2020, cach3.com does not collect or store any user information, there is no "phishing" involved.
hashcat Forum
Does Hashcat only compare the beginning of hashes ? - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Developer (https://hashcat.net/forum/forum-39.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-40.html)
+--- Thread: Does Hashcat only compare the beginning of hashes ? (/thread-8979.html)



Does Hashcat only compare the beginning of hashes ? - tachsah - 02-18-2020

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.


RE: Does Hashcat only compare the beginning of hashes ? - Chick3nman - 02-19-2020

You are correct, in most cases I believe we only compare the first ~128bits or so since the likelyhood of a collision at that length is low enough that we don't consider it a problem. If someone were to find a collision for that length on a longer hash, we could add a post processing step to go through more of the hash, but to my knowledge that hasn't happened yet.