[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANJ2NMPxULUS1GDupKcNZhyY6Qht-aOeMmoJVN71_WhK3jL07g@mail.gmail.com>
Date: Wed, 2 Jan 2013 01:29:28 -0800
From: Myrice Li <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Mask mode (was Password Generation on GPU)
Solar,
After a long time break, I will resume my work. :) I am trying to start
with mask mode. The reset() and done() interfaces have something I don't
very understand changes in x86-64.s. Though they may
the corresponding assembly of interfaces change. But in case of I
misunderstand some thing, I will leave them there. After mask mode is done,
I think it is the time merge the bitmaps, set_mask() and mask mode together
and replace the hard coded password generation.
On Tue, Aug 7, 2012 at 11:03 PM, Solar Designer <solar@...nwall.com> wrote:
> myrice -
>
> > From previous discuss, JtR could apply mask on exist keys that passed
> > from set_keys() interface.
>
> Please don't confuse JtR as a whole and the formats interface. Yes, I
> suggested that set_mask(), which is to be added to the formats
> interface, will apply the mask to keys previously set with set_key().
> Both are part of the formats interface. This does not imply that JtR
> as a whole would let the user combine masks with other cracking modes.
> It may, or it may not, independently of how it's implemented in the
> formats interface and whether a given format even provides set_mask().
>
> The standalone mask mode (to be invoked on its own, not in combination
> with any other mode) would have code to generate candidate passwords on
> its own, without reliance on a format's set_mask(). It would also make
> use of set_mask() when available, for some of the character positions
> (like 2). It shouldn't do that for too many because then we'd be
> spending too much time per crypt_all() call, which would make the
> program non-interactive, prevent frequent enough updates of the .rec
> file, and cause "ASIC hangs" on GPUs.
>
> I suggest that initially we only implement this standalone mask mode,
> not supporting combinations with other cracking modes. (In a sense
> this will be inferior to your current hack. That's a pity.)
>
>
After reread this, I think I understand more about what you mean than last
summer. Standalone mask mode is desired anyway from discussion I see. But
it would be the independent mode regardless whether we crack on CPU or GPU.
What I want to do is trying to add mask mode from now on. But I am still
looking at adding options to JtR. I may only spend weekend for this. I will
let you know when I finished the first version.
Thanks,
Myrice
Content of type "text/html" skipped
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.
