Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 06 Mar 2011 22:47:17 +0100
From: magnum <rawsmooth@...dband.net>
To: john-dev@...ts.openwall.com
Subject: Re: Re: md5_gen, proposed functionality

On 03/06/2011 05:23 PM, JimF wrote:
> ----- Original Message ----- From: "magnum" <rawsmooth@...dband.net>
>>> Func=MD5GenBaseFunc__setmode_ascii_to_unicode
>>> Func=MD5 GenBaseFunc__setmode_normal
>>
>> That makes sense and I think it would cover all situations.
>
> What modes should be handled?

I think there should be just one unicode mode, but that mode should 
behave differently if the (suggested) --utf8 "global" option was given 
to John. Otherwise you would have to create different formats just for 
differently formatted wordlists. I think it should just be called 
"setmode_unicode" as it's converting either from ISO-8859-1 or from 
UTF-8, both are supersets of ascii.

So when using setmode_unicode and no --utf8 option was given, we insert 
null bytes. If the --utf8 mode was given, we perform utf8 conversion.

I see no current need for other modes, did you have anything special in 
mind? Theoretically we could have all sorts of conversions like 
setmode_cp863_to_unicode but there is no need, as utf8 is a superset of 
all codepages. You would convert the cp863 wordlist to utf-8, then run 
john with --utf8).

And on the other hand, if the hashes was created from cp863 plaintext, 
we would just use normal mode and feed John with a cp863 formatted wordlist.

> Should there be any way to setup different 'mode_normal'? For that, if
> we need it, it would have to be done with Flags= items, and likely would
> also require changes to john proper.

I can't think of any special cases. Mode_normal would just turn unicode 
conversion off for the following steps, right?


I'm currently experimenting with a global --utf8 flag and optional UTF-8 
support for the NT format. When I come up with something usable, I'll 
make an "evaluation release" of it.

BTW now I suddenly realised why you objected to having it done in 
set_key()... I have only done that to unsalted formats. It would be a 
death blow for a salted format, right? At least doing UTF8->UTF16 
conversion.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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