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: Thu, 9 Jan 2014 01:57:22 +0000
From: Peter Maxwell <>
Subject: Re: [PHC] A final cheat killer pass with smoke

On 9 January 2014 01:36, Bill Cox <> wrote:

> That's what the "smoke" is for.  If all an attacker has access to is cache
> miss timing, then simply randomizing the order of of memory access would
> make it virtually impossible to gain information from the timing.

Going on what I understand from (and correct me if I have misunderstood
your definition),

"The final round would first fill an array of addresses that it needs to
access based on data derived from the password, and then the smoke would be
used to shuffle the values in the array.  The cheat killer pass would read
all those locations in the randomized order, adding together the values at
those memory locations."

​you're suggesting that a list of memory indices be created from the
password and that the order of these indices are then randomised.  For
argument's sake, lets just assume the attacker can recover this memory
access pattern in its entirety, they now have a list: a_0, a_1, a_2, ....

If the attacker sorts that list in ascending order, it will be unique up to
the point of collision in the generating function, lets say write the
function as g( password ) so we have the ith iteration of g() creating a_j
for some 0 <= j <= n-1.  An attacker then proceeds by brute forcing that
generating function to create the same ordered sequence a_0 through a_n-1,
which will likely be the password; your "smoke" is irrelevant, what's
relevant here is the computational resources required for each iteration of
that function and an array sort.  Given g() is not in itself memory-hard
and likely to be quite light on resources, does that not bypass your

Content of type "text/html" skipped

Powered by blists - more mailing lists