Re: [VOTE] Timing attack safe string comparison function

On Wed, Mar 19, 2014 at 1:27 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi all, > > On Wed, Mar 19, 2014 at 3:56 AM, Ferenc Kovacs <tyra3l@gmail.com> 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