[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F87FA96.9060207@linuxasylum.net>
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.
