[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 29 Dec 2012 19:27:12 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New self-test for maximum length
On 29 Dec, 2012, at 19:01 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> On 12/29/2012 05:53 PM, magnum wrote:
>> I just threw this in with devastating results:
>>
>> commit f49d2c56531de71da2a03c0e28c8bc939cce376b
>> Author: magnum <john.magnum@...hmail.com>
>> Date: Sat Dec 29 17:25:46 2012 +0100
>>
>> formats.c: Add a self-test that puts maximum length candidates in all
>> buffer positions and then read them back to verify. This finds incorrect
>> claims of PLAINTEXT_SIZE as well as most kinds of key buffer over-runs.
>> It found 15 problematic formats right away.
>
> [...]
>
>>
>> I have no idea why I did not get the idea long ago. Unlike the "valid() killer" test that is only active with -DDEBUG, this one doesn't seem prone to segfault so it's always active. This is the current results on my 64-bit machine:
>>
>> $ make -sj8 macosx-x86-64 && ../run/john -t=0 | grep FAIL
> [...]
>> Benchmarking: SAP CODVN B (BCODE) [128/128 SSE2 intrinsics 12x]... FAILED (max. length in index 0: wrote 8, got 0 back)
>
> Did you use a password consisting of spaces?, since SAP ignores trailing
> spaces, this could be somehow expected.
No, I use only uppercase letters in order to not get problems with upper-casing formats and such things. This was actually a false positive: The format postpones setting keyLen[index] until crypt_all(), boosting the "many salts" case. This new self-test never calls crypt_all() so when keys were read back, they got the wrong length. Easy fix (workaround in format).
The problem in raw-md4 is also fixed, it was a real bug: The format read back lengths over 31 incorrectly. Lengths are stored as bits but only LSB was read in get_key(). 32 bytes is 256 bits so it "overflowed".
As said before, we should test all, or most, lengths in the Test Suite (lengths 32, 55, 125, 35, 31, 15, 64 and 27 are most common, in that order). Also, it is a very good idea to include a self-test vector of maximum length in any format, if at all possible. Sadly, my recent experiments with --max-len optimizations for OpenCL dictates that the test vectors are no longer than the minimum length we want to support optimizing for.
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.
