On Thu, May 31, 2012 at 2:03 AM, Jon Callas <[email protected]> wrote:
> On May 30, 2012, at 4:28 AM, Maarten Billemont wrote:
>
>> If I understand your point correctly, you're telling me that while scrypt 
>> might delay brute-force attacks on a user's master password, it's not 
>> terribly useful a defense against someone building a rainbow table.  
>> Furthermore, you're of the opinion that the delay that scrypt introduces 
>> isn't very valuable and I should just simplify the solution with a hash 
>> function that's better trusted and more reliable.
>>
>> Tests on my local machine (a MacBook Pro) indicate that scrypt can generate 
>> 10 hashes per second with its current configuration while SHA-1 can generate 
>> about 1570733.  This doesn't quite seem like a "trivial" delay, assuming 
>> rainbow tables are off the... table.  Though I certainly wish to see and 
>> understand your point of view.
>
> My real advice, as in what I would do (and have done) is to run PBKDF2 with 
> something like SHA1 or SHA-256 HMAC and an absurd number of iterations, 
> enough to take one to two seconds on your MBP, which would be longer on ARM. 
> There is a good reason to pick SHA1 here over SHA256 and that is that the 
> time differential will be more predictable.

If you'll advise the use of compute-hard PBKDFs why not also memory
hard PBKDFs?  Forget scrypt if you don't like it.  But the underlying
idea in scrypt is simple: run one PBKDF instance to generate a key for
a PRF, then generate so many megabytes of pseudo-random data from that
PRF, then use another PBKDF+PRF instance to generate indices into the
output of the first, then finally apply a KDF (possibly a simple hash
function) to the output of the second pass to generate the final
output.  The use of a PRF to index the output of another PRF is
simple, and a simple and wonderful way to construct a memory-hard
PBKDF.

Meory and comput hardness in a PBKDF is surely to be desired.  It
makes it harder to optimize hardware for fast computation of rainbow
tables.

Nico
--
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to