Re: Time Invariant String Comparison

[Andres Perera <andres.p@...>]

On Thu, Jan 16, 2014 at 4:42 PM, William Ahern
<william@25thandclement.com> wrote:
> On Thu, Jan 16, 2014 at 05:15:51PM +0100, Pierre Chapuis wrote:
>> > On Thu, Jan 16, 2014 at 5:01 AM, Oliver Kroth <oliver.kroth@nec-i.de>
>> > wrote:
>> >> Why not use hashed passwords, which is a better idea anyway as this
>> >> takes a
>> >> length independent time, and you may store the credentials in a safe
>> >> way?
>> >
>> > This is the best solution to the problem. The hashing function has
>> > fixed-length output making the comparison immune to timing attacks,
>> > and its own execution time is based only on the length of the input
>> > and leaks no information about the real password.
>>
>> +1. If you are storing passwords in cleartext timing attacks should
>> be the least of your worries. Use a good hashing function instead,
>> like bcrypt [1], scrypt or PBKDF2. See [2] to understand why those
>> ones and not generic hashing functions.
>>
>> [1] https://github.com/mikejsavage/lua-bcrypt
>> [2] http://codahale.com/how-to-safely-store-a-password/
>
> Cryptographic security depends on exponential cost differences. Key
> stretching solutions like bcrypt and PBKDF2 add linear costs. Their security
> is, therefore, mostly hype, IMNSHO.

this is a mathematically rediculous statement

if the increment to, eg, bcrypt number of rounds, entails linear cost,
it can be adjusted to match exponential

n = 16777216 = 2 ^ 24

if the iterator for *anything* entails linear growth, it can be
adjusted to match exponential

>
> Salting gives you a better bang for your buck. Fortunately, both bcrypt and
> PBKDF2 incorporate salting. Their true value lies not in their convoluted
> stretching schemes, but in the fact that they also incorporate other useful
> features, and that you can download them as libraries that are hard to screw
> up using.
>
>