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
| ||
|
Date: Thu, 28 Mar 2013 19:02:56 +0000 From: Marsh Ray <maray@...rosoft.com> To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net> CC: "fgrieu@...il.com" <fgrieu@...il.com> Subject: RE: [PHC] Re: Suggestion: API should include a verifier function In the history of computing, nobody has ever needed a way to "hash passwords" per se. What the world needs is a batteries-included and fool-resistant scheme for securely storing and validating password-based credentials. - Marsh > -----Original Message----- > From: Dennis E. Hamilton [mailto:dennis.hamilton@....org] > Sent: Thursday, March 28, 2013 11:05 AM > 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
Powered by blists - more mailing lists