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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date: Sun, 11 Aug 2013 11:51:58 -0700
From: "Dennis E. Hamilton" <>
To: <>
Subject: Interdependence of t_cost and m_cost parameters

I'm always having difficulty understanding the interdependence that might exist between t_cost, m_cost and, to a related degree, also outlen.  

Here are some considerations I have.  I don't know how these fit with what others assume the interdependencies might be, or whether the interdependencies are simply left wide open, including when and where step functions arise.

 - Dennis


It is generally easy to have t_cost be directly related to a linear work factor apart from any step functions that may arise in conjunction with outlen.  Alternatively, a PHS could amortize t_cost when there is some outlen-related timing-step increase.  There is such an increase with PBKDF2, for example.  While the t_cost doesn't have to adjust for differences in terms of processor performance, it would be useful to have the effect be smooth, whatever the relationship is.

Amortizing t_cost against m_cost is tricker.  That is, it is difficult to work out the combinations if m_cost also has step-function costs.  It is also not clear what the difference between m_cost 1 and m_cost 2 might be and whether a given implementation has step functions here too (in which case t_cost could be amortized once again).

Note 1: I am also assuming that, whatever the m_cost is, with the other parameters fixed, the result should be cryptographically unrelated to a result produced for any other m_cost value.  The prospect of t_cost, m_cost password-hash collisions with all other parameters the same must be negligible.

Note 2: A requirement that I have for iterative password-hashing procedures is that I can have a version that will operate with a specific time threshhold and then report the t_cost that was achieved along with the resulting hash.  That becomes the known t_cost value for verification.  I've not considered m_cost in practical cases that have come up.  (Given a threshold t in milliseconds, the resulting t_cost
value is one for which the hash is produced in the approximate interval [t, 3t/2].)

Note 3: If I wanted variable m_cost control, I'm thinking that the procedure in (Note 2) would take an m_cost suggestion and that procedure would deliver the t_cost and m_cost values that were used in a generation that satisfied the specified time threshold.  That seems definitely trickier.  Interesting, but trickier.  

-----Original Message-----
From: Jean-Philippe Aumasson [] 
Sent: Monday, February 18, 2013 22:48
Subject: Re: [PHC] Q: Reference t_cost and m_cost parameters

On Mon, Feb 18, 2013 at 10:48 PM, Solar Designer <> 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.

Powered by blists - more mailing lists