[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+aY-u7Acp2MvF48tXg1kmnAjAM3re3z5Owp24sBE+QwSWC2zg@mail.gmail.com>
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
Powered by blists - more mailing lists