[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <FEMGd-B7cQyZeU3DcZzGbI5n5rIa4pgeJxdKRJG0oxaUnvoqX_i-oc0gzAHI8EeCtx2vUeKjeS-8mR2Z2F9AKH0aViOBd2qfD445guSfh50=@protonmail.com>
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.
