Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Apr 2012 16:45:15 +0800
From: myrice <>
Subject: Re: fast hashes on GPU

Solar, Samuele -

On Thu, Apr 5, 2012 at 8:44 PM, Solar Designer <> 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.