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: <20150625062544.GA2450@openwall.com>
Date: Thu, 25 Jun 2015 09:25:44 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Why protect against side channel attacks

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.)

> how many calculations, n, per hash you can observe

This becomes irrelevant.

> and, obviously i and j.

Yes.  At least one of these must be large enough.

> That would give you a rough idea of the resulting search space(s).

Under your scenario, the search space(s) are trivially made so large
that the attack can't advance at all.

Alexander