Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Sep 2011 16:29:38 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Problem seen in 1.7.8-Jumbo-6-RC3

This has to do with both raw-md5u and md5_gen(29) both calling the init() function on the same data. Even though john makes sure to only call init once on each format structure, the raw-md5u calls the underlying init function in the lower level subformat.   This same structure is the one which john later calls init on.

It looks like I have to add my own init flag in my 'private' data to make sure I do not double init.

What happens in init, is that the plaintext_len is *=3 if we are in utf8 mode. That is the length which john uses. Internally, within the format, it still is only using 27 bytes.

I hope this will be a trivialfix.

I also found a porting problem in some of the new code magnum did in oracle_fmt_plug.c.   It is trivial, moving a var declaration to the top of the function block.  

I will get a patch out soon, that fixes both of these.

Jim.

>-----Original Message-----
>From: magnum [mailto:rawsmooth@...dband.net]
>Sent: Tuesday, September 20, 2011 3:40 PM
>To: john-dev@...ts.openwall.com
>Subject: [john-dev] Problem seen in 1.7.8-Jumbo-6-RC3
>
>$ ../run/john -test=0 -enc=utf8
>(...)
>Benchmarking:  md5_gen(29): md5(unicode($p)) [SSE2 16x4x2 (intr)] in
>UTF-8 mode... FAILED (length)
>
>This is due to format->params.plaintext_length > 125. Doesn't happen
>with thin format.
>
>For some reason it does not happen when running that format only!?
>
>$ ../run/john -test -form=md5_gen\(29\) -enc:utf8
>Benchmarking:  md5_gen(29): md5(unicode($p)) [SSE2 16x4x2 (intr)] in
>UTF-8 mode... DONE
>Raw:	7815K c/s real, 7894K c/s virtual
>
>
>magnum

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.