[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+aY-u5Y--NVxOH_yXjTb9mEn-SWiwOAWFrdDHrgLUD4NceNPg@mail.gmail.com>
Date: Thu, 25 Jun 2015 12:18:24 +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 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.
The attacker would proceed by first determining, q, in the same manner as a
normal side-channel attack and then brute-force h against result
intermediate result q.
(you can of course apply some per-password secret key, k, say which would
ameliorate these concerns but that's essentially a secret salt)
>
> > how many calculations, n, per hash you can observe
>
> This becomes irrelevant.
>
Statistically, it's rather important in the above scenario, at the moment
at least.
>
> > and, obviously i and j.
>
> Yes. At least one of these must be large enough.
>
I would posit that j needs to be large enough when any data-dependent
timings are involved, using my argument above. That's the original
problem: making people choose better passwords.
Or one must start storing per-password secret data too, which is perfectly
feasible to be fair and might produce a nice middle ground here.
Content of type "text/html" skipped
Powered by blists - more mailing lists