Date: Fri, 19 Feb 2021 15:59:31 +0000 From: Misgac04 <Misgac04@...tonmail.com> To: Solar Designer <solar@...nwall.com> Cc: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com> Subject: Re: HMAC-SHA256 Max length / Bug ? Hi, Thanks for detailed answer. I just tried to play with SALT_LIMBS value and I can make john work on the desired length now! But, I realized that I have another issue, which may be due to special char handling. I have multiple colon in my message (it's json after all) and from quick tests it's messing up with john. Consider this. Working john.txt :#fc1ef1f30c98237e736ba5de2300725bc92fed657eedeb67ee77161cbab74b8 Failing (No password hashes loaded) john.txt ::#fc1ef1f30c98237e736ba5de2300725bc92fed657eedeb67ee77161cbab74b8 I'm not aware of special chars restriction or escaping (except hashtag). Would that be a bug ? ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, February 19, 2021 4:21 PM, Solar Designer <solar@...nwall.com> wrote: > Hi, > > On Thu, Feb 18, 2021 at 09:04:59AM +0000, Misgac04 wrote: > > > I'm using john 1.9.0.jumbo1-5, from blackarch. > > I'm having issues at cracking hmac-sha256 key because john skip my hash, I think my message/signature combination seems too long. > > Yes, it is too long. Looking in hmacSHA256_fmt_plug.c, we have this: > > #ifndef SIMD_COEF_32 > #define SALT_LENGTH 1023 > #define SALT_ALIGN 1 > #else > #define SALT_LIMBS 12 /* 1264-9 == 759 bytes / > #define SALT_LENGTH (SALT_LIMBS * PAD_SIZE - 9) > #define SALT_ALIGN MEM_ALIGN_SIMD > #endif > As you can see, for a SIMD-enabled build the maximum salt length is 759 > bytes. I've just confirmed that your sample is loaded when the salt is > shortened to 759, and stops being loaded at 760. > For a SIMD-less build, the limit would apparently be 1023, but it'd run > slower. > I've just tried increasing SIMD_LIMBS like this: > #define SALT_LIMBS 24 / 2464-9 == 1527 bytes */ > > along with changing "#ifndef SIMD_COEF_32" to "#if 1" inside the tests > initializer, to have support for higher salt lengths actually tested. > The format still passes self-tests after a rebuild, and starts loading > your sample hash fine. So you can probably do the same. I only tested > this using the latest code off GitHub, and I suggest you use the latest > too - not a distro package. > > > For instance this works well: > > john.txt > > hello#750f39f4f1bc9dfb785a9a939d324227e910cf33af8bbd4e7a65012d385e508c > > However this is not loaded by john > > john.txt > > FWIW, you got the line wrapped at 190 characters there. With such > wrapping, the last one of the resulting multiple lines is actually > loaded fine, but that's not what you intended. I ran my tests above > with the line unwrapped back to its full length. > > > My practical case is with a message of 3kbytes. > > Oh, then you need an even higher value in SALT_LIMBS, and you need to > create your own test vector to make sure this actually works right. > > Alexander > > P.S. You don't appear to be subscribed to the list, so I am CC'ing you > on this reply. You might want to subscribe so that you don't miss any > other replies people might post, and so that you can reply to those into > this same thread.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.