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