On Wed, Mar 19, 2014 at 1:27 AM, Yasuo Ohgaki <[email protected]> wrote:
> Hi all,
>
> On Wed, Mar 19, 2014 at 3:56 AM, Ferenc Kovacs <[email protected]> wrote:
>
>> > > > From benchmark result, overhead for timing safe comparison is
>> negligible
>> > > > with byte by byte comparison.
>> > > > I would like to see timing safe "===" for 5.6, if it's
>> > > > possible.
>> (== could
>> > > > be timing safe, too)
>> > > >
>> > > > Is anyone working on it?
>> > >
>> > > I don't know if someone else is, but I am not.
>> >
>> > I'm not in favour of this — identity doesn't imply timing safety, and
>> > I think we should keep operators as performant as possible.
>> >
>>
>> Agree and afair it was explicitly stated as out of scope for this rfc.
>> (sorry for not merging this sooner, thanks Adam for thaking care of this).
>>
> Benchmark reveals performance issue is negligible.
>
and that benchmark was executed only one platform, with random data.
I'm not saying that it's not accurate, but it is a different kind of risk
when you introduce a new method for specific compare functionality than
replacing === with this new method for everybody.
>
> Regardless of where it is implemented, simple byte by byte compare is the
> best.
> We may ignore length leak at all. It's simpler (less risk) and faster.
>
> It's better to make === timing safe like Python, since it would
> be far less risks than dedicated API, but we may consider this later if
> the risk is
> getting greater.
>
I disagree, yeah we could cover up more ground if we replace the ===
implementation with a timing safe one, but that would be more riskier from
the stability point of view, than adding it as a separate function first.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu