phc-discussions - Re: [PHC] Re: 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]

Message-ID: <CAHOTMVKQYUoFzXZ1+pjqxsxKNLHxcCjgSH68p74621VHdejiXw@mail.gmail.com>
Date: Fri, 29 Mar 2013 18:36:57 -0700
From: Tony Arcieri <tony.arcieri@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] Re: Suggestion: API should include a verifier function

So upon further reflection, I really think the threat model of PHC is: the
attacker has the password hash. If you can solve that problem, the issue of
timing attacks should be irrelevant (I think this was e.g. Solar Designer's
point)

There's been quite interesting discussion to the contrary however.

I still think a verifier API is probably a good idea, regardless? If
nothing else, I think a separate verifier API is a good cryptographer <=>
end user interface ;)


On Wed, Mar 27, 2013 at 6:15 AM, Watson Ladd <watsonbladd@...il.com> wrote:

> This isn't necessary: a non-constant time comparison at worst reveals the
> hash, which doesn't give an attacker
> enough information to break a password anyway if we do our jobs right.
>
>
> On Tue, Mar 26, 2013 at 11:08 PM, Tony Arcieri <tony.arcieri@...il.com>wrote:
>
>> On Tue, Mar 26, 2013 at 7:57 PM, Tony Arcieri <tony.arcieri@...il.com>wrote:
>>
>>> you'd provide a user-supplied one as input, and verify via a guaranteed
>>> constant time comparison whether or not it's correct.
>>>
>>
>> Oops, not quite what I meant to say there, but I'm sure you got the idea
>> ;)
>>
>> To clarify: you would pass in the hash/salt "on file" along with the
>> alleged password, and the function would return whether or not the provided
>> password matches the supplied hash/salt. The arguments are, otherwise, the
>> same as the hashing function.
>>
>> As an API strawman, if this is our hashing function:
>>
>>     PHS(out, outlen, in, inlen, salt, saltlen, t_cost, m_cost)
>>
>> we might consider:
>>
>>    PHS_VERIFY(hash, hashlen, in, inlen, salt, saltlen, t_cost, m_cost)
>>
>> (I'm not particularly married to the name "PHS_VERIFY", so please
>> bikeshed away ;)
>>
>> --
>> Tony Arcieri
>>
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little Temporary
> Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
>



-- 
Tony Arcieri

Content of type "text/html" skipped