[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140622204741.GB31138@openwall.com>
Date: Mon, 23 Jun 2014 00:47:41 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Oracle Bitslice DES
Hi Deepika,
On Sun, Jun 22, 2014 at 01:18:45PM -0700, deepika wrote:
> Regarding grouping of salt+passwords, I cannot figure out the best way out. If I set max_keys_per_crypt to be larger than bitslice length and put same length values in separate buckets, then the buckets may contain less values than the bitslice length.
Sure. You goal is to have them e.g. at least 90% full on average, or
whatever turns out to be optimal in real-world benchmarks on currently
relevant machines and doesn't impact "interactive" use of JtR too much
(not too much work is lost on interrupting/restoring a session, etc.)
> The probability of getting full bucket thus depend on how many max_keys_per_crypt I read. What about reading all the passwords in one go, setting max_keys_per_crypt to be the number of values in password file, and separating them into different buckets? This way I will get maximum probability of fullness of buckets. Of course this will demand more memory. What you say?
Most of the time, we don't actually want to maximize this probability
while disregarding anything else. There are limited-size caches, we
want the status line to reflect current progress, we don't want to lose
too much work when interrupting/restoring.
For example, it took some tuning to arrive at trip_fmt.c's current
compile-time defaults. You'll need to tune yours, too.
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.
