Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Jan 2013 09:27:51 +0100
From: magnum <>
Subject: Re: New plugin load order magic

On 11 Jan, 2013, at 8:58 , Solar Designer <> 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.

>> I tried to follow loader.c but I don't see where it calls init (it does not happen in loader.c).
> ldr_split_line() calls fmt_init().  It is called not only by
> ldr_load_pw_line(), but also by ldr_show_pw_line().  We could have
> ldr_split_line() skip calling fmt_init() if source is not NULL,
> indicating call from ldr_show_pw_line().  However:
>> Also, does the conventions allow calling binary() without calling init()? Not that I know of any format that would have any problems with that.
> This is in fact a problem.  Not only does the convention so far not
> allow that, but some formats may actually require init() to be called
> before binary().  I think some of my DES code may depend on that, in
> some builds.

If DES is the only one maybe it could be changed, or as a temporary work-around we could put in a cludge to call init() for DES only. But I can see the point in having binary() depend on init().

> 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?


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.