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: Tue, 24 Mar 2015 07:57:47 +0100
From: Milan Broz <>
Subject: Re: [PHC] Another PHC candidates "mechanical" tests

On 03/24/2015 04:45 AM, Solar Designer wrote:
> 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.

Well, once you reopen this thread...

Actually I already run this test for all 2nd round candidates
but did not have time to polish & publish output yet

(I tried to include all submissions including new Catena versions and Argon2 and
if possible even SSE optimized versions.)

The underlying code is "ready" (
with quilt style patches to show fixes).

There are a lot of engineering issues (endianess, crashes, ...), I will try to send
a list of them to the list today, it need more context comments.


My intention is to test KDF (for usage in cryptsetup FDE) on some real use case
so I will add that testcase output here. It was intended for some workshop paper later
but probably it is better time to publish it here for now.

> 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