[cryptography] Javascript scrypt performance comparison

Solar Designer solar at openwall.com
Fri May 8 09:27:19 EDT 2015


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 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 compo, yescrypt is rich with
> side-channels,

Worded like that, it's FUD.  It's a fully expected kind of FUD, though.
This is why the PHC winner, if there's only one, will likely be
side-channel safe... and thus it'd be relatively weak in other ways,
because there's a security vs. security tradeoff here.

The reality is: bcrypt, scrypt, and most PHC finalists use password
dependent memory lookups, and thus are not cache-timing safe.  It's the
same kind of side-channel leak in all of these.  In some, not including
yescrypt, there's an additional leak via integer division.  In yescrypt,
it's only this one side-channel via memory lookups.

In typical scenarios, this does not matter.  In some, it does.  Needing
to consider these aspects, and the confusion around this, is a very good
argument in favor of otherwise-comparable but cache-timing safe PHC
finalists.  These are Catena and Argon2i.  For practical purposes,
though, this property weakens their security against offline attacks.

There are also hybrid designs, such as Lyra2.  These try to capture the
best of both worlds, but unfortunately when we're dealing largely with
FUD and confusion and when there are still (fewer) scenarios where their
partial cache-timing leaks matter anyway, this does not help - or at
least this appears to be the current perception.

> i wonder how to secure js implementations against these, and
> the extra sidechans that are introduced by the usage of js itself. can anyone
> enlighten pls?

For side-channel leaks from password hashing, cryptographically random
salts may help.  Here's relevant discussion:

http://thread.gmane.org/gmane.comp.security.phc/2922/focus=2934
http://thread.gmane.org/gmane.comp.security.phc/2922/focus=2945
http://thread.gmane.org/gmane.comp.security.phc/2922/focus=2949

BTW, a side-channel safe mode (with correspondingly worse security
against offline attacks) might be added to yescrypt later, but given
that much of the problem is about confusion around these issues, it's
unclear if that would help.  There's significant (and in some ways
reasonable, I admit) pressure for choosing a PHC winner that is fully
side-channel safe and does not even include a side-channel unsafe mode,
not even if it is clearly documented as such.

For example, it's technically trivial to combine Argon2i and Argon2d
into one scheme that would accept a side-channel safety flag, and I'd
support that.  But this might not be an adequate solution to the FUD.

Personally, I intend to opt for greater offline attack resistance, at
least for the next few years.  So that's where we'd part ways.

> i start to wonder what the name globaleaks really refers to, sidechans?

There are indeed valid concerns about JavaScript crypto in general, and
about that GlobaLeaks thing.  In this thread, I am commenting on
specific technical issues being raised, leaving the bigger picture
beyond scope, even though obviously the bigger picture matters more.

To me, having yescrypt(-lite) implemented in JavaScript is primarily one
of several tests for how implementable yescrypt is and what performance
it achieves in different languages/environments.  This may help improve
its specification.

Alexander


More information about the cryptography mailing list