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  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 <>
Subject: Re: [PHC] Do we need a common password hashing API?

On Sun, Apr 13, 2014 at 9:33 AM, Thomas Pornin <> 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.


Content of type "text/html" skipped

Powered by blists - more mailing lists