Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 19 Jun 2015 17:33:11 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: continuous feeding (for data driven branching)

Just to document a discussion behind an idea...

When there is a data driven branching we may want to pack intermediate
results into several queues. For example, sunmd5 does it after "coin
flip".

Currently we get a lot of candidates, separate them into 2 packs and,
oops, packs may be sub-optimal: for instance, we got 8 candidates and
based on "coin flip" (or other factor), we got packs with intermediate
results for 3 and 5 candidates while we would like to have 4 and 4 for
our sse code.

Continuous feeding: format reads N candidates, separate them and if it
needs more input to fill up buffers optimally then it asks for them.

Problem 1: format's interface needs changes. Changes can be minimal:
currently crypt_all() can hold back some candidates, use them on next
call and report them as newly generated. The only changes needed: call
crypt_all() in the end with count=0 as a signal for crypt_all() that
it needs to flush all candidates at any cost because john finishes.
(As a modification: call with count=0 only if the last call had count
== MAX_KEYS_PER_CRYPT .)

Such change was proposed by Solar Designer and may be good for
asynchronous calls too (to support FPGAs).

Problem 2: holding candidate (worst case: password) for too long: for
instance, 1 our queue got 1 candidate that is password but we don't
hash it because 1 is not optimal, all other candidates go to other
queue by a coincidence, so format waits for the finish to hash that 1
candidate and user instead of 5 minutes has to wait long
hours/days/months/years. So format has to do something to not hold
candidates more than N minutes.

Problem 3: partial hashing and holding back would give inaccurate
speed reports.

Thanks!

-- 
Regards,
Aleksey Cherepanov

Powered by blists - more mailing lists

Your e-mail address:

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