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]

Date: Sun, 13 Apr 2014 10:49:11 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Do we need a common password hashing API?

On Sun, Apr 13, 2014 at 9:33 AM, Thomas Pornin <pornin@...et.org> wrote:

> 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.
>

IIRC, EARWORM similarly has a hard-coded password "donotuse" or some such,
for generating the ROM used with the PHS interface.  If I were going to use
EARWORM for an authentication server, or Makwa for hashing delegation, I
doubt I'd want to make that happen through any common API that tries to
support both.  That just sounds like more work to me.

However, most of the entries fit somewhat naturally into the current PHS
interface with just t_cost and m_cost.

Bill

Content of type "text/html" skipped