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

Powered by blists - more mailing lists