+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: Cracking Scrypt Hashes: Line-length exception errors (/thread-5828.html)
Cracking Scrypt Hashes: Line-length exception errors - norfSprite - 09-02-2016
I can't get Hashcat to attempt to crack a scrypt hash that has a b64 encoded digest that is not of length 44.
With four test hashes only the following hash does not complain of a line-length exception:
SCRYPT:16384:8:1:AAAi6VM8REKgZxUi4t==:XXXXQUxxxxFBxxxxQXXXXUxxxxFBxXxxQUxxXXFBQUEK
The following hashes as shown below all cause Line-length exceptions.
hashcat (v3.10) starting...
WARNING: Hashfile 'scryptExampleHash.hash' on line 1 (SCRYPT:16384:8:1:AAAT3xpfSyKgS3hzD1V0Yg==:axxxxee2/GgXd5ihAlWifFtwxxxSYuPyYaI4axxx6rlHwxxxyxxxHtQMSmaZqhyxxxmp11ci4jRhvmxxwJf6kw==): Line-length exception
WARNING: Hashfile 'scryptExampleHash.hash' on line 2 (SCRYPT:16384:8:1:AAAi6VM8REKgZxUi4t==:QxxxQxxxQxxxxxxBxxxBxxxBxxxBxxxBQxxxQxxx): Line-length exception
WARNING: Hashfile 'scryptExampleHash.hash' on line 4 (SCRYPT:16384:8:1:AAAi6VM8REKgZxUi4t==:xxxBxxxBQxxxQxxxQxxxQxxxxxxxQxxxQxxxQxxxQUFBCg==): Line-length exception
Does hashcat support variable length digests for scrypt?
RE: Cracking Scrypt Hashes: Line-length exception errors - atom - 09-03-2016
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.
RE: Cracking Scrypt Hashes: Line-length exception errors - norfSprite - 09-05-2016
(09-03-2016, 11:22 AM)atom Wrote: 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.
Interesting I did not know that, that seems like a critical flaw.
Is there documentation about this that you could point me to?
Edit: testing shows that the password is recoverable with only 32 bytes (b64 format), the other 12 can be any valid b64 character.
The hash displayed when cracked has the last two characters changed, why is this?
SCRYPT:16384:8:1:d29ybGQ=:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkfesTIiWK
SCRYPT:16384:8:1:d29ybGQ=:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkfesTIiU=:hashhashhashhashhashhashhash
Session.Name...: hashcat
Status.........: Cracked
Input.Mode.....: File (scryptTests/s.dict)
Hash.Target....: SCRYPT:16384:8:1:d29ybGQ=:kV5oiUfzPhEra/O...
Hash.Type......: scrypt
RE: Cracking Scrypt Hashes: Line-length exception errors - atom - 09-08-2016
Documentation is here: https://hashcat.net/wiki/doku.php?id=frequently_asked_questions#what_is_the_maximum_supported_salt_length
RE: Cracking Scrypt Hashes: Line-length exception errors - norfSprite - 09-08-2016
(09-03-2016, 11:22 AM)atom Wrote: 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.
Apologies if it wasn't clear in my last post, but the documentation I am hoping you could point me too is the document that explained how it is possible that you only need the first 8 or so bytes to verify a password match.
RE: Cracking Scrypt Hashes: Line-length exception errors - henpemaz - 09-08-2016
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.
RE: Cracking Scrypt Hashes: Line-length exception errors - norfSprite - 09-09-2016
(09-08-2016, 09:24 PM)henpemaz Wrote: 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.
atom Wrote: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.
RE: Cracking Scrypt Hashes: Line-length exception errors - atom - 09-10-2016
Don't make it too theoretic. From a practical perspective, with scrypt, you wouldn't find any two hashes that share the same first 8 byte with different inputs, simply because it's so slow.