Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ