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: Thu, 25 Jun 2015 01:40:46 +0100
From: Peter Maxwell <>
To: "" <>
Subject: Re: [PHC] Why protect against side channel attacks

On 25 June 2015 at 01:16, Marsh Ray <> 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

Powered by blists - more mailing lists