RE: Time Invariant String Comparison

[Thijs Schreijer <thijs@...>]

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Rob Kendrick
> Sent: donderdag 16 januari 2014 13:51
> To: lua-l@lists.lua.org
> Subject: Re: Time Invariant String Comparison
> 
> On Thu, Jan 16, 2014 at 06:39:28AM -0600, Paige DePol wrote:
> > On Jan 16, 2014, at 6:30 AM, Elias Barrionovo <elias.tandel@gmail.com>
> wrote:
> >
> > > On Jan 16, 2014 9:55 AM, "Daniel Silverstone" <dsilvers@digital-
> scurf.org> wrote:
> > > > Lua's strings are interned and hashed.  As a result, string
> > > > comparison for equality is pretty much constant time :)
> > >
> > > Unless it's Lua >= 5.2 and the password is really large, like >32 bytes
> large. But this can be changed at compile time.
> >
> > As for the password attack, wouldn't just adding a tiny random delay to
> each request negate such a problem?
> 
> Depends on the quality of your RNG.  If you use /dev/random then you've just
> changed the attack from a timing attack on passwords to an entropy depletion
> attack.
> 
> B.

How about setting a maximum size (100 chars) and always compare each character in a loop, all of them, so no early exit from the loop. After the loop determine the verdict.

Slightly slower for the user, but that is negligible. Always constant duration.

Something like (untested);

compare = function(str1, str2)
local fails, dummy
for i = 1,100 do
  if (str1:sub(i,i)~=str2:sub(i,i)) then
    fails = true
  else
    dummy = true  -- just here to make execution time the same
  end
end
return not fails

Thijs