[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <loom.20051222T031107-359@post.gmane.org>
Date: Thu, 22 Dec 2005 02:32:56 +0000 (UTC)
From: Radim Horak <yesbody@...nam.cz>
To: john-users@...ts.openwall.com
Subject: Re: john improvement suggestions - bigcrypt optimization
Solar Designer <solar@...> writes:
> Unfortunately, this is not in line with the way John does things
> currently and with algorithms such as bitslice DES (which assume a fixed
> number of keys per invocation). To overcome this difficulty, John would
> need to maintain two separate sets of buffered keys (doubling the number
> of buffered keys - while L1 data cache size remains constant!) and
> invoke the low-level crypto routines for the appropriate sets of salts
> whenever either buffer fills up.
>
> Does this subtle optimization for the rarely-used bigcrypt justify the
> added complexity and the likely slight reduction in c/s rate? I am
> really not sure. I'd rather spend my time on more obvious improvements.
>
I understand that this universal solution is quite complex, but there could be
much more simpler hack. At startup (or before processing a wordlist rule) john
could analyze:
1) in incremental mode - if definition contains MaxLen <8 then discard all known
8-char-password-hashes from memory, or if actual length <8 then skip them until
change of length.
2) in wordlist mode without rules - this could not be reasonably done, but
3) in wordlist mode with rules - detect if certain rule will generate maximum <8
char length passwords (ie. with "<8" or "'7" rule) - skip the known-length
hashes until next rule. These rules can then be used as a guides with custom
wordlists.
-Radim
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.
