Message-ID: <20150302093322.GA29005@openwall.com>
Date: Mon, 2 Mar 2015 12:33:22 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] PHC status report

On Mon, Mar 02, 2015 at 09:02:33AM +0100, Kriszti?n Pint?r wrote:
> Solar Designer (at Monday, March 2, 2015, 7:38:49 AM):
> 
> > (I acknowledge that there are some scenarios, which
> > might become more common in the future, where the lack of cache-timing
> > resistance has practical security cost, too.  And I'd like to thank
> > Krisztian for reminding us of these on several occasions.)
> 
> let me remind you that the topic did not receive a whole lot of
> attention, and mostly met silence.

The topic was in fact mostly met with silence, but I agreed with you on
the scenarios where this issue matters.  There was nothing to argue
about.  I simply agreed with you here:

http://thread.gmane.org/gmane.comp.security.phc/1673/focus=1679

However, I do not agree with your implied suggestion (if I understood
you correctly back then) that we shouldn't be considering
non-cache-timing-safe schemes at all.  I think we should.

I can't speak for others, but clearly you're not alone in pushing for
cache-timing-safe designs, and one of them is a PHC finalist.

> if there was any discussion on the
> private forum, it would be useful to hear about it.

No, there wasn't any (that I recall), except for the consensus that we
need a cache-timing-safe scheme among finalists and thus among potential
winners.

> the only reaction
> i can recall from the panel was Jeremi Gosney, and his rather peculiar
> remark of "Password hashing is not cryptography. Timing attacks are
> not a practical concern in password hashing, especially not with
> salted schemes."

I think that's a simplistic view not shared by all on the panel, and
"not cryptography" is poor wording.  I guess Jeremi was trying to
emphasize the mostly engineering nature of password hashing, but I'd
agree that timing attacks may apply regardless.

Personally, I would definitely stay solely with cache-timing-safe
designs if there weren't a practical security price to pay for that.
Unfortunately, there is, and so we have to weigh cache-timing safety vs.
other desirable security properties.

> > Yes, Rig update was accepted and was considered along with other
> > submissions after that point, but Rig already ranked poorly by that time
> > and there was no policy to require panel members to reconsider their
> > assessment of a candidate whenever an update was received and accepted.
> > So bugs in the earlier version did affect the non-selection.
> 
> after reading this five times, i'm still unable to find any meaning
> that would be acceptable.
> 
> please explain me in what framework does that make sense? catena got a
> complete rewrite after a practical break. and it was still accepted.
> apparently, a bugfix in an implementation was not.

I never said the Rig update was not "accepted".  It was.  It was just
(likely) not re-reviewed by panel members who had already formed an
opinion on Rig by the time the update was received.  I am not aware of
any different treatment of Catena.

My understanding is that the bugs in the initial Rig submission were not
that important per se (bugs can be fixed, and the PHC timeline provided
for tweaks), but were treated by some panel members as indicating that
Rig was not as mature as Catena, thus affecting the selection in favor
of Catena.  This makes sense to me.

As to your claim that "catena got a complete rewrite after a practical
break", which would invalidate the maturity reasoning, I just don't know.
This isn't "my category".  I'd appreciate comments from someone familiar
with the Catena update.

> this and other remarks from other panel members just make me more and
> more convinced that there is no rationale behind the decision, but
> only personal preference. the status report is only a patchwork to put
> something on the table.

Like I keep saying, the status report reflects the selection rationale.
Obviously, things such as "convincing theoretical framework", which is
said of Catena, are subjective ("convincing" to whom? to panel members
who were in greater support of Catena than its alternatives).  You say
this is no rationale at all.  That's your opinion.

> if it was down to a voting,

As already explained in here, the voting was part of the process, but it
did not directly decide the selection (nor was it intended to).  In the
Catena vs. Rig case, the overwhelming difference in support by the panel
was apparent after the voting, though, and Rig v2 was not yet submitted
during the voting.  This didn't formally exclude Rig from further
consideration as a potential finalist, but it focused further discussion
on the top contenders, which at that point Rig wasn't.  Of course, any
panel member was free to direct discussion to any candidate, including
Rig, but IIRC no one asked to discuss Rig further.  (Gambit was still
being discussed.)  I think the submitters of Rig just didn't provide
clear reasoning on why they thought Rig should have been selected over
Catena and Gambit.  (I think you also didn't do that for Gambit.)

> i think we should see the results of that voting.

I support this.  Not that it would matter.

> why is it secret again?

I guess for two reasons: need permission from everyone who voted, and
the votes not directly deciding the selection.  In fact, you wrote:

"i was under the impression that the voting was the selection method.
if it wasn't, then it indeed does not matter much."

And that's exactly the case.  You also wrote:

"what matters is the actual rationale, what the selection was based on."

And this is summarized in the status report, like it or not.

I also wish the panel put more effort into this and decided on the
finalists in more of a scientific manner - in fact, contrary to what you
say I wouldn't mind more original analysis by the panel (rather than
just processing of previously available findings).  But I don't find the
subjective criteria and their application that bad, either.

Alexander

Powered by blists - more mailing lists