Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABtNtWG=V_OWA223xckfjU9eFhmt8yFrrOz_V0=s9Gpb3_3KMw@mail.gmail.com>
Date: Fri, 21 Aug 2015 01:13:15 +0800
From: Kai Zhao <loverszhao@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: BENCHMARK_LENGTH bugs

Hi Alexander,

On Mon, Aug 17, 2015 at 11:22 PM, Solar Designer <solar@...nwall.com> wrote:
> magnum, Kai -
>
> However, this highlights another robustness task for Kai: identify which
> formats wrongly set BENCHMARK_LENGTH to -1 when they actually need to
> report separate "Many salts" vs. "Only one salt" speeds (that is,
> formats that are fast and salted, yet wrongly have this set to -1).
>
> Also, identify formats that wrongly set BENCHMARK_LENGTH to 0 when they
> don't actually need to report separate "Many salts" vs. "Only one salt"
> speeds (that is, formats that are very slow or/and saltless, so the two
> speeds reported are nearly the same anyway).
>
> For a start, maybe --test-full should warn about formats that have:
>
> (benchmark_length == -1 && salt_size != 0) ||
> (benchmark_length == 0 && salt_size == 0)
>
> The latter combination is strictly an error (can't benchmark for
> different salt counts when there are no salts), so perhaps even the
> non-full --test should complain when it sees it.
>
> The former is sometimes valid: we use it on very slow hashes (and
> non-hashes), where the results would be effectively the same anyway (key
> setup overhead is negligible).  Perhaps we'll need a (growing) whitelist
> of formats for which --test-full should mute this warning.
>
> And we'll need to proceed to correct these settings in formats that
> currently got them wrong.
>

I create a patch for benchmark_length:

https://github.com/loverszhaokai/JohnTheRipper/commit/810a62c938d86a724f5398d312bbb1c5736a1147

This patch detects two errors:

Testing: dominosec8, Lotus Notes/Domino 8 [8/64]... (8xOMP) FAILED
(This format is very slow, but it will report separate "Many salts"
vs. "Only one salt" speeds)
Testing: 7z, 7-Zip (512K iterations) [SHA256 AES 32/64]... (8xOMP)
FAILED (This format is very slow, but it will report separate "Many
salts" vs. "Only one salt" speeds)

$ ../john --test --format=dominosec8

Will run 8 OpenMP threads
Benchmarking: dominosec8, Lotus Notes/Domino 8 [8/64]... (8xOMP) DONE
Warning: "Many salts" test limited: 1/256
Many salts: 3471 c/s real, 435 c/s virtual
Only one salt: 3303 c/s real, 416 c/s virtual

$ ../john --test --format=7z

Will run 8 OpenMP threads
Benchmarking: 7z, 7-Zip (512K iterations) [SHA256 AES 32/64]... (8xOMP) DONE
Speed for cost 1 (iteration count) of 524288
Many salts: 3056 c/s real, 3034 c/s virtual
Only one salt: 18.0 c/s real, 18.1 c/s virtual


I think I should add more slow hashes. The top slow hashes are in the
attached file.


Thanks,

Kai

Download attachment "top_slow_hashes" of type "application/octet-stream" (9777 bytes)

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.