[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANJ2NMPF_=14Jxom5J8sGwfeGbdaaom08ZtBi7yyN3JNSbz-nw@mail.gmail.com>
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.
