[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <352073c7d9b69b98c4389f1264e06933@smtp.hushmail.com>
Date: Tue, 03 Jul 2012 00:47:15 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Updates to the dynamic format (bleeding patch)
Committed. I'm starting to wonder if/when we should move this over to
magnum-jumbo. It depends on how long core will stay 1.7.9.
magnum
On 2012-07-03 00:22, jfoug wrote:
> 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.
>
>
>
>
>
>
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.
