[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150513212243.GA21132@openwall.com>
Date: Thu, 14 May 2015 00:22:43 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: get_binary_*() and get_hash_*() methods
On Wed, May 13, 2015 at 09:24:18PM +0300, Aleksey Cherepanov wrote:
> On Wed, May 13, 2015 at 07:53:30PM +0300, Solar Designer wrote:
> > On Wed, May 13, 2015 at 07:37:21PM +0300, Aleksey Cherepanov wrote:
> > > I tried to perform lookup in crypt_all() to exit earlier not finishing
> > > the computations.
> >
> > The same(?) can be achieved by exiting crypt_all() early all the time
> > and completing the computation in cmp_one() when needed. IIRC, myrice's
> > raw SHA-512 on GPU formats did that, completing the computation in
> > cmp_one() on CPU only when needed.
>
> Not exactly the same: I build the check into the algo so I don't need
> global vars to complete computation. Though cmp_one should be called
> so rarely that computation of the whole hash from key should be ok.
You're right.
> > > I tried it against raw-sha512, scalar implementation
> > > with 2 instructions reversed (endianity altering and addition of the
> > > state), I compared h variable (it should be the closest result). Also
> > > I replaced salt->index(index) with var & 0xfff (salt->hash_size == 2).
> >
> > OK, but raw SHA-512 on one core isn't slow enough for this to matter.
>
> "slow enough"? Did you mean "fast enough" as I can get from the text
> below?
Yes, sorry. I meant "isn't fast enough".
> BTW having high MAX_KEYS_PER_CRYPT, it may be interesting to construct
> a small bitmap (or a similar structure) in the end of crypt_all() to
> be used in cmp_all()/cmp_one() to speed up the check.
I guess this would potentially be optimal only when cracking a small
number of hashes, but more than 1. For 1 hash, it's quicker to compare
each computed hash directly than to set a bit in a bitmap. For a large
number of hashes, it's efficient to use a bitmap for those, like we do
now. So it's only the in-between range, with crypt_all()'s *count being
much larger than the number of hashes loaded for cracking, where your
proposed approach makes sense. Yet this may in fact be of some help for
that range. So it's a good idea for that special case.
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.
