Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

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