Date: Mon, 4 Jun 2012 12:11:07 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Password Generation on GPU 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. That said, for CPU-only formats, the set_mask() idea would in fact be usable to generate candidate passwords by multiple threads - right from inside of crypt_all(). > 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). > 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? set_mask() itself is merely a wrapper that sets variables. It may also do some preprocessing if such is needed, but that's all. In fact, it might be called just once, outside of the cracking loop. (Or it might also be called in the cracking loop by another cracking mode.) The actual implementation will be inside crypt_all(), which after a set_mask() will know to generate and hash many more candidate passwords than it had keys set with set_key(). 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). > 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? Not quite. See answer above. set_mask()'s arguments will in fact need to be passed to GPU at some point before or at the crypt_all() call. Then crypt_all() will proceed to generate/hash/forget the candidates. So you don't need to generate any of them "first". > 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 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 Yes. > 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. > I hope more details of this implementation. Did I provide sufficient detail above? Any other questions? Thanks, Alexander
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.