Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 19 Sep 2015 02:33:21 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hash early exit vs. large hash list

On 18/09/15 17:25, Solar Designer wrote:
> For raw-md5, we currently have early exit before the last 3 steps.
> Aside from this being extremely far from what state of the art fast
> hash crackers do in terms of steps reversal,

Can we reverse any more without considering the actual candidate (or its 
length)? I doubt the shared functions are suitable for hard-core 
reversal. It might be better to do so in formats like the -ng ones that 
doesn't use shared code. Or at least do them first.

> as currently implemented it
> also hurts performance when cracking large hash lists.  Only 32 bits of
> the hash result are preserved and the rest are recomputed with scalar
> code in cmp_exact(), and when the target hash list is large this happens
> quite often.  In the 29M testcase, cmp_exact() is called a few million
> times on wrong passwords (as well as 1.7+ million on correct passwords).

> I think we should support a mode where the SIMD code would exit early,
> but would record the entire state (all four vectors), so that cmp_*()
> wouldn't have to recompute from scratch.  Ideally, we'd only enable this
> mode when the number of loaded hashes is large, although this can be
> tricky in terms of (avoiding) code complexity.

For MD4/5, I was already considering improvements like cmp_one() of 
Alain's NT format (and introduce a shared function for doing those last 
steps). Maybe we should have a separate function for single-round, with 
the few branches that would be needed for that (reversed or not, full 
output state stored or not). This would benefit iterated formats too 
because of less branches.

For SHA-1/SHA-2 though, would we not need a good part of the 80 word 
internal state to be able to continue? Should we store that too? That 
ought to be slower than not reversing at all. In self-contained formats 
like eg. SHA-256-ng we (can) have the whole state available, but with 
the shared code we can't. I hope I'm wrong though?

magnum


Powered by blists - more mailing lists

Your e-mail address:

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