lists.openwall.net   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  linux-cve-announce  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]
Message-ID: <54608392.8030109@gmail.com>
Date: Mon, 10 Nov 2014 10:21:22 +0100
From: Milan Broz <gmazyland@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Another PHC candidates "mechanical" tests

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!

> (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.

> 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... :)

Thanks,
Milan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ