Hacker News Reader

Comment by JulianMorrison | Hacker News Reader

From Wikipedia, use of PBKDF2 leaves this vulnerable to GPU based fast dictionary attacks (versus eg: scrypt that is a deliberate RAM hog).

View on HN

While this is true, for these sorts of deployments you would use a high-entropy random key, not just a password. I guess it's different if you want to deploy this on a mobile phone or something, though.

Other than that, this strikes me as a very nice way to get seamless, strong encryption for mobile or desktop apps (where data at rest needs to be protected) without writing a single line of crypto code.

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.

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