Message-ID: <CANDZ8KFwH15+ybWKkmOauLx=o4_eXouFiNQqxysftQ8moqAh+A@mail.gmail.com>
Date: Mon, 2 Mar 2015 07:15:20 +0530
From: Donghoon Chang <pointchang@...il.com>
To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net>
Subject: Re: [PHC] PHC status report

Dear Alexander,

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?

I am sorry for replying late to your above concerns. It took time to
prepare a note for the answer. (It took time to uproad it  on Eprint.) Rig
team wrote a note regarding your concern.

-------- Performance Analysis of Some Password Hashing Schemes (
http://eprint.iacr.org/2015/139.pdf)


In terms of performance comparison, as you can see from the note, our
experiment shows that Catena is the worst design among the category
"Catena, Gambit, Rig." from performance perspective. And based on our
implementation, Lyra2, Rigv2, TwoCats and yescrypt provides good
performances in a wide range of use cases.

Nonetheless, the PHC chose Catena as one of finalists due to other reasons,
though it looks that Catena is not-good choice in terms of performance.
According to the PHC status report, (
https://password-hashing.net/report1.html), Catena was chosen by the
following reasons.

   - Well-motivated design, convincing theoretical framework
   - Well-understood side-channel and TMTO resistance

But, in the PHC status report it was not mentioned that Catena seems to be
one of slowest designs compared to others. See  Fig. 1 of
http://eprint.iacr.org/2015/139.pdf. Actually, among 8 designs we
considered, our experiment comparion shows that Catena is the wost among 8.

I just want to know whether the PHC panel already knew the negative aspects
of Catena from the performance-perspective. If the PHC panel knew it, I
want to know why in the PHC status report it was not mentioned, only with
full of praises for Catena!

*Emphasize that This mail is not for blaming Catena design, but for
pointing out that it seems that the PHC status report was written with
biases!*

On the other hand, let us see the case of non-finalists. As one example,
see the PHC panel's evaluation on Rig case.

   - Similar to Catena, but received less attention (cf. bugs found in the
   specification and code)

"Bugs found in the specification and code" is NOT true in the second
version of Rig, which was accepted by the PHC panel.
I personally do not want to ask why Rig was not chosen, but I want to ask
to the PHC panel why the evaluation on Rig was very poorly written without
mentioning any good points of Rig. I personally do not want to ask any kind
of praise on Rig. But, I believe that the PHC panel, as the name of the
world-wide competition panel, though the PHC panel members have own jobs,
"has to" provide a much better report with more evidences based on facts.

I, personally, humbly request to the PHC panel to provide a better report,
please!

Thanks and regards,

- Donghoon





2015-02-12 22:28 GMT+05:30 Solar Designer <solar@...nwall.com>:

> 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
>

Content of type "text/html" skipped

Powered by blists - more mailing lists