[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Nov 2014 20:09:37 +0100
From: Milan Broz <gmazyland@...il.com>
To: discussions@...sword-hashing.net
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
https://github.com/mbroz/PHCtest/blob/master/hash_libs/pufferfish/patches/fix-raw-output.patch
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).
Milan
Powered by blists - more mailing lists