Date: Fri, 13 Apr 2012 16:45:15 +0800 From: myrice <qqlddg@...il.com> To: john-dev@...ts.openwall.com Subject: Re: fast hashes on GPU Solar, Samuele - On Thu, Apr 5, 2012 at 8:44 PM, Solar Designer <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). Content of type "text/html" skipped
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.