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

Powered by blists - more mailing lists