john-dev - Re: Long Password Length Status

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 21 May 2012 22:34:21 +0800
From: myrice <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Long Password Length Status

Hi, all

Here are long password support status.

I used two array to store password. One is short length with length
currently set to 16. The other is the extend array with (125-16). In
one crypt_all() invoking, if there is a long password, the two arrays
are needed to transfer to GPU. Otherwise, if no password length larger
than 16, I only transfer the array with short length.

Here are the result
All password candidates are short:
Benchmarking: Mac OS X 10.7+ salted SHA-512 [CUDA]... DONE
Many salts:     65925K c/s real, 66584K c/s virtual
Only one salt:  30247K c/s real, 30247K c/s virtual

Some of the password candidates:
1/4 number of long password:
Benchmarking: Mac OS X 10.7+ salted SHA-512 [CUDA]... DONE
Many salts:     61086K c/s real, 61086K c/s virtual
Only one salt:  26214K c/s real, 26214K c/s virtual

When the long password candidates is 1/2 ( 2 short + 2 long in fmt_test),
Benchmarking: Mac OS X 10.7+ salted SHA-512 [CUDA]... DONE
Many salts:     60531K c/s real, 59986K c/s virtual
Only one salt:  26214K c/s real, 17476K c/s virtual

I find virtual is a lot slow in this case. And the real actually may
jump to 17M c/s sometime.

And all are long password candidates: ( 2 long in fmt_test )
Benchmarking: Mac OS X 10.7+ salted SHA-512 [CUDA]... DONE
Many salts:     60531K c/s real, 61086K c/s virtual
Only one salt:  13107K c/s real, 13107K c/s virtual

Thanks!
Myrice

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.