Date: Tue, 5 Jun 2012 02:12:33 +0800 From: myrice <qqlddg@...il.com> To: john-dev@...ts.openwall.com Subject: Re: Password Generation on GPU On Mon, Jun 4, 2012 at 4:11 PM, Solar Designer <solar@...nwall.com> wrote: > myrice - > > On Mon, Jun 04, 2012 at 12:25:17AM +0800, myrice wrote: >> On Mon, Apr 30, 2012 at 12:32 PM, Solar Designer <solar@...nwall.com> wrote: >> > void set_mask(int count, int *positions, char **charsets) > [...] >> At begin I want to use each threads generates candidate passwords. > > What do you mean by this? Multiple threads on CPU, each generating > candidate passwords? No, that's not what we'll have if we're talking > of a GPU-enabled format. The candidate password generation would be on > GPU, and we'd use at most one logical CPU per GPU. > Sorry for unclearness. I mean, for example, we may implement incremental mode on GPU. The password will generate totally on GPU. No password candidate will copy to GPU. With set_mask(), we still have to copy password candidates, which are generated on CPU, to GPU. But you said "So theoretically it might provide greater speed than what we'd achieve by having each thread generate its entirely independent stream of candidate passwords." So does it mean that implement password generation totally on GPU is not effective? Nevertheless, as you point out in other parts, I will happy to implement set_mask() first and it is good to begin with. >> I guess with set_mask(), we can reuse current password generation >> mode(e.g. incremental, wordlist or single). > > Not quite. Initially, only the new mask mode (to be added) would take > advantage of set_mask(). Later, we can add some support for combining > this with other cracking modes (I posted some thoughts on that already, > but it's a relatively distant future right now). > I become more clear of this. So we first create and implement a new mode - mask mode. But only with the mask, we don't have password candidates base for the mask to apply on. So we have to at least coordinate with one exist mode first? Or we may make mask mode more powerful. So we can generate password candidates from the mask(rule?)? > Yes, the candidates will be generated on GPU. In fact, due to > simplicity of this special cracking sub-mode (so to speak), you should > not even need to store them in the GPU card's global memory. You'll be > generating and hashing them right away. And you don't even need to > store them anywhere. If there's a successful guess, get_key() should > be able to reconstruct the candidate password with a given number (this > may be implemented on CPU). This will be great. With this we could have many more password candidates per one crypt_all() call. >> 3) We still have to call multiple time of set_key() > > Maybe, but not necessarily. This depends on cracking mode and its > implementation. For mask mode, we may choose to call set_key() just > once per crypt_all() - having the pre-set mask do everything else. So we could just base on a simple password candidate and enumerate many more with the mask? If so, I could first implement this and this also solve my question with password candidates in mask mode above. >> The total password candidates number in one crypt_all() call should be >> the same. > > Yes, it should be similar to what we'd use now. Not necessarily exactly > the same. Some tuning will be needed. > >> We have to deal with memory on GPU. > > Only to store the computed hashes. Or maybe not even for that purpose, > if we move hash comparisons onto GPU and inside crypt_all() as well, > which is a closely related change. Now I think we could crack many more password candidates per one crypt_all() call. With comparisons on GPU inside crypt_all(), no large GPU memory is needed. So I am clear that, loaded hashes and move cmp_all() to crypt_all() on GPU is the first thing before this. >> I hope more details of this implementation. > > Did I provide sufficient detail above? Any other questions? Yes. These details are really helpful! Thanks! :) myrice
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.