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.