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-next>] [day] [month] [year] [list]
Message-ID: <CAOLP8p7v+fha7uzJuEPTJ_BZCKCU6UZ=NdYXf7=-19TaE_LJNQ@mail.gmail.com>
Date: Thu, 6 Mar 2014 09:06:37 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Scrypt can have highest time*average memory cost

I have been using time*cost as my basic measure of memory-hard KDF
performance, but up to now I've only used peak memory usage rather
than average.  Scrypt writes memory in the first loop, then reads
memory in an unpredictable fashion in the second, while I read and
write at the same time until memory is full.  It turns out that the
Scrypt technique can achieve a higher average time*memory cost for the
entire run, by 50%, even if both ways result in the same peak memory
usage.

Peak memory usage is a very important number, but if an attacker is
using a multi-CPU system with a very large shared memory, then he
probably cares more about average memory than peak.

The advantage of reading and writing at the same time is I can make
each hashed block dependent on two prior blocks, rather than 1, as
with Scrypt.  This helps reduce time-memory trade-off options for an
attacker, which is especially important given that an attacker can
gain a 4X reduction in time*memory cost by using a small fraction of
the memory and doing recomputations as needed.  So, I think that
reading and writing at the same time is preferable.

Can anyone think of a way to fill memory with mostly writes and few
reads in a way that still creates enough data dependencies to fight
off TMTO attacks?  For example, with an unpredictable loop, I might be
able to do small block reads and hash them to create much larger
blocks.  For a cache-timing resistant loop, an attacker could just
keep the memory which is read and discard the rest.

Bill

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ