Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 2 Jul 2012 12:51:34 -0500
From: "jfoug" <>
To: <>
Subject: RE: I think I got it (was: For some dynamic formats on linux-x86-mmx build cracking depends on password candidate sequence)

>May be when the password length is reduced to the length that really
>works, we can also get rid of this (line 1170):
>                if(index==0) {
>                        // we 'have' to use full clean here. NOTE 100%
>sure why, but 10 formats fail if we do not.
>                        DynamicFunc__clean_input_full();

This code is totally gone right now, in bleeding.  I am using clear_keys(), vs using the index==0 'method'.

There are only 2 formats (at this time), where I have to do a clean_full.

As for the lengths, unfortunately, they are there, DUE to other issues, such as UTF8 longer characters.  The entirety of the dynamic format is VERY complex, and often the format has to be written to fully deal with data internally, not to depend upon JtR's features, since at build time, you really DO NOT know what to expect, and any format can do pretty much what it wants.

I will make sure that the key loading 'protects' itself, but that in of itself is NOT good enough.  I will likely have to setup lengths for each type, and for each build.  I have done 'some' of this for the salted formats. It looks like I will have to do it for ALL formats.  This may take some tweaking to get it right, not knowing at build or compile time, if the user is running 'normal' or -utf8, so that also may have to be taken into account.


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.