Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 May 2013 22:32:06 +0200
From: magnum <>
Subject: Re: Incremental mode in

On 15 May, 2013, at 22:17 , Solar Designer <> wrote:
> On Wed, May 15, 2013 at 08:05:17PM +0200, magnum wrote:
>> On 14 May, 2013, at 11:09 , Solar Designer <> wrote:
>>>> Despite 1.7.9 (unstable) running 25% slower, it does crack more hashes here. This is with exact same training as bleeding.
>>> This is unexpected and troubling - we don't want to be making things
>>> worse than what we had before.
>> Unfortunately further tests seem to show the same.
> This is weird.  It is inconsistent with previous test results,
> including yours:
> How do you explain that?

I'm aware of that, it bugs me too. I was likely even using the same test set! I need to check out that older version and compare.

But the post states I used 0x7e and 15 (and likely a min of 0x20)... is it possible we lose precision somehow with the larger figures?

> Did I break something in the new incremental mode, reducing its
> efficiency, after that test?  Or was the test or interpretation of its
> results somehow wrong?
> Can you test with more datasets, not just those same 70k hashes?

I did use a totally different DES set now too (g4wker), with even worse results compared to older. That's in the odf.

> Can you add last summer's contest edition to the mix?

This crossed my mind too. I will. I think I'll start with reverting to April 26. Or maybe first re-train using current code at 0x20 0x7e and 15?


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.