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]

Message-ID: <CAMtf1HvF-Lb6JczRqWZhHMVuSpspzXYDC3vp+WaTzC6xRXLz5Q@mail.gmail.com>
Date: Thu, 25 Jun 2015 22:53:41 +0800
From: Ben Harris <ben@...rr.is>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Why protect against side channel attacks

On 25 Jun 2015 10:36 pm, "Krisztián Pintér" <pinterkr@...il.com> wrote:
>
> On Thu, Jun 25, 2015 at 4:16 PM, Ben Harris <mail@...rr.is> wrote:
> >> secret salt disables server relief
> >
> > You could have the client send
> > the password and the server reply with hash(password, salt) which the
client
> > then does stretching on.
>
> i guess it would, but adds one more round of communication, and also
> removes the benefit of not needing the password ever leave the client.

The client needs to request the salt either way, so it isn't saving a
round.

> all this hassle just to be able to use something that should not be
> used in the first place anyway.

I've always been on the cache-independent bandwagon, I'm just feeling that
some of these arguments against cache-dependent candidates are getting a
little close to FUD.

Performance efficiency
Data independence
Time-space-area hardness

None of the candidates give all three, it seems like we can only get two.
And based on my experience working in companies, security policies are
rarely so good that side channel attacks make up a large fraction of your
risk level.

Content of type "text/html" skipped