Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 Jan 2014 21:31:43 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Handling of hashes with different iteration counts

On 01/28/2014 01:46 AM, Solar Designer wrote:
> Your array of functions idea could be good, but I think we'll need
> exactly two, so maybe just make it two functions, t_cost() and m_cost().
> Many future password hashing schemes are likely to have more than 2
> tunable parameters (and more than scrypt's 3, too), but for the purpose
> of choosing which hashes to focus attacks on, we may translate those
> many parameters into t_cost and m_cost for _our_ attacks.

I'm not sure anymore whether or not an array of functions is a good idea.
My aim was to avoid the need to touch every format whenever we realize
we need to report one more tunable cost for a specific format.

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.

Advantage of the single function with one more parameter:
less code added to the format definition (just a single line, not
counting the #if FMT_MAIN_VERSION > 11 and #endif).

Disadvantage of the single function with one more parameter:
Formats that want to report at least one cost parameter need to return 1
for every id of tunable cost that is not relevant for the format.
So the format specific functions get a little bit more complex and are
easier to get wrong.

I still think an array of functions is the better approach, but a single
function with an additional parameter would work to.

I don't like adding just two separate cost functions cost_t and cost_m,
because when we do have to add a third cost function for a format, we
need to adjust FMT_MAIN_VERSION and all the format definitions.
That's more than 200 files to change right now, and there will
definitely be more and more formats in the future.

Frank

Powered by blists - more mailing lists

Your e-mail address:

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