[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <657974cf-0dc0-864f-81b5-405c3d327896@cox.net>
Date: Wed, 29 May 2019 18:59:15 -0500
From: jfoug <jfoug.openwall@....net>
To: john-users@...ts.openwall.com
Subject: Re: SSHA256 (32bit hash, 32bit salt)
On 5/29/2019 7:16 AM, Solar Designer wrote:
> Maybe you could also add ability to base64-decode hashes and salts, and
> extract their portions into $s or such accordingly, to dynamic formats
> in general - ideally, also usable via command-line "dynamic scripting".
> Maybe this would eliminate the need for having some thin formats in C,
> instead defining them in a .conf file?
I have been thinking about the 'thin' format, and how that could be
enhanced, to possibly avoid having to acually place new 'code' to do
it. Simply put the thin format is nothing more than a couple of hooking
functions, which allows the dynamic format to expose 'base' dynamic
methods. Then by simple creating a normal function, but only writing a
few 'critical' methods, we can 'ask' the dynamic function to handle all
of the other stuff. Since it would be near impossible to handle
arbitrary input strings in a truely generic manner (if it could be done,
then there would only be 1 format in john anyway), so the ONLY part that
must be done is the part which initially looks at the raw hash, and then
a simple function which will convert from that hash (knowing its
layout), into a format which the rest of the dynamic format can handle.
So it really is a pre-processing/validation and a conversion format,
where the real cracking and checking for cracks is fully done by dynamic.
>
> As I understand, currently dynamic formats are able to base64-encode
> intermediate hashes before further hashing (as it's sometimes a step in
> third-party hashes that we need to support), but it requires that its
> input hashes be in hex and salts in plaintext or hex. This is limiting
> its convenient use, sometimes requiring re-encoding as we see here.
At this point, the only base-64 stuff is in conversion of internal data
into the next block of data to be hashed. So it would allow you to take
the 'raw' password, or buffer result of the first hashing, convert that
to a base-64, AS the input to the next round of hashing. BUT it was not
designed (I think) as a parser for the input. The input is fixed, as
$dynamic_xxx$hash$salt where hash and salt must be base-16. Dyna can
be just a touch more complex than that, but in reality, that is the
expression and only expression which dyna can process.
We 'did' have it handling md5crypt at one time, BUT that was 100%
specialized functions to do the parsing of the input strings. I think
there may be a few other 'unique' inputs, but it is no where near a
generic input parsing tool. I think it could be 'done' better (I KNOW
it can be done better). I really like how some of the description is
done on some of the hash database sites (like hashes.org I think), and
it may be that there could be some extensions added to the dynamic
format, so that you could make the INPUT string also much more generic.
But i have not driven down that road, I do not think it would be trivial
at all.
Jim.
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.
