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: <014b01ce2bde$bd936290$38ba27b0$@acm.org>
Date: Thu, 28 Mar 2013 11:04:48 -0700
From: "Dennis E. Hamilton" <dennis.hamilton@....org>
To: <discussions@...sword-hashing.net>
Cc: <fgrieu@...il.com>
Subject: RE: [PHC] Re: Suggestion: API should include a verifier function

Yes to all of that.  And the reason that I said "Again, it is all the more reason that there be a verification API behind which a platform-sensitive solution can be encapsulated."  What you give the compiler/script-engine is not what you get.  Sometimes cpu dependence and use of assembly code is the answer.  But that can all be somewhere behind the API.

I think Jeremy's observation about where the retrieval of the held key occurs and where the verification happens are all important.  I don't think that's so much an observation about the comparison as about where the verification occurs.  And if one is situated where the fetched key (correct-hash) value is observable, it strikes me that there is a lot more for the vulnerable party to worry about than this attack.

I agree that an attack of the scale required here going undetected and unthwarted suggests far more difficulty than just this vulnerability.

I am not proposing a change to the PHS API.  I am agreeing that a PHSverify( ) interface is also desirable (whether or not a minimum requirement for a PHS submission).  A reference implementation should be carefully annotated to explain what is undesirable to put into production without addressing platform issues in the implementation and the threat model where situated in an application.

 - Dennis

-----Original Message-----
From: Francois Grieu [mailto:fgrieu@...il.com] 
Sent: Thursday, March 28, 2013 09:35
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Re: Suggestion: API should include a verifier function

[ ... ] I am skeptical at universality of a reference
implementation of bulletproof hash-to-key comparison, and think a reference
implementation (similar to Dennis E. Hamilton's second example) belongs to
some reference example uses and test harness, also taking care of giving
reference values for input in at least a practical subset of UTF-8 (and
perhaps canonicalizing 16-bit unicode input).

Such reference would be quite useful, I think, and largely common to all
submissions sticking to the default API:

|    int PHS(
                     void*   out, size_t  outlen, // hash output
               const void*    in, size_t   inlen, // password input
               const void*  salt, size_t saltlen, // salt input
            unsigned int  t_cost,                 // controlling of time
            unsigned int  m_cost                  // ||||controlling of memory||
            ); |

If that API needs extensions, I think the single most useful would be a
control on how many CPUs should be usable (or perhaps the design challenge
would bemaking that largely transparent).

   Francois Grieu