Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <00fa01cd58a1$219e64e0$64db2ea0$@net>
Date: Mon, 2 Jul 2012 17:22:13 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Updates to the dynamic format (bleeding patch)

Here are the changes:

 

Made a new format bit  (FMT_DYNAMIC)

 

--list=format-all-details lists this flag, as a 'dynamic' format.  Also if a
dynamic format, --list=format-all-details gets the proper salt size from the
format.  The dynamic formats will always have a salt_size of 0 or the size
of a pointer in the fmt_main structure. They handle their own salt
processing, since it is variable. Also the format handles all duplicate salt
stuff, by keeping a list of all pointers, and if a dupe is found, the
original pointer is returned again.

 

Dyna_7 has been fully deprecated (commented out, with comments in the source
as to why).  Dyna_6 is the format to use.

 

The length of pw inputs, and salts have been audited.

 

Bug fixed in the parser (a calloc should have been used, vs an alloc).

 

2 new parser keywords added:  SaltLenX86= and MaxInputLenX86=   These are
fully optional, and rarely needed.

 

The length of data for SSE types is 55, and the length for data for non-see
builds is 80.  The length of salt/pw (and an optional saltx86/pwx86) now
sets these values up. This can be done automatically, by simply setting the
salt length.  It can also be overrode by the format builder.  A format like
md5($s.md5($p)) will have to have the salt limited to at most 23 bytes (for
SSE), due to 32 bytes from the hash.  However, in this case, there is no
reason to limit the length of the PW to 32. It can be set to 55, even though
55-23 is 32.  If for this format, the salt (ITW) was 32 bytes, then this
format would need to be re-engineered, and must not use SSE for the outer
md5().  

 

I know Frank raised issues with the length's, but the complexities are NOT
easy to work around.  Also, there is, and will never be, any length
validation checking within the inner workings of the format. The format
author must know the layout of memory. There really is no other way around
it, UNLESS they want to simply make the format Not-SSE-Safe.

 

Added a function in dynamic to return the 'real' salt length (since this was
not exposed  globally).

 

Jim.

 

 


Content of type "text/html" skipped

Download attachment "JtR-dynamic-length-fixing-1.diff" of type "application/octet-stream" (24050 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.