phc-discussions - Re: [PHC] Different cost settings and optional input

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEw2jfzDh6d61PTMp3U2YqiBvYbuRA=skQGazsJuYJ7SWFS6CQ@mail.gmail.com>
Date: Sat, 16 Feb 2013 12:54:28 +0100
From: Patrick Mylund Nielsen <patrick@...rickmylund.com>
To: Jens Christian Hillerup <jens@...lerup.net>
Cc: Jens Steube <jens.steube@...il.com>, discussions@...sword-hashing.net
Subject: Re: [PHC] Different cost settings and optional input

A non-secret parameter (salt) would presumably solve that problem.


On Sat, Feb 16, 2013 at 12:43 PM, Jens Christian Hillerup <jens@...lerup.net
> wrote:

> On Sat, Feb 16, 2013 at 12:22 PM, Jens Steube <jens.steube@...il.com>
> wrote:
> > Of course, jchillerup is right. I think we should update the CFS to
> > make that clear. In a world full of wrong or partially wrong
> > information troublemaker can simply abuse this lack of clarity to
> > create an Illusion of a weakness in the PHC hash. Such an Illusion can
> > easily cost its credibility.
> >
> >> 09:45:02 gat3way | Is it allowed to rely on a secret parameter other
> than the password then?
> >> 09:45:36 gat3way | otherwise I am afraid such requirement would very
> likely inherently weaken security
> >
> > I am not sure what his concern is about. I think it is the following:
> > We allow the use of a "optional input":
>
> (I'm jchillerup from the previous IRC discussion - hi)
>
> I also had some doubts when I read that. Given two hashes, it'd be
> trivial to determine if they share a preimage; just, in parallel,
> increase the work for both of them by 1 until you see a hash you've
> seen before in the chain (hit), or you've increased-by-one for too
> long (miss).
>
> However, this attack is not that important I'd argue, because if two
> equal passwords *exist* it is likely that that password is in some
> dictionary anyway, or that they originate from the same person. For
> the former case the attacker could perform a dictionary attack on the
> variant that requires lesser work. But hopefully the final PHC
> candidate will require too much work for dictionary attacks, even at
> its lightest setting. For the latter case the attacker would know that
> the two passwords are equal, and not a lot more than that.
>
> JC
>

Content of type "text/html" skipped