phc-discussions - Re: [PHC] PHC status report

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]

Date: Thu, 12 Feb 2015 19:58:25 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] PHC status report

Thank you all for the very interesting comparison with the SHA-3 process.

On Thu, Feb 12, 2015 at 08:07:19PM +0530, Donghoon Chang wrote:
> => As you agree, we should not make any mistake once again. That's why now
> I request the PHC panel to take only good aspects of NIST SHA-3 selection
> process, by writing a public report and by evaluating each PHC candidate
> according to security and performance.

In other words, you're asking the PHC panel to analyze security aspects
(which aspects does this include? some are subjective) of all 22
non-withdrawn PHC candidates and to produce and compare optimized
implementations of them (both defense and attack?), all on the panel
members' own time?

Or should the panel rely on readily available analysis and
implementations (and for candidates lacking a particular bit of analysis
or implementations, just state so)?  What about the (currently almost
non-existent for PHC candidates) attack-optimized implementations, then?
(A concept that wouldn't be relevant for AES and SHA-3.)

The panel has already considered then-available information on the
candidates' security and performance.  (It also considered other
criteria, which you say shouldn't have been considered at this stage.)
We could list the limited available information in a report, but it'd
have many "blank fields" and would not fully reflect the selection of
finalists (because of the additional criteria and diversity).

Should we also go back and analyze pre-tweaks finalists in the exact
same fashion, just to be fair?

What should we do if such analysis (whatever it is that you request we
do) eventually shows e.g. Rig performing better than (pre-tweaks?)
Catena, which I admit it might?

In other words, is this just to do the 22 candidates justice (while
distracting us from selecting the winners to doing this previous step in
what might or might not be a better way), as well as possibly to improve
the public image of PHC (although that is unclear to me), or is it to
potentially affect the outcome of PHC (e.g., by potentially going back
and giving a current non-finalist time to tweak, and then selecting a
current non-finalist as a winner)?

Alexander