[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130111091341.GA2682@openwall.com>
Date: Fri, 11 Jan 2013 13:13:41 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: New plugin load order magic
On Fri, Jan 11, 2013 at 09:27:51AM +0100, magnum wrote:
> On 11 Jan, 2013, at 8:58 , Solar Designer <solar@...nwall.com> wrote:
> > On Fri, Jan 11, 2013 at 08:26:40AM +0100, magnum wrote:
> >> I was just considering reverting my patch for now.
> >
> > Yes, I think you should.
>
> I reverted it now but we need to fix this somehow. For the horribly slow iterated formats that are getting common now, we just can't default to CPU formats on a GPU build.
Well, maybe we can have ldr_split_line() skip calling fmt_init() if
source is non-NULL and the format is a GPU one.
> > We may want to eliminate the need to call binary() for --show, but this
> > may have non-trivial consequences (some desirable, some maybe not).
>
> So we would compare the ascii representations after prepare() and split(), instead of the binaries. Could there be different representations of same binary? When?
Upper/lowercase variations of hex encodings is an obvious example, but
we should be taking care of them anyway.
IIRC, the uses of binary representations in --show are primarily to make
use of binary_hash*(), but there are also uses of source representations
and a corresponding hash function anyway.
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.
