Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.