Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

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