[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 May 2013 23:14:40 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Incremental mode in 1.7.9.14
On Mon, May 13, 2013 at 08:42:06PM +0200, magnum wrote:
> On 13 May, 2013, at 20:22 , Solar Designer <solar@...nwall.com> wrote:
> > Change the 1e-3 (in both places) to something larger (e.g., 1e-2).
> > I think the largest value that makes sense is 1.0. So maybe test these:
> >
> > 0.01
> > 0.1
> > 0.5
> > 0.9
> > 1.0
[...]
> Thanks, I will try this. So if I understand the old code & comments, 1.7.9 used 1.0 for this, right?
Not exactly. There's no exact equivalent between 1.7.9's and new code.
It is quite possible that old code was giving these short passwords
higher weight than the new code even with this setting at 1.0.
> Just thinking out loud, how about using some variant of "1/length" instead of a fixed figure? That would benefit really short lengths but not skew the longer ones.
Yes, I also was thinking of making this parameter per-length rather than
a global constant. We already consider the number of combinations for
each order[] entry, though.
Alexander
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux -
Powered by OpenVZ
