Date: Tue, 03 Jun 2014 10:37:59 +0200 From: Frank Dittrich <frank.dittrich@...lbox.org> To: john-dev@...ts.openwall.com Subject: Hashes with different tunable costs (was: Re: Handling of hashes with different iteration counts) Alexander, On 04/11/2014 10:26 AM, Solar Designer wrote: > On Fri, Apr 11, 2014 at 12:02:24AM +0200, Frank Dittrich wrote: >> If p is 1, then N*r = m_cost = N*r*p = t_cost. This doesn't seem to be >> very useful. > > Yet it makes sense. > >> For now (not committed yet, and thus no pull request), I decided to >> report N*p as t_cost and r*p as m_cost. >> (As long as p == 1, just N and r are reported; p > 1 influences both >> t_cost and m_cost. Does that make sense?) > > No, this makes no sense to me. > > With scrypt, the only way to tune t_cost without affecting m_cost is via p. > That's the reality. What you're doing is reusing my suggested t_cost > and m_cost names to mean something totally different. That's confusing. > Please don't do that! I decided to report three tunable cost values for django-scrypt: N, r, and p. (I increased FMT_TUNABLE_COSTS to 3.) I would have preferred to report values that correspond to memory or time usage. But if that's not trivial, I'd rather report the real value of each tunable cost parameter here. 1 0:00:00:00 Cost 1 (N) is 14 for all loaded hashes 1 0:00:00:00 Cost 2 (r) is 8 for all loaded hashes 1 0:00:00:00 Cost 3 (p) is 1 for all loaded hashes The above lines are from the log file. If a particular tunable cost has the same value for all remaining hashes, I'll report them in the log file. This is another change, in a separate commit. If the hashes have different cost values, they are reported both on stdout and in the log file, but identical values are just reported in the log file. I thought logging this information might help explaining why the c/s value is much lower than what you might expect from a john --test run: $ ./john --test --format=bcrypt Will run 8 OpenMP threads Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/64 X3]... (8xOMP) DONE Raw: 3384 c/s real, 423 c/s virtual $ ./john bcrypt Loaded 14 password hashes with 7 different salts (bcrypt [Blowfish 32/64 X3]) Will run 8 OpenMP threads Press 'q' or Ctrl-C to abort, almost any other key for status 0g 0:00:00:09 0.32% 2/3 (ETA: 23:45:49) 0g/s 56.00p/s 400.0c/s 816.0C/s conrad..keith 0g 0:00:00:18 0.57% 2/3 (ETA: 23:52:12) 0g/s 53.33p/s 384.7c/s 784.7C/s picasso..steven1 0g 0:00:00:30 2/3 0g/s 51.14p/s 371.9c/s 746.2C/s manson..oreo Session aborted 0:00:00:00 Loaded a total of 14 password hashes with 7 different salts 0:00:00:00 Sorting salts, for performance 0:00:00:00 Cost 1 (iteration count) is 256 for all loaded hashes 0:00:00:00 - Hash type: bcrypt (lengths up to 72) Both changes are now pulled into bleeding-jumbo. > BTW, in yescrypt, I've introduced t - a way to tune t_cost without > affecting either m_cost or p. So with yescrypt you'd have: > > m_cost = N * r > t_cost = N * r * f(t) * ((flags & YESCRYPT_PARALLEL_SMIX) ? 1 : p) That means, for yescrypt I'll need to increase FMT_TUNABLE_COSTS to 5 and report N, r, t or f(t), flags, p? > whereas with classic scrypt it is: > > m_cost = N * r > t_cost = N * r * p [...] > I understand we might want to group hashes not only by their full m_cost > and t_cost, but also e.g. by N and r individually, as the differences in > memory access pattern may turn into speed differences (this is why these > settings are separately tunable, after all). However, this simply does > not fit into the m_cost and t_cost model. If you want to include such > support, you need to include it explicitly: as ability to group hashes > by individual hash type specific parameters. For yescrypt, you would > then also need to support grouping separately by p, t, and flags. Do we > really want to introduce that support proactively? The only changes required if a new format needs to report more than 3 tunable costs are: -Adjust the FMT_TUNABLE_COSTS definition in formats.h -add more than 3 trivial functions (returning an unsigned int value calculated from a particular salt) to this format -(optionally) list more than 3 names/descriptions for the tunable costs of this format, No other format needs to change. A minor adjustment for --list=format-methods is required if a user wants to use ./john --list=format-methods:tunable_cost_value to see all formats which report at least 4 tunable costs. Currently, only these are valid "method names": ./john --list=format-methods:tunable_cost_value ./john --list=format-methods:tunable_cost_value ./john --list=format-methods:tunable_cost_value ./john --list=format-methods:tunable_cost_value (bleeding-jumbo)src $ git grep -n FMT_TUNABLE_COSTS ... listconf.c:562:#if FMT_TUNABLE_COSTS > 1 listconf.c:564:#if FMT_TUNABLE_COSTS > 2 ... Frank
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.