[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4FF367CD.7050609@rycon.hu>
Date: Tue, 03 Jul 2012 23:44:45 +0200
From: Balázs Bucsay <earthquake@...on.hu>
To: Solar Designer <solar@...nwall.com>
CC: john-dev@...ts.openwall.com
Subject: Re: MySQL 3.23 hash optimizations
Hi there,
Thanks for the link Alexander. I know an other method what is similar to
this, but not the same. This one is a very interesting one too, but I
don't see your solution yet. If I'm right, first I have to generate
tables for every sum with all possible prefixes, and after I have to
test the passwords (generated by the john) prefixed with the
prefixtable's elements.
In this situation, the module have to use a very large (depends on the
sum and the prefix size) slice of memory.
Or maybe I just didn't get the idea in the right way.
Balázs
On 03/07/12 00:19, Solar Designer wrote:
> Hi,
>
> I just found this web page:
>
> http://www.tobtu.com/mysql323code.php
>
> It mentions a reversing optimization and, if I understand correctly,
> testing entire groups of candidate passwords with much fewer explicit
> tests - but this probably won't fit into JtR.
>
> Well, maybe it'd fit if crypt_all() can produce more output indices than
> we had keys set with set_key(). (A formats interface enhancement that
> is planned anyway.) Then get_key() would generate and return the actual
> "virtual keys" (if there's a match on a key that was never tried by the
> high-level code explicitly).
>
> I just thought I'd have this "bookmarked" in here.
>
> Alexander
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.
