phc-discussions - Re: [PHC] Why protect against side channel attacks

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: Thu, 25 Jun 2015 01:40:46 +0100
From: Peter Maxwell <peter@...icient.co.uk>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Why protect against side channel attacks

On 25 June 2015 at 01:16, Marsh Ray <maray@...rosoft.com> wrote:

>  > While I would imagine it's almost infeasible, at this moment in time I
>
> >also don't see why a PDF with data-dependent timings would ever be picked
> anyway.
>
>
>
> While I agree data dependent timings are a non-starter, it’s kind of a
> shame. If the access patterns is not known in advance (i.e., it varies per
> guess) it can make it harder for an attacker to hide memory latency.
>
>
>
Yeah, but on balance a constant-time implementation is still preferable to
even the remote possibility of opening up a new attack vector that hadn't
existed before... would be somewhat embarrassing for the PHC if a few years
down the line it turned out that password data could be recovered from a
local timing attack that an unsalted md5 password hash isn't vulnerable to
:-)

Admittedly, I'm still not convinced on the utility of most memory-hard
PDFs anyway.  Put it this way, I'm working on a project just now that may
end-up serving a reasonably high load of login requests and will choose
something *far* more light-weight for the password hash than has been
generally proposed on this list -- memory and compute cycles aren't free.
You get far more bang for your buck by giving users a swift swift kick up
the rear-end and forcing them to pick marginally better passwords.

Content of type "text/html" skipped