Date: Thu, 17 Sep 2015 23:26:18 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: "struct db_password" allocation magnum - I just found that someone added a field called "uid" to "struct db_password", but forgot or didn't know to adjust the memory allocation accordingly. So we were over-allocating memory when neither DB_WORDS, nor DB_LOGIN was set. The attached patch corrects that. Unfortunately, currently the only way DB_LOGIN may be reset is via the --save-memory=1 option (or higher). By default, we're allocating space for the login pointers (and setting them to NULL) just in case a further line would actually contain a login name (and not just a bare hash). --save-memory=1 is in fact documented to disable this behavior while having no performance impact. Unfortunately, this changed in jumbo, where it also disables the wordlist memory buffer. I think that's wrong (in core, there's only performance impact for =2 or higher), but I didn't touch it yet. Anyway, running with this patch and with --save-memory=1, and using mmap instead of pre-loading (because of the above limitation), I get the new best speed for the 29M testcase: real 0m41.777s user 2m56.745s sys 0m13.665s Yes, --save-memory=1 not only saves memory, but also improves speed. The only reason not to use it (except for jumbo's limitation above) is wanting to see the login names on cracked passwords. The 29M list contains bare hashes only anyway. Alexander View attachment "john-loader-mem-save.diff" of type "text/plain" (1012 bytes)
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.