jfoug
jfoug
Why would there need to be any core structure format change?? This should all be handled with 1 format, and data driven by the hash string. There would be a...
So there is nothing that would tell us, what we have? hmm. thats pretty ugly for sure.
This is the same optimization I have done for the PBKDF2-HMAC-\* hashes. So any salts >= 64 bytes (or >= 128 bytes for 64 bit hashes), is a candidate for...
I agree, it would be a good for this first limb is the same for all simd entries type hashes.
Because there is no SaltLen value. I should look at this just to make sure. I added SaltLen=-128 and now I see this: ``` $ ../run/john --list=format-all-details -format:dynamic_1588 Format label...
Is the salt len 'always' 64 bytes long? If so, then I could simply change it to `SaltLen=64`
Found another candidate. dynamic_1503. NOTE, I created 2 new flags: MGF_KEYS_BASE16_IN1_SHA1 and MGF_KEYS_BASE16_IN1_SHA256 to handle these formats. b083104 But for 1503, we have reduced 3 limbs to 2 limbs. We...
This new enhancement request is just fine. How about you also post to john-users (linking to this page), so that others can see what is requested.
NOTE, the way jtr loads files, it will almost certainly be best to not have too many of these $HEX[xxxx] words. When they are needed, great, but taking a wordlist...
@magnumripper can you think of other areas where $HEX[] should be dealt with if/when we add this option? If so, then edit the top post, adding a new task.