[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANJ2NMOXWfC05bFQoF=qMDV-W-xMGBR44YzE7mqwPMxvqrkEwA@mail.gmail.com>
Date: Mon, 4 Jun 2012 00:25:17 +0800
From: myrice <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Password Generation on GPU
Solar, all -
Sorry for postpone for so long. Now let;s start discussing.
On Mon, Apr 30, 2012 at 12:32 PM, Solar Designer <solar@...nwall.com> wrote:
> While in the long run we could want to have JtR's usual cracking modes
> on GPU, I think we could start with the following:
>
> 1. Enhance the formats interface by adding an optional method like:
>
> void set_mask(int count, int *positions, char **charsets)
>
> which would tell the format to substitute all possible characters from
> the supplied charsets in the supplied character positions. For example,
> if called with (1, [5], ["abcdef"]), it would for every key set with
> set_key() additionally substitute every one of the six characters in
> character position number 5 (zero-based). So crypt_all() would produce
> 6 times more password hashes than we had candidate passwords provided
> via set_key(). cmp_all() would operate on all of the actually computed
> hashes. In order for the caller to know how many times to call
> cmp_one(), cmp_exact(), and get_hash*() - when these are needed -
> crypt_all() would be changed to return the number of hashes actually
> computed. (I am considering certain other changes as well, which may
> result in these interfaces being revised some further or differently,
> but I am not including those other changes here to avoid confusion.)
> set_mask() is also good in that it may be closely coupled with the
> format's crypto code when that is helpful. For example, for LM hashes
> the already-transformed key bits matrix may be modified. So
> theoretically it might provide greater speed than what we'd achieve by
> having each thread generate its entirely independent stream of candidate
> passwords.
>
At begin I want to use each threads generates candidate passwords. I
guess with set_mask(), we can reuse current password generation
mode(e.g. incremental, wordlist or single). Here, I have some
questions regarding the set_mask()
1) I think the set_mask() should be implemented on GPU, at least, we
should generate password candidates and directly place them on GPU
memory to avoid data transfer. Otherwise, I do not know benefits of
this - the only we have done is generate more password candidates?
2) With the set_mask() on GPU, we should pass the argument to GPU and
before the crack, we have to generate password candidates first,
right?
3) We still have to call multiple time of set_key() and transfer a
large size of data from CPU to GPU? Though this size may reduce
compare to now implementation
So in my understanding, we have
- Less set_key() call
- Less data size transfer from CPU to GPU
This reduce the CPU execution time.
But we take more time at GPU with
+ Generate password on GPU
The total password candidates number in one crypt_all() call should be
the same. We have to deal with memory on GPU.
I hope more details of this implementation.
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.
