On 5/8/15 2:34 AM, Solar Designer wrote:
> On Mon, May 04, 2015 at 11:48:25AM +0200, Fabio Pietrosanti (naif) - lists
> wrote:
>> Also for upcoming implementation extending scrypt concept, like
>> yescrypt/yescrypt-lite it would be very interesting to think how to make
>> it faster in the contex
On Fri, May 08, 2015 at 09:04:47AM +0200, Fabio Pietrosanti (naif) - lists
wrote:
> Do you think that yescrypt-lite in JS will be a reasonable substitute of
> scrypt within a defined amount of time (we're open and interested to
> integrate latests crypto)?
according to someone close to the PHC co
Hi,
Disclosure: I am the designer of yescrypt (building upon Colin Percival's
scrypt, obviously), and I am on the PHC panel (along with many others).
On Fri, May 08, 2015 at 10:34:28AM +0200, stef wrote:
> On Fri, May 08, 2015 at 09:04:47AM +0200, Fabio Pietrosanti (naif) - lists
> wrote:
> > Do
On Fri, May 08, 2015 at 04:27:19PM +0300, Solar Designer wrote:
> On Fri, May 08, 2015 at 10:34:28AM +0200, stef wrote:
> > according to someone close to the PHC compo, yescrypt is rich with
> > side-channels,
>
> Worded like that, it's FUD. It's a fully expected kind of FUD, though.
sorry - alt
On 5/8/15, Solar Designer wrote:
> ...
> The reality is: bcrypt, scrypt, and most PHC finalists use password
> dependent memory lookups, and thus are not cache-timing safe...
> In typical scenarios, this does not matter. In some, it does.
has there been consideration of a processor instruction f
