Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 29 May 2019 18:59:15 -0500
From: jfoug <>
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 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.


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.