[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANJ2NMMFvxyr7sREwWt-6fbDrsJSPQwctGoFxX4T9XxTErq=ww@mail.gmail.com>
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.
