Date: Tue, 15 Sep 2015 20:33:23 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Judy array On Tue, Sep 15, 2015 at 08:28:18AM -0700, Fred Wang wrote: > This is *a* test. It is "contrived" only so far as I chose a repeatable, fixed set of files. The data was real, however, and is very representative of the types of files I process. I don't know what magnum meant, by I agreed it's "contrived" in the sense that for practical purposes a person wouldn't be cracking those same 2M easy passwords out of the 29M over and over, and they won't care much whether the first time they do it takes them 1 minute or 10 minutes (so they can as well do it without --fork even, if they're on a low RAM machine, and only use --fork once they're past the easiest passwords). However, this test did also reveal other issues, which are also relevant for longer runs. > To load 26M (uncontrived, actual number) of bcrypt hashes into John takes, literally, many hours. Not to crack, just to load. Using my approach on bcrypt, I solved approximately 60,000 bcrypts in the time it took for John to load the file. That's a different matter, albeit a related one in the sense that it's also JtR's old defaults and lack of runtime heuristics. It's probably the SALT_HASH_LOG issue that magnum and Frank mentioned. You might want to try bumping SALT_HASH_LOG up, a lot. > Improving the handling of these common cases will absolutely improve the performance of John, for virtually every hash type. I agree. 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.