Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Apr 2012 15:19:18 +0800
From: myrice <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Password Generation on GPU

Hi, Samuele, Solar, all -

On Fri, Apr 13, 2012 at 6:06 PM, Samuele Giovanni Tonon <
samu@...uxasylum.net> wrote:
>
> 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.
>

I agree with you bandwidth may cause the problem.  Password generation on
GPU will reduce the transfer time.

For term of "password generation", I just want to make it clear. Do you
mean that in real password generation, the single, wordlist and incremental
mode? I mentioned real because we split benchmark with real password
generation. In benchmark, we just use bench_set_keys(set key from test_fmt
one by one).

For now, I haven't explored so much of these modes. But I am familiar with
ben_set_keys. So if I test it by modifying bench_set_keys, the result is
also meaningful, right?

Thanks!
Dongdong Li

[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

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