Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 31 Dec 2012 05:07:21 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: clear_keys(self)

On 31 Dec, 2012, at 4:27 , Solar Designer <solar@...nwall.com> wrote:
> On Sun, Dec 30, 2012 at 05:16:50AM +0100, magnum wrote:
>> I think we might want to add a "struct fmt_main *self" parameter to clear_keys() for access to self->params.max_keys_per_crypt and other things. Maybe this has alrady been discussed?
> No, but the convention has been to only pass the self pointer to
> functions that may be called before init(), and to init() itself.  The
> rest may use a global variable (declared static in the fmt file), which
> is either the only format struct or a pointer set by init().  I see
> little reason to single out clear_keys().  So I oppose this change.
> 
> What formats would use this?  Is this e.g. for sharing of clear_keys()
> implementation between several formats (which)?

OK, I was just confused. Yes, I was thinking about formats like TC or DragonFly that are several formats in one file. I got the idea it gets tricky without a self pointer but I can't remember the train of thoughts... I probably had this in mind:

	struct fmt_main some_format;
	void clear_keys(void)
	{
		memset(buffer, 0, some_format.params.plaintext_length *
		       some_format.params.max_keys_per_crypt);
	}

This would not work for multi-format files but like you say I could use a format-global variable if I get in that situation.

magnum

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.