Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ