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: <CA+aY-u7dQYBX4dD0UUZmXNODaN2xhUyjhmy+acjWVwjACkrU9A@mail.gmail.com>
Date: Thu, 25 Jun 2015 12:42:41 +0100
From: Peter Maxwell <peter@...icient.co.uk>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Why protect against side channel attacks

On 25 June 2015 at 12:27, Ben Harris <mail@...rr.is> wrote:

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

Ah, yes, my variable naming is again completely mince, should have been
h=hash(salt+password) or similar.

You get the idea though: the salt must be secret to avoid an attacker being
able to exploit the low dimension of the password space.  Are we assuming
the salt as secret?

Content of type "text/html" skipped