Date: Fri, 13 Apr 2012 12:06:14 +0200 From: Samuele Giovanni Tonon <samu@...uxasylum.net> To: john-dev@...ts.openwall.com Subject: Re: fast hashes on GPU On 04/13/2012 10:45 AM, myrice wrote: > Solar, Samuele - > > On Thu, Apr 5, 2012 at 8:44 PM, Solar Designer <solar@...nwall.com > <mailto:solar@...nwall.com>> wrote: > > myrice - > > 5. Try to support longer passwords without a significant slowdown when > the actual passwords being tested happen to be short. Right now, we > have to decrease PLAINTEXT_LENGTH to achieve decent speed for the > single-salt case, but this is a nasty limitation for actual use of such > a build of John (another build needs to be used when testing of longer > passwords is desired). There are ways to keep the data transfers to GPU > smaller most of the time while allowing for longer passwords in the rare > cases when those are present. > > Hi, I am trying this. For trade-off, I think we could first set > INITIAL_PLAINTEXT_LENGTH to 16 and set a flag to indicate short > password(flag=0) or long password(flag=1). > > The we malloc each password length to 16. In set_key function, if we > have a password larger than 16. We reallocate(free-malloc or realloc) > all the password length to 107(The maximum of Mac Lion password length). > > I think it works. A lot of malloc may slow down some speed. I will try > first. Here is still a question, I don't know whether or not we need so > long password?(i.e. 107? or could it be shorter?) > > BTW, On my G9600M GS, the MAX_KEYS_PER_CRYPT is 256*128. The speed is > no difference with PLAINTEXT_LENGTH set to 16 or 107. However, > on GTX580, the MAX_KEYS_PER_CRYPT is 4096*512. There is ~8M c/s slow > down(74M c/s to 66M c/s). yup, this is the other PITA with fast hashes: with slow GPU the time spent on "hashing" is higher than time spent on bus transfer; for this reason changing plaintext_length doesn't affect it too much. Problem arise with newer GPU where "cpu time" is lower than "bandwith time" . If you all have some time try to change plaintext_length on ssha-opencl you will see how it affects the speed; the other hashcat solved the problem, "sorting" password length from shorter to longer; i suspect atom does that so he can create/destroy cl buffers accordingly; however i don't know how this could be achieved in john. Cheers Samuele
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.