[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141110090410.GA6640@openwall.com>
Date: Mon, 10 Nov 2014 12:04:10 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Another PHC candidates "mechanical" tests
On Mon, Nov 10, 2014 at 09:22:23AM +0100, Milan Broz wrote:
> I run some simple tests with almost all PHC candidates
> (plus Catena2 and RIG2 submitted here).
This is a helpful contribution. Thank you!
> - Yescrypt seems to produce different hash for 32bytes length than for other requested lengths
> if it is intended
Yes, and yes. 256-bit (32 bytes) is a special case usable for
yescrypt's builtin support for "server relief". For other output
lengths, that functionality is not applicable, so the corresponding
post-processing is bypassed. For uses of yescrypt that don't care about
"server relief" (which most of them won't), this should not matter.
(yescrypt-lite will probably only support 32 byte output, so will invoke
those code paths unconditionally.)
> (and not my mistake) then probably PHS() should fail for other req. output
Why? The PHC call for submissions doesn't say anywhere that PHS()
output for a shorter length should be a prefix of its output for a
longer length. In other words, the requested output length might or
might not affect any/all output bits.
In fact, now that you bring this up, I think a slight improvement might
be to always have the requested output length affect all of the output
bits, even if just to avoid any confusion of this sort ("hey, there's a
special case here").
To summarize, I think yescrypt's behavior is allowable per PHC terms,
for all output lengths that it agrees to produce. Not just for 32.
Alexander
Powered by blists - more mailing lists