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: Mon, 10 Nov 2014 20:09:37 +0100
From: Milan Broz <>
Subject: Re: [PHC] Another PHC candidates "mechanical" tests

On 11/10/2014 07:15 PM, epixoip wrote:
> On 11/10/2014 12:22 AM, Milan Broz wrote:
>> (and Pufferfish if not fixed to produce raw output)
>> (I run this mainly to find apparent mistakes like that Pufferfish hexa encoding.)
>> The Pufferfish mistake in PHS() implementation (which includes even
> buffer overflow) just
>> underlines that these trivial tests could be useful to find serious
> problems.
> Just for clarification, there is no requirement for PHS() to return raw
> output, and you created the bug & subsequent buffer overflow in PHS()
> with a half-baked patch.

Well, that's why I am tracking all my changes separately. The patch is here

What exactly is half-baked? 

To the overflow: just send small buffer of outlen size and see what strlen() will do in memmove
(without the patch).

> Furthermore, PHS() is merely the wrapper for the sake of this contest.
> The 'official' interface for the reference implemenation is pufferfish().

Shrug... Yes. I can just say that PHS() simply produces non-random output
(because ASCII has high bits set to zero) and crashes because it is not
respecting outlen parameter and move along.

But I think it would be pity to remove nice algorithm from testing just because
of this small mistake... (And the first sentence in my tests says that
I am testing PHS() function only).


Powered by blists - more mailing lists