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: <BY2PR03MB55480F108D3934274BE792AA7AE0@BY2PR03MB554.namprd03.prod.outlook.com>
Date: Thu, 25 Jun 2015 18:52:45 +0000
From: Marsh Ray <maray@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] Why protect against side channel attacks

From: Ben Harris [mailto:ben@...rr.is]
> 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.

Things are changing with cloud. It’s the biggest shift in business computing I’ve seen since the personal computer. Shared CPU multi-tenancy is the new norm.

-          Marsh

From: Ben Harris [mailto:ben@...rr.is]
Sent: Thursday, June 25, 2015 7:54 AM
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<mailto:pinterkr@...il.com>> wrote:
>
> On Thu, Jun 25, 2015 at 4:16 PM, Ben Harris <mail@...rr.is<mailto: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