Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <003801cd61f7$aa0f53c0$fe2dfb40$@net>
Date: Sat, 14 Jul 2012 14:34:19 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: additional memory usage questions, and the db_password structures

There are other areas of this which can have significant impacts on memory
usage, for large count of input (i.e. reduce this overhead and improve
scalability of JtR).

 

These 2 are the next_hash pointer, and words pointer.

 

For these 2, the words pointer is only used for single runs. So why not
build a structure that is shorter than the 'original', OR mem_alloc_tiny the
db_password items sizeof (list*) less bytes when running in non-single mode?
If that information even used other than in a single run?

 

As for the other pointer (the next_hash), couldn't that be moved outside of
each object, and simply be an array of db_password pointers??  My
understanding was this is used in salted only, and only when there are
multiple salts, thus keeping the ability to walk the salts.  However, why
does each and every data object require this pointer?  It may simply be a
miss understanding on my part, of just what the next_hash is.

 

However, on a 64 bit system, these 2 pointers are 16 bytes PER candidate of
memory used.  And for a non-salted (or single salt??) run, that is not
single, this memory is fully wasted, I think.

 

Jim.

 

 


Content of type "text/html" skipped

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.