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, , ["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.