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 _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
