[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150324034553.GA2302@openwall.com>
Date: Tue, 24 Mar 2015 06:45:53 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Another PHC candidates "mechanical" tests
To add to the proper thread:
On Mon, Nov 10, 2014 at 10:21:22AM +0100, Milan Broz wrote:
> On 11/10/2014 10:04 AM, Solar Designer wrote:
> > On Mon, Nov 10, 2014 at 09:22:23AM +0100, Milan Broz wrote:
> ...
> >> - 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.
>
> Ah, missed this. Thanks for explanation!
This has changed in the tweaked yescrypt (currently listed as v1 on the
PHC website). While 256-bit is still the hash length to use for server
relief (and now also for upgrades), it is no longer special in terms of
(not) bypassing the corresponding post-processing (which is now invoked
for any output length, even when it's not usable for server relief).
> > (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.
>
> Yes. But the "32 bytes special case" is IMHO confusing.
OK, it no longer is a special case in this respect.
> > 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").
>
> Exactly! I think if it is dependent of output length then it should
> be for the whole set. But just my 2 eurocents... :)
Since yescrypt is also able to compute classic scrypt, I opted to make
it behave the same as classic scrypt does.
Thus, yescrypt v1's output for a shorter length is always a prefix of
its output for a longer length. I'd appreciate you re-testing yescrypt
for this property.
This was the other way to avoid the confusion you brought up, different
from what I initially proposed above. Unfortunately, that initial
proposal would result in inconsistent behavior for classic scrypt vs.
native yescrypt modes.
Alexander
Powered by blists - more mailing lists