phc-discussions - Re: [PHC] Q: Reference t_cost and m

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGiyFdeuvnn9nUG7F++SbAa2B9mpU60izPjOzYT03a_u77mpgA@mail.gmail.com>
Date: Tue, 19 Feb 2013 07:48:04 +0100
From: Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Q: Reference t_cost and m_cost parameters

On Mon, Feb 18, 2013 at 10:48 PM, Solar Designer <solar@...nwall.com> wrote:
> On Mon, Feb 18, 2013 at 11:23:16AM -0800, Dennis E. Hamilton wrote:
>> For the candidate reference-implementation API, the t_cost and m_cost
>> parameters are apparently unitless values related to time cost and space
>> (memory cost).
>>
>> Is there some standard definition for these, so that one can substitute
>> implementations but not need to know the implementation to know the
>> consequences?
>>
>> Or is it presumed that a candidate specify how these are interpreted
>
> I think it's the latter.
>

It is: for example m_cost=2 does not mean "2 megabytes", t_cost=100
does not (and cannot) mean "100 cpu cycles", etc.

t_cost and m_cost may (and will probably) accept different ranges of
values for different submissions. We did not want to impose a specific
range, as it would have restricted designers (although any countable
range can be mapped to [0;1], though with limited precision).

>
>> By fixed I mean that the salt and the cost parameters would be either stored
>> or otherwise preserved between creation of a hash and recomputation of the
>> hash for authentication of a password.
>
> Oh, that's a different aspect from what you wrote in the previous few
> paragraphs.  Yes, it is expected that the parameter values, except for
> secrets, will be stored along with the hashes or with the encrypted
> data (if the scheme is used as a KDF).  This is beyond scope of PHC,
> although we may discuss it in here.
>

That's also my understanding.