phc-discussions - Re: [PHC] Do we need a common password hashing API?

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: <20140413133349.GA9877@bolet.org>
Date: Sun, 13 Apr 2014 15:33:49 +0200
From: Thomas Pornin <pornin@...et.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Do we need a common password hashing API?

On Sun, Apr 13, 2014 at 08:42:27AM -0400, Bill Cox wrote:
> There are a few entries that are difficult to fit into the PHS interface.

In the case of Makwa, one should mind the following: though my
implementation provides a PHS() function, for formal compliance with
the submission requirements, that function should be used ONLY for
testing purposes.

The reason is that Makwa uses a big composite integer (the "modulus") as
parameter. That parameter does not fit into the PHS() API, so I
hardcoded a modulus that I generated myself. I did not keep the private
factors, but I cannot prove that; if I had kept a copy of the factors,
then that would grant me an unfair advantage (ability to decrypt the
passwords or at least to run a very efficient brute force attack). Using
that modulus implies trusting me, and you should not.

Apart from that, Makwa accepts some other optional parameters (whether
to do pre-hashing, whether to do post-hashing) that did not fit in PHS()
either.

	--Thomas Pornin