I agree with Jeffrey's suggestion to implement server-side KDF as well, with higher settings.
Just some minor detail on what (little) can be done on client side in JavaScript: On Thu, Mar 12, 2015 at 10:57:47AM -0600, Jeffrey Goldberg wrote: > 2. Use SHA-512 in PBKDF2 > > This will make PBKDF2 resistant to GPU based cracking efforts. > Note that this is resistance to attacks using current, off-the-shelf, > hardware. It is only a short term solution. I think this wording is too strong. While I did and I continue to advocate SHA-512 over SHA-256 for this reason (when someone insists on PBKDF2 or the like anyway), the gap with recent attack implementations is narrower than it used to be. For sha512crypt vs. sha256crypt, it's down to ~2x: https://hashcat.net/misc/p130_img/changes_v130.png And scrypt even at fairly low settings is likely somewhat stronger (or rather not-as-weak) against GPU attacks than PBKDF2-HMAC-SHA-512 at comparable low running time. Not at settings as low as Litecoin's 128 KB with r=1, but at settings like 2 MB with r=8, which is affordable in JavaScript. BTW, given the wide availability of scrypt altcoin ASICs, some of which can handle higher N (this is known) but likely not higher r (this is a plausible guess, given the incentive model for those ASICs), and given the effect r has on scrypt speeds on GPU, I recommend that scrypt paper's recommended r=8 (rather than altcoins' typical r=1) be used. That's even when the original reason for using r=8 (reducing the frequency and thus performance impact of TLB misses, and allowing for some prefetching) does not apply, like it mostly does not with JavaScript. (Of course, someone may produce more capable scrypt ASICs.) Alexander _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
