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]

Date: Wed, 8 Jan 2014 21:29:13 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] A final cheat killer pass with smoke

I am assuming the attacker cannot determine the addresses accessed, but
only that a cache miss occured.  I'm pretty new to this stuff.  Is there a
cache timing attack that reveals the actual addresses?


On Wed, Jan 8, 2014 at 8:57 PM, Peter Maxwell <peter@...icient.co.uk> wrote:

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