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, 6 Apr 2014 14:44:22 -0400
From: Bill Cox <>
Subject: Re: [PHC] pufferfish

On Sun, Apr 6, 2014 at 11:15 AM, Krisztián Pintér <> wrote:
> Jeremi Gosney (at Sunday, April 6, 2014, 4:09:28 PM):
>>> @@ -132,7 +132,7 @@ int PHS (void *out, size_t outlen, const void *in,
>>> -        memmove (out, hash, strlen (hash));
>>> +        memmove (out, hash, outlen);
>> No, this is incorrect. The `hash' variable in this context is not the
>> raw hash value, it is the encoded hash plus the hash identifier and
>> encoded salt string.
> it might need some clarification then, what the intended use of PHS
> is. as i interpreted it, "out" should be raw bytes of length "outlen".
> that poses the question though, what if a scheme does not even produce
> anything that could be called "raw value" (e.g. it produces two
> numbers in a prime field).
> i would suggest to include a little memo for all candidates, what can
> we expect from the output, is it random, is it a struct, etc. i added
> that to Gambit, but i won't resubmit for this little change, it will
> be there with the next significant update.

I agree.  In the near-term, I need to add some data for each entry
that specifies t_cost and m_cost input limits.  Some of them segv, and
others have ranges which are quite difficult to guess, and return
non-zero if called with illegal input values.  The candidates also
come in different categories, and not all of the mechanical testing
makes sense for all of the candidates.  There are also limits in the
PHS API.  For example, with access to the full set of input
parameters, I suspect I could call Yescript in anti-GPU mode, small
memory in-cache mode, large memory mode for disk encryption, fast
low-memory server authentication with ROM mode, and probably a few
other ways.  With just t_cost and m_cost, I wont be able to benchmark
everything it is capable of.  I'm not sure what to do about that.

I also need to see if there is any automated way to profile memory
usage and bandwidth for an entry over a whole run.  I know valgrind
can give me cache-miss stats, but I'm not sure if it gives us all the
data we would need.  It's not as simple as running the tool and saying
it hashed X amount of memory in Y seconds.

I think it would be cool to let the authors choose what their prefered
benchmark settings are, and to use those to compare them.


Powered by blists - more mailing lists