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.