Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 5 Jul 2015 09:09:55 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: Lyra2 on GPU

On Sun, Jul 05, 2015 at 01:42:41AM +0200, magnum wrote:
> On 2015-07-04 19:37, Solar Designer wrote:
> >On Sat, Jul 04, 2015 at 07:26:01PM +0200, Agnieszka Bielec wrote:
> >>2015-07-04 19:19 GMT+02:00 Solar Designer <solar@...nwall.com>:
> >>>Maybe the auto-tuning could be done only once, only in reset()?
> >>
> >>it's only in reset but first reset is called for correctness tests and
> >>after that is called before real password cracking
> >
> >Oh.  This is wasteful, but it makes sense.
> >
> >Ideally, we'd auto-tune for the actual loaded hashes, yet also run
> >self-test with those settings (even if suboptimal for the self-test).
> >But I think there's no easy way to do that currently.
> 
> Something like this perhaps?
> 
> void reset(struct db_main *db)
> {
> 	static int tuned_already;
> 
> 	if (db || (options.flags & FLG_TEST_SET)) {
> 		/* look at db for costs, then autotune here */
> 		tuned_already = 1;
> 	}
> 	else if (!tuned_already) {
> 		/* set a fixed low LWS & GWS here */
> 	}
> }
> 
> So if we're running --test, we'll auto-tune at first call to reset() and 
> not re-tune at second call.
> 
> If running an actual crack, we'll self-test with some low LWS/GWS (eg. 
> 8/64) and then once we get a db (which we can look at to see costs) 
> we'll auto-tune for actual costs.
> 
> It would be slightly safer to self-test using the actual LWS/GWS that 
> will be used later, but iirc this can't be done without changing core.

Yes, right, but you may make or propose specific changes to make this
possible.

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.