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: <53F7B39A.2020501@larc.usp.br>
Date: Fri, 22 Aug 2014 18:18:18 -0300
From: Marcos Simplicio <mjunior@...c.usp.br>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] What Microsoft Would like from the PHC - Passwords14 presentation

Hi.

Reading the last posts, I was wandering: do the table consider in some
of its metrics what we call a "Slow memory attack" (i.e., when the
attacker stores the required memory pieces in a cheap device such as a
hard disk and then prefetches those pieces when and only when he/she
knows those pieces are needed, avoiding the corresponding latency
penalties) in Lyra2's documentation?

I ask because this seems to be a concern taken into account since the
design of scrypt, or at least this is my impression when there is such
an emphasis on an attacker's need of using RAM. However, I believe that
it conflicts with a cache-timing-resistant design. After all, a scenario
where no memory access depends on the password is just perfect for
prefetching and, thus, for latency avoidance (although bandwidth is
likely to become a serious issue then).

I honestly am not sure whether preventing attackers from building
"latency-free" implementations is more important than preventing them
from exploiting cache timing, but I do not see how any scheme could have
a "Yes" for both criteria.

Or maybe I'm just trying to compensate Lyra2's "maybe" in cache-timing
resistance :)

BR,

Marcos Simplicio.


On 22-Aug-14 17:41, Greg Zaverucha wrote:
> For side-channel resistance, "maybe" means either: "maybe side-channel resistant, more analysis required", or it's a hybrid design where side-channel information about the state is only available after some (quantified) amount of work has happened.   Lyra2 is an example candidate designed to provide this type of defense (see [1], page 31, last paragraph).  I think this is worth considering since there are some assurances on how hard it is to exploit the side-channel.
> 
> In terms of the inconsistency,  yes "Agility" shows as a criteria in the table, and in the talk we did not take a position on whether this should be a requirement (as there are good arguments for and against).  It's interesting to note that if you drop the Agility column, the candidates listed on slide 36 are the same. 
> 
> Greg
> 
> [1] https://password-hashing.net/submissions/specs/Lyra2-v1.pdf
> 
> -----Original Message-----
> From: Krisztián Pintér [mailto:pinterkr@...il.com] 
> Sent: Friday, August 22, 2014 12:46 AM
> To: discussions@...sword-hashing.net
> Subject: Re: [PHC] What Microsoft Would like from the PHC - Passwords14 presentation
> 
> On Fri, Aug 22, 2014 at 12:58 AM, Bill Cox <waywardgeek@...il.com> wrote:
> 
>> It obviously has the same cache timing resistance characteristics as the other hybrid designs, which are labelled with "maybe" rather than "no".
> 
> 
> there is no such thing as sorta cache timing resistant. it either is or isn't. if it isn't, we can talk about how hard to exploit.
> 
> the talk is not exactly consistent with itself in some regards. the table at the end is very strict. but the earlier slides are much more tolerant. i suspect the table was made early, and the slides were modified later, but March will correct me on this one. the same thing can be said about primitive replaceability. it is unsure in the exposition, but counted in the table.
> 
> anyway, i think the table is fine, because gambit is in the 4 good ones, so i agree :)
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ