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 19:27:48 +0800
From: Ben Harris <mail@...rr.is>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Why protect against side channel attacks

On 25 Jun 2015 7:19 pm, "Peter Maxwell" <peter@...icient.co.uk> wrote:
>
>
>
> On 25 June 2015 at 07:25, Solar Designer <solar@...nwall.com> wrote:
>>
>> On Thu, Jun 25, 2015 at 12:35:42AM +0100, Peter Maxwell wrote:
>> > Lets assume there is
>> > i bits of global secret data, s, and j bits of per-password secret
data, h,
>> > say.  The question then becomes: how much of s and h you can determine
in
>> > observing the side-channel for a single PDF calculation
>>
>> With proper design, where the secrets are passed through a fast
>> cryptographic hash first (that is not itself susceptible to side-channel
>> leaks), the answer to your question above is:
>>
>> Essentially none, as long as i and j are large enough (e.g. 128 bits
>> each) and s and h are cryptographically random.
>>
>> In fact, to fully defeat the attack, it is sufficient to have s or h;
>> it is not necessary to have both.  (In practice, it may be helpful to
>> have both for other reasons.)
>
>
> Not sure if we're talking at cross purposes here, or that having had a
night's sleep I'm a bit more awake, but I think the algorithm would still
be in trouble.
>
> If you pre-hash with constant time, say, global secret s and per-password
data, h, to create, q, say then the access pattern will be a function of
both s and h.  Remember that s is constant and h is picked from a space of,
around, 2^40 (or some reasonable reflection of password strength.

h in this example was the per user salt, assumed to be ~128bit. So even
knowing q, you would not be able to brute force the password without h. A
successful attack would require both a database leak (to get the salt) and
a side channel attack (to remove the password stretching).

Content of type "text/html" skipped