solar at openwall.com
Fri Mar 13 10:43:50 EDT 2015
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
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:
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
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
(Of course, someone may produce more capable scrypt ASICs.)
More information about the cryptography