phc-discussions - Re: [PHC] Suggestion: API should include a verifier function

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: Wed, 27 Mar 2013 13:55:06 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Suggestion: API should include a verifier function

On 27 March 2013 02:57, Tony Arcieri <tony.arcieri@...il.com> wrote:

> I think to be a "complete" solution, the API should include a verify
> function which guarantees a constant time comparison, similar to what NaCl
> provides for its authenticators:
>
> http://nacl.cr.yp.to/auth.html
>
> e.g.
>
>     crypto_auth(a,m,mlen,k);
>     crypto_auth_verify(a,m,mlen,k);
>
> Without such an API, I am afraid that users of the API will screw up the
> comparison and open themselves up to a timing attack.
>

I'm not sure such a strict condition is actually necessary, it is probably
sufficient to require any underlying primitives are time-constant.

>From what I understand, timing-attacks are really designed to derive key
data by using data-dependent timing differences in an algorithm.  So, if
there was a secret key involved in a password hash algorithm, that would
need protecting in this manner.  Any secret key would however not be
exposed due to differences in, say, an iteration count of the underlying
primitive (you cannot derive any key material that isn't as efficient by
brute-force).

Deliberately introducing timing-differences in a well defined manner can
actually create an asymmetric problem that is disadvantageous to the
attacker and makes the defender's job easier; if I do submit an entry to
the PHC, this will be included as a mode of operation in my submission.  In
other words, one can force the attacker to do (I think) roughly O(n^2) work
instead of O(n) work and retain the entire password hashing algorithm
server-side.



>
> The arguments of the verifier function are identical to the original
> hashing function, except instead of calculating a password hash, you'd
> provide a user-supplied one as input, and verify via a guaranteed constant
> time comparison whether or not it's correct.
>
> --
> Tony Arcieri
>

Content of type "text/html" skipped