Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5197A67D.3010104@mccme.ru>
Date: Sat, 18 May 2013 20:04:13 +0400
From: Alexander Cherepanov <cherepan@...me.ru>
To: john-dev@...ts.openwall.com
Subject: Re: dynamic_1300 selftest FAILED (get_hash[0](1)) in bleeding

On 2013-05-16 03:28, jfoug@....net wrote:
>> BTW are flags MGF_SALTED and MGF_USERNAME really useful? If format uses
>> something like DynamicFunc__append_salt then it's surely salted
>> otherwise it's not. The same with username.
>
> At the time things were written originally, I did not want to loop through the array of function pointers, looking for the certain 'magic' ones that listed something was salted.  Now, I have been doing that on the newer 'large' hash formats.  One reason I did not want to do this, was that additional functions could be added later that would also 'mean' a salt was there.
>
> Not only that, but you have salt, 2nd salt, user name, etc, etc, in any order.  These have to be deal with in the prepare function, and in valid which can both be called PRIOR to init() being called for the format.  They also are needed within other things like salt, binary, source, etc.
>
> There simply are so few 'knowns' when presented with a hash in dynamic. and frequently dynamic may be loading millions of hashes, so we want it to also be fast, that the choice was made to force the hash author to inform upfront if these type of data are present.

Sorry, I was not clear enough. I didn't mean to get rid of MGF_SALTED 
and MGF_USERNAME completely. I thought about eliminating them from 
dynamic.conf. They can be recomputed internally by dinamic while reading 
dynamic.conf.

-- 
Alexander Cherepanov

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.