[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b86187835a36872379b8f028ba27839f@smtp.hushmail.com>
Date: Fri, 24 Jul 2015 03:51:21 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Bleeding jumbo now defaults to UTF-8
On 2015-07-23 19:24, Marek Wrzosek wrote:
> W dniu 22.07.2015 o 18:23, magnum pisze:
>> Incremental mode was not written with multi-byte charsets like UTF-8 in
>> mind, so will sometimes produce some worthless invalid characters. You
>> can add "-ext:filter_utf8" to filter them out but for fast formats it's
>> better to just ignore them: The filter is much slower than the waste it
>> mitigates.
>>
> So this -inc=utf8 is producing garbage, because incremental mode isn't
> ready to charsets like utf-8. Why is utf8.chr available then?
No-one urged you to use it. Say it produces 0.5% garbage and 0.5% proper
UTF-8 candidates of which one cracks *a single* really cruicial password
of "Administradore", and 99% is more or less same stuff as ascii mode.
Would you consider that useful or would it be shitty?
> What is the format of .chr file? Is it possible to adapt current code of
> incremental mode to generate Unicode characters from plane 0 using
> utf-16 (e.g. using short instead of char)? If yes, then making utf-8
> from them should be simply by encoding using this format (by using bit
> fields or shifting bits - whatever is faster).
There is actually an issue present for porting incremental to either 16
or 32-bit internally. Do not hold your breath, it might never happen.
But I think it would be fairly trivial.
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.
