Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 30 Jan 2014 10:31:57 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Handling of hashes with different iteration counts

On 2014-01-30 02:33, Frank Dittrich wrote:
> On 01/29/2014 10:10 PM, magnum wrote:
>> On 2014-01-29 21:31, Frank Dittrich wrote:
>>> Defining an array of functions is one way to do it.
>>> Defining a single function with one more parameter (id of tunable cost)
>>> is another one.
>>
>> Another one is a single function that returns [a pointer to] an array of
>> uint: If you don't have any notion of variable cost, the array is {0} or
>> perhaps the pointer is NULL. If you have it, array can be {iter, 0} or
>> {t_cost, m_cost, 0} and so on with virtually no limit.
>
> And then one of the formats decides to return an array of a different
> size than usual, under rare, hard to reproduce circumstances?

What?! How is this a problem with what I suggested?

> No, thanks. I really don't want to think about such situations.
> If a format method is either NULL or returns a single unsigned int
> value, that's easy to handle. The worst case that can happen is I report
> bogus differences if a format is seriously broken.

How is my suggestion different in this regard? I really don't understand 
your concern. It's a null-terminated array, no more crazy and wild than 
a null-terminated string. It's totally flexible - you will support a 
size up to FMT_TUNABLE_COSTS and whenever you bump that figure in 
formats.h, no formats need any change except the very one that called 
for the increase.

magnum


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ