[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150917202618.GA18989@openwall.com>
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.
