Hacker News Reader

While this is true, you can tune the work factor of PBKDF2 accordingly. On the positive side, it's easier to argue for PBKDF2 in face of regulations since it's a standard while scrypt is not.

View on HN

The problem with tuning it is that if you use it on a mobile, for example, tuning it enough to thwart a GPU would mean that one authentication would take 10sec on the mobile.

We have done some work on a branch in SQLCipher that allows for adaptive key derivation length based on the device it runs on. The iteration length will be computed per device where time is the constraint. We presented our initial findings last year at PasswordsCon 14.

Isn't that the standard? We always time the iterations for a specific time delay on the specific device and use that, and that's what, for example, LastPass (IIRC) does.

That still does nothing for the fact that a GPU will be thousands of times faster than a mobile.

>Isn't that the standard?

SQLCipher uses PBKDF2 as a standard mechanism to compute a key, however by default it uses a static iteration length, currently 64,000.

The problem is often that the device spread varies greatly and often a given application will target more than one device. You can watch our presentation covering the details here:

https://www.youtube.com/watch?v=b8TNHZ7fWzg&list=PLdIqs92nsI...

Reply on news.ycombinator.com