[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120215154102.GA2389@openwall.com>
Date: Wed, 15 Feb 2012 19:41:02 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Save memory option save little memory
On Wed, Feb 15, 2012 at 07:02:45AM -0800, Alain Espinosa wrote:
> Hi. I played with the --save-memory option and see a very little memory save:
>
> jumbo version
> john-1.7.9-j5 123MB cracking 1 million NTLM
> john-1.7.9-j5(--save-memory=1) 114MB cracking 1 million NTLM
> john-1.7.9-j5(--save-memory=2) 110MB cracking 1 million NTLM
> john-1.7.9-j5(--save-memory=3) 108MB cracking 1 million NTLM
>
> non-jumbo
> john-1.7.9 64MB cracking 1 million LM
> john-1.7.9(--save-memory=1) 52MB cracking 1 million LM
> john-1.7.9(--save-memory=2) 48.7MB cracking 1 million LM
> john-1.7.9(--save-memory=3) 45.5MB cracking 1 million LM
>
> My system is Windows 7 Ultimate SP1 32 bits, Pentium M CPU, 2GB RAM.
> --save-memory=1 result was expected as the username was very short but
> for option --save-memory=3 i was expecting at least a half use of
> memory.
There's going to be more of a difference with this option in future
versions of JtR:
http://www.openwall.com/lists/john-dev/2012/01/15/7
although that's mostly because memory usage without that option will
increase (for slightly greater speed).
I wonder how you achieve lower memory usage in Hash Suite without a
slowdown. Do you also achieve this for LM hashes or only for NTLM?
The NTLM code in JtR keeps full rather than partial hashes in memory and
it also keeps full original ciphertexts. The former is avoided for LM
(it keeps partial "binary ciphertexts" only), but the latter is not. In
fact, it is impractical to do both at once. But greater memory savings
are possible by not keeping the ASCII strings - only keeping them in
binary form.
Perhaps in Hash Suite you keep the binary values only?
In JtR, it is easier and more reliable to keep the ASCII strings for
writing them into john.pot. Otherwise we'd have to have binary to ASCII
conversion for every format, which with so many formats would be a
considerable amount of code (and bugs). Hash Suite is currently in a
better position to do this sort of thing. ;-)
Well, one thing we can do is _optionally_ have a binary to ASCII
conversion function in formats. Then some formats will be able to save
more memory - such as to better compete with Hash Suite. ;-)
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.
