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: <CY1PR0301MB06683F0FEC73CD77DD0BAB6DACAE0@CY1PR0301MB0668.namprd03.prod.outlook.com>
Date: Thu, 25 Jun 2015 00:18:21 +0000
From: Greg Zaverucha <gregz@...rosoft.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: RE: [PHC] Why protect against side channel attacks

Yes I (and others, like you Krisztián) have understood the technical mechanics of how the attack would work for a while.  But I hadn't thought through the whole scenario that I described in my email, and the part that was new to me was that there isn't a good way to recover from this type of attack, and OTOH some breakthrough that makes hashcat a lot faster can be dealt with relatively easily.   Again, apologies if this was pointed out before, I'm simply agreeing with it. 

To Marsh's comment about the 10x. Even if it was discovered that the PHF with side-channel protections was no better than ROT13(salt||password), it's still easier to deal with than finding out attackers have been successfully exploiting side-channel attacks. 

Greg

-----Original Message-----
From: Krisztián Pintér [mailto:pinterkr@...il.com] 
Sent: Wednesday, June 24, 2015 12:53 PM
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Why protect against side channel attacks


Greg Zaverucha (at Wednesday, June 24, 2015, 9:12:16 PM):

> To summarize, hashing with a function that has side channels 
> introduces a new attack vector, and can put passwords at risk even without a breach.


this is indeed an important point. but even more important that i explained it more than a year ago on this very list, with very minimal impact.

> Date: Mon, 28 Apr 2014 16:25:34 +0200
> on timing attacks
>
> scenario: we can run a task on the same computer, or otherwise can 
> listen in on its memory usage patterns (power analysis, etc). but 
> otherwise we have no access to either any memory or on-disk databases.
> we can acquire a memory access fingerprint, that is, some 
> characteristics of the pattern in which memory is accessed (number of 
> cache misses in a time window, access of certain memory locations or 
> blocks, etc). this fingerprint is unique to the password/salt 
> combination. therefore we can check a password/salt hypothesis by 
> running the algorithm against it, and matching to the access 
> fingerprint.
> ...
> in short, correlation between secret information and memory access 
> patterns not only offers a shortcut, but in fact opens up a new attack 
> vector that previously was not present.


to which (and my later attempts) the following answers were given:


Thomas Pornin:

> This may also be due (at least in part) to performance reasons.
> Data-dependent branching will behave poorly with regards to jump 
> prediction within the CPU.

> To a large extent, password hashing works in a complete opposite 
> direction


Hongjun Wu:

> POMELO is a conservative design so that even when the cache-timing 
> attack is successful, POMELO can still perform as a strong PHS.


Jeremi Gosney:

> I've never heard that this was a no-no in the context of password 
> hashing. On the contrary, data-dependent branching is something that 
> has been considered highly desireable in password hashing

> Password hashing is not cryptography. Timing attacks are not a 
> practical concern in password hashing, especially not with salted schemes.