Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 27 May 2012 10:06:39 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: memory usage within JtR and possible ways to significantly reduce it.

I have this change done, and it has been patched into magnum-jumbo, and
bleeding edge (I think bleeding edge).  The code was much easier than I ever
expected.  I am seeing about a 15% improvement in performance of some huge
(31million) dynamic0 hashes.

I only have it implemented for NT and dynamic_0 at this time.  I am believe
there will be some issues I have to address, before I can attempt a salted
hash.

NOTE, every format file WAS modified.  I have also added code into
format_self_test, so that ANY missing format function, will cause the self
test to fail (listing the missing function).

PLEASE people who are working JtR at this time (I know there is a LOT of
fury in the GPU projects), refresh your source you are working on, from the
git repository.   

There were also a few other formats fixed. A couple of things like a memory
overwrite, and some formats that were using opensssl/md5.h and
openssl/sha1.h, vs the md5.h and sha1.h within john. On some builds, this
was causing core dumps for me (probably due to an openssl that does not
match Jtr's impmentation properly.

This patch IS pretty intrusive. It required modification to about 80% of the
source files within JtR.  Almost all of those were very trivial changes,
however. Simply adding a fmt_default_get_source pointer to the end of each
format's structure object.

Jim.

PS, I would like to thank Magnum for taking the time to get this properly
jammed into the git data.

>From: jfoug [mailto:jfoug@....net]
>
>>From: Solar Designer [mailto:solar@...nwall.com]
>>
>>> I ... am
>>> looking at starting on the 'optional' source() method, to eliminate
>>> having to have the hashes allocated (IF a format can recreate the
>>> hash, some may not be able to do that)?
>>
>>Please feel free to experiment with that if you like.
>
>I will start looking at this.  I do think legacy formats should maintain
>existing behavior, and formats themselves would 'tell' JtR, through

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ