Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <015d01cc9e48$98b53c70$ca1fb550$@net>
Date: Tue, 8 Nov 2011 12:59:51 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: algorithm info wrongly put in format_name

>From: Solar Designer [mailto:solar@...nwall.com]
>
>On Tue, Nov 08, 2011 at 10:18:07AM -0600, jfoug wrote:
>> I believe what you are seeing is the 'BENCHMARK_FORMAT' value.
>
>You mean BENCHMARK_COMMENT, and you're correct.  The Subject is slightly
>wrong then.
> ......
>We could similarly use this when benchmarking phpass hashes - to tell
>the user that the reported speeds pertain to "$P$9" hashes (with the '9'
>rather than some other cost factor).  We could thus use " (x2048)" for
>"$P$9" hashes.

I like this 'usage' for the BENCH comment.  That way, we can have all bench
testing done in the x2048 mode, get a consistent timing, and then when john
is run, and the input file to the format is a bunch of $P$B items, which are
x8096, the 4x slowdown would be expected, and show that the bench timings
were consistent.  Other formats such as crc32, dummy, etc, which have
different behavior based upon things like password len, may have a comment
listing (8 byte pw), or something like that, so that when comparing bench
timings to observed timings, certain expected discrepancies would be shown.

Jim.

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.