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, 14 Jul 2015 13:55:40 +0200
From: Jakob Wenzel <>
Subject: Re: [PHC] Overview of PHC Candidates and Garbage-Collector Attacks

Hash: SHA256

On 05.07.2015 21:57, Solar Designer wrote:
> Hi Jakob,
> On Thu, Jul 02, 2015 at 05:05:50PM +0200, Jakob Wenzel wrote:
>> we have updated the classification document (including analysis 
>> regarding to (weak) garbage-collector attacks -- (W)GCA).
>> See:
>> Among other minor changes, the update includes: 1) Argon2d and
>> Argon2i (as two instantiations of the finalist Argon2) 2)
>> yescrypt now provides (W)GCA resistance under certain
>> requirements depending on the input parameter
> It is unclear from your description whether you think yescrypt
> provides GC resistance at t > 0 and/or g > 0, and why.  Can you
> clarify?  You first list t = 0 among requirements for yescrypt's GC
> resistance, and then describe how things change at t > 0 and/or g >
> 0, but you seem to never clearly state whether it's GC attack
> resistant at those settings. (And there's a missing closing brace,
> but this doesn't affect meaning.)

Hi Alexander,

Thanks for the comment! My explaination was indeed not as clear as it
should have been. I updated the yescrypt part by considering the
following cases:

g - cost upgrade parameter (client-independent update increasing time)
V - array in RAM
N - defining the size of the array V (memory cost in RAM)
p - number of threads
r - memory per thread

1) no flags are set and g = 0
scrypt compatibility mode (when used without ROM) => same attacks as
for scrypt applicable.

2) no flags are set and g >= 0
yescrypt is vulnerable to WGC atacks since at least one full
invocation of the time- and memory-consuming core of yescrypt has to
be invoked before the password is overwritten.

3) YESCRYPT_RW is set and g = 0
The second loop of ROMix (Line 6-9) performs less than N writes to V
if t = 0 and if (t = 1 and N >= 8). GC attacks similar to that for
scrypt are applicable but with higher effort since V is at least
partially overwritten. For t > 1, it is most likely that the whole
state V is overwritten, making yescrypt resistant to GC attacks

4) g > 0
yescrypt provides resistance to GC attacks since V is overwritten at
least once (second invocation of first loop (Lines 2-5) of ROMix).

5) YESCRYPT_RW is set, p >= 1, N/p >= 256, N/p * r >= 2^17
Under these requirements, a 64-times smaller instance of yescrypt is
invoked before the full yescrypt. Then, yescrypt overwrites the
password significantly fast, hence, providing WGC resistance.

It would be really cool, if point 5) would also be mentioned in the
specification of yescrypt (and not only the reference code).

> On a related note, the tweaked yescrypt defines client-independent 
> updates, so you may check this in Table 2.


An updated version of the classification is available here:

Best regards,

- -- 
Jakob Wenzel
Research Assistant
Chair of Media Security (Prof. Lucks)
Bauhausstra├če 11 (Room 217)
99423 Weimar
Version: GnuPG v2


Powered by blists - more mailing lists