phc-discussions - Re: [PHC] A final cheat killer pass with smoke

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+aY-u7JKDHmcd798XFDcNSj7RU458Mf_yoj6NrqxtyHdJD=Xw@mail.gmail.com>
Date: Thu, 9 Jan 2014 01:57:22 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] A final cheat killer pass with smoke

On 9 January 2014 01:36, Bill Cox <waywardgeek@...il.com> 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, ....
a_n-1.

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
memory-hardness?

Content of type "text/html" skipped