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:45:47 +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

Well, it’s not the salt per se, but the access pattern it generates.

Is there an attacker advantage if they have the ability to perform queries on the addresses generated by a unknown salt for a limited set of chosen password inputs?

I don’t recall if the PHC analysis considered this question explicitly for those functions with password-derived access patterns.

It’s probably a moot point for a couple of reasons:
* It doesn’t sound like we’re actually contemplating a function with a password-derived access pattern side channel, and
* The salt is not a capital-S Secret, by definition, so we’re forbidden from reasoning about it as if it were, even if hopefully it is.

-          Marsh

From: Bill Cox [mailto:waywardgeek@...il.com]
Sent: Wednesday, June 24, 2015 6:18 PM
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Why protect against side channel attacks

On Wed, Jun 24, 2015 at 5:55 PM, Marsh Ray <maray@...rosoft.com<mailto:maray@...rosoft.com>> wrote:
Again, these cache timing side channels tend to leak the salts too.

How?  In most cases, salt never leaves the authentication servers and associated storage.  The salt is hashed/shredded before unpredictable addressing begins.

Content of type "text/html" skipped