[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120415005925.GC1296@openwall.com>
Date: Sun, 15 Apr 2012 04:59:25 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hashes on GPU
myrice -
On Fri, Apr 13, 2012 at 04:45:15PM +0800, myrice wrote:
> 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).
Makes sense.
> 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
Would you ever revert to the smaller buffer later, if long passwords are
no longer seen? It'd be a pity to have a long-running cracking
session's speed severely impacted by a single over-long wordlist entry.
Maybe you can keep 2 (or more) buffers allocated and switch between them
as necessary?
> (The maximum of Mac Lion password length).
Actually, I don't know what Lion's maximum password length is. 107 is
the maximum length that does not require us to invoke the SHA-512
compression function more than once (for 108, we'd have to do it).
(That's from my memory from the time when I first wrote XSHA512_fmt.c.
I did not verify this number now.)
Lion's actual maximum password length is probably different - can be
lower or higher than 107. It might even vary by the method used to set
the password (such as GUI vs. CLI).
> 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?)
I think it'd make sense to have more than 2 buffer sizes, but to keep
the largest (rarely used) at length 107. Something like 8, 12, 16, 20,
32, 64, 107.
> 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).
It is puzzling that there's significant difference for the multi-salt
case, as you say. PLAINTEXT_LENGTH should significantly impact the
single-salt case only. Perhaps there's some side-effect of that change?
Alexander
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.
