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.