Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 24 Jul 2015 03:51:21 +0200
From: magnum <>
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.


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.