Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 Jul 2015 00:13:30 +0200
From: magnum <>
Subject: Re: auditing our use of FMT_* flags

On 2015-07-27 20:30, magnum wrote:
> On 2015-07-27 15:57, Kai Zhao wrote:
>>> $ ./john --test=0 --format=dominosec8
>>> Will run 8 OpenMP threads
>>> Testing: dominosec8, Lotus Notes/Domino 8 [8/64]... (8xOMP)
>>> FAILED (cmp_all(1))
>>> I did the same thing to those formats which do not set FMT_8_BIT
>>> and they are ok. Such as, descrypt, bsdicrypt, tripcode
>> Could you help me with the FMT_8_BIT ? Do I understand right ?
>> Thanks very much.
> I'm not sure about this but this problem seems to be similar to FMT_CASE
> (just a self-test-technical issue). So just like for FMT_CASE you should
> try testing with some input file and a wordlist instead.

BTW I don't know much about Domino but it might also be the case that 
the real application simply rejects 8-bit input (even though the 
algorithm would handle it) for mitigating codepage mismatch problems. In 
such a case it might be relevant to not set FMT_CASE.

WPA-PSK is similar. Many implementations (and, I think, the spec) only 
allow ASCII characters 0x20-0x7E, ie. printable ASCII. It would be 
relevant to drop FMT_CASE for that format but I suspect some 
implementations do allow eg. UTF-8 so I have deferred it. Anyway, the 
actual algorithm (PBKDF2-HMAC-SHA1) allow and use 8-bit just fine.


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.