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

Powered by blists - more mailing lists