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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.