Cracking Scrypt Hashes: Line-length exception errors

[norfSprite]

https://en.wikipedia.org/wiki/Birthday_problem

Give it a brief read and draw your own conclusions regarding hash collision.

Edit: Complementing with some pre-digested math (very informal, btw, I'm no mathematician):

Given a pseudorandom function Hash X P(N) -> H(M) (N length of the password, M length of the hash, M > N), there are 2^N possible passwords and therefore at most 2^N possible hashes (that implies that X(P) is not dense, that is, it doesn't spawn to all 2^M possible values of (M)).

Given two randomly generated hashes x1 and x2 for X unknown, each one has roughly (2^N)/(2^M) of chance of being the hash of an actual password, and then 1/(2^N) that is is the hash of a certain specific password.

Given x1 the hash of your desired password, and x2 a 'randomly generated' valid hash, x2 has about 1/(2^N) chance of being from the same password. If x1 and x2 are equal up to the Zth bit, then there is a 1/(2^(N - Z*N/M)) or (2^(N/M)^Z)/(2^N) chance of them being the same password, which goes up pretty fast with Z.

Include the fact that your acceptable password space is actually a small subset of P(N) (not everyone used randomly generated binary passwords) and then the N on the denominator of that chance becomes smaller than the N on top, increasing your odds.

All this is very inaccurate and mostly 'intuitive' but hopefully you get the idea.

I am under the impression that scrypt isn't hampered by colliding hashes, __under the condition__ that you aren't truncating the output. I get that if I only compared output of say 1 byte millions of inputs would match that output.  However comparing outputs to 2 bytes would significantly reduce the amount of collisions.

That leads me to a concern that there is the possibility that Hashcat could output a false positive. To be clear I have not run in to this ever, but I believe theoretically it could happen with scrypt.

Example situation:
Website validates scrypt digest to length of 128 bytes.
Hashcat validates scrypt digest to length of 24 bytes.
Input hash ->(Hashcat)-> spits out password based on 100% match of first 24 bytes of digest.
Take that password perform same scrypt derivation, get 128 bytes.
Submit 128 bytes to website, website rejects because the 25th or 26th or nth byte is not a match.
Therefore hashcat would, in a practical end user sense, be spitting out a false positive.

In theory you just need to know the first, maybe 8 byte, to check if the password was correct. The salt length is limited, however, but can be of dynamic length if it's not too long.

I interpret that to mean that the first 8 bytes are unique across all inputs so that a match of the first 8 bytes of output could verify the entire hash as a match or not.