[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP41585B5D01E3601D52BD30CFD420@phx.gbl>
Date: Mon, 19 Aug 2013 08:59:30 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: relbench/benchmark-unify (was: Bleeding-jumbo release)
On 08/14/2013 12:02 AM, Frank Dittrich wrote:
> On 08/11/2013 04:53 PM, magnum wrote:
>> All Bleeding-jumbo issues known to me are listed in https://github.com/magnumripper/JohnTheRipper/issues
>
> I don't see the problem I mentioned on john-users a few days ago:
> http://article.gmane.org/gmane.comp.security.openwall.john.user/6720/
>
> benchmark-unify needs some adjustments so that relbench finds more
> matches between current unstable (or latest jumbo release) and current
> bleeding.
I'm just going through the format name changes, comparing --test output
of unstable and bleeding.
If I have a string like "mschapv2-naive, MSCHAPv2 C/R", should I always
drop the "format-label, " part in benchmark-unify, so that I still
detect multiple implementations of the same algorithm, picking the fastest?
But then, this would mean that "descrypt, traditional crypt(3)" would
become "traditional crypt(3)".
And "md5crypt, crypt(3) $1$" would become "crypt(3) $1$".
I'm afraid there are some cases where important information gets lost:
LastPass, sniffed sessions
MongoDB, system / network
PST, custom CRC-32
PuTTY, Private Key
RAdmin, v2.x
The other approach would be to keep all those format labels, and just
drop those few labels where I have different implementations of the same
algorithms, allowing the fastest one to be picked for comparison.
But that would mean even more future benchmark-unify changes if
additional implementations for existing algorithms come up.
What is the preferred way of handling this?
Frank
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.
