phc-discussions - Re: [PHC] Native server relief support for password hashing in browsers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1676159410.20140119182109@gmail.com>
Date: Sun, 19 Jan 2014 18:21:09 +0100
From: Krisztián Pintér <pinterkr@...il.com>
To: Christian Forler <christian.forler@...-weimar.de>
CC: discussions@...sword-hashing.net
Subject: Re: [PHC] Native server relief support for password hashing in browsers

Christian Forler (at Sunday, January 19, 2014, 6:02:34 PM):

> We never claim that the cache-timing attacks against scrypt are practical.

all attacks start infeasible, and it is a good excuse to ignore the
problem. then they become feasible, and ... people look for another
excuse to ignore the problem. we have seen this so many times.

it would be nice if, at one day, we all came to an agreement that it
is smart to listen to cryptographers. if they say that something is
fishy, we need to start moving away from it immediately. it takes time
to clear up all the legacy code, but if we don't start, we will never
get anywhere.

by the same token, considering cold boot attacks or DMA attacks, with
memory hard pbkdf-s, we are moving into the exact opposite direction
than the trend. in all other areas, we try to put crypto in the CPU.
with memory intensive functions, we hugely exacerbate the problem
instead.

it is getting to be my pet peeve, but i think we badly need some
randomized blinding.