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: Tue, 14 Apr 2015 17:19:13 +0300 From: Solar Designer <solar@...nwall.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] Competition process On Tue, Apr 14, 2015 at 01:01:54PM +0000, Gregory Maxwell wrote: > I've personally felt that there is no win here... that there are > elements of each candidate that I consider superior which are not > incompatible and only do not exist in a single proposal due to how the > history panned out. For many finalists, yes. But for yescrypt in particular, there's only one desirable property it's lacking that isn't strictly incompatible with those it does have: cache timing safety. While adding cache timing safety is incompatible with some of yescrypt's current elements, it can nevertheless reasonably be made an option (disabling those elements). In fact, I might add this option later (as a non-PHC extension, given that we have no further tweaks planned in PHC). Are you aware of anything else that yescrypt could have had, but is lacking only "due to how the history panned out"? yescrypt is being criticized primarily for being overly(?) complex, and this is in fact related to it being that almost all-in-one solution. (It could be slightly simpler, yet with all of its present features, if I started over without the scrypt legacy. But only slightly.) Makwa's delegation is probably not something that could reasonably be added to the mix of what's currently in yescrypt. It'd probably double the complexity, so these may be better as independent schemes that can be used together whenever that makes sense in a given protocol. > Some might think that this fact is a reason to select many winners; > but I think many winners is pessimal for the marketplace. There is so > much that any of the candidates can be improved through really > excellent implementation which is diluted by multiple options, there > is compatibility lost, etc. There are definitely major drawbacks to having multiple winners with overlapping use cases. So far, I tried to provide for a workaround by defining yescrypt such that cut-down partial functionality implementations make sense, and are significantly simpler. (We need to actually produce some of these, to demonstrate that.) The PHC panel might or might not find this workaround "good enough" (so it might or might not select yescrypt), but I'm afraid our alternatives are either to select another single winner that isn't an all-in-one, or to select multiple winners. None of these three options (all-in-one winner, non-all-in-one winner, multiple winners) is perfect. Alexander
Powered by blists - more mailing lists