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
| ||
|
Message-ID: <BY2PR03MB5549BAF207FBCC24EDBF9E7A7650@BY2PR03MB554.namprd03.prod.outlook.com> Date: Tue, 9 Dec 2014 23:21:41 +0000 From: Marsh Ray <maray@...rosoft.com> To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net> Subject: RE: [PHC] PHC finalists announcement I'm a panel member with my "personal opinions" hat on: From: Krisztián Pintér [mailto:pinterkr@...il.com] Sent: Tuesday, December 9, 2014 2:32 PM > since we are waiting for the decision details, why not review the criteria meanwhile? >> - defense against GPU/FPGA/ASIC attackers > > what about CPU attackers? consider a botnet or cloud computing. In a sense, the goal of a good PHF is to make it possible for the defender's CPU environment to be the optimal one for performing the work factor. >> - quality of the documentation > > hm. at this point, we have severe disagreement. can it be the case > that a better candidate is not selected, because a weaker candidate > was better documented? can it be the case that, provided the competition > will have an infuence on the industry practice, we will stuck with > an inferior method just because it was poorly documented once? I would hope that wouldn't happen, but the quality of documentation is important. I don't think we can assume that someone else will come along later and invest the time into producing a high-quality specification suitable for implementers. It doesn't have to be a Latex formatted academic paper, but I want to ask the question: "If I and N other software developers were to implement this function from this specification what are the chances we would end up with bug-free and interoperable implementations?" >> - quality of the reference implementation > > same points here. nobody ever intended to actually use the reference > implementation. I don't think that's a safe bet. On the contrary, I think the first thing that will happen is that people will port the reference implementation to their scripting language frameworks, distro maintainers will package it as libraries, etc. > it would be a shame to exclude a good algorithm due > to a subpar reference implementation. Read the Bcrypt paper if you haven't already. It's a great paper about a great password hashing scheme. https://www.usenix.org/legacy/events/usenix99/provos/provos.pdf But observe the ambiguity it leaves for implementers wishing to make a bug-free and compatible implementation. Observe the lack of a portable reference implementation. Observe the lack of a diverse set of test vectors. Observe this CVE: http://www.openwall.com/lists/oss-security/2011/06/20/2 IMHO, a primary goal of the PHC should be preventing such a thing from happening. > > - general soundness and simplicity of the algorithm > > i'm unclear what this means. i understand simplicity, but not > general soundness. The obsolete modified-DES crypt(3) is an example of a "generally unsound" password hashing function. Basically it sucks by modern standards, and in retrospect made some questionable assumptions in its design. http://linux.die.net/man/3/crypt > > - originality and innovation > > although i appreciate innovation, we need to understand that > innovative and good are independent concepts. an attacker will > not in any way be stopped by shining new ideas, unless they > are also good. however, an attacker might be stopped by old > ideas, provided they are good. Agree. - Marsh
Powered by blists - more mailing lists