[guardian-dev] CacheWord Key Derivation

[Abel Luck]

Daniel McCarney:
> On 16/03, Nathan of Guardian wrote:
>> On 03/13/2014 10:46 PM, Stephen Lombardo wrote:
>>> I do have one concern with the key derivation implementation. From the
>>> code in PassphraseSecrets.java and Constants.java, CacheWord seems to be
>>> using only 100 PBKDF2 iterations on the user provided key and a raw key
>>> with SQLCipher. This seems lower than it should be to support production
>>> applications using the library on real data, weakening the default
>>> protections that SQLCipher provides and users have come to expect.
>>
>> I know the 100 iterations value was a decision made by Abel early on,
>> though we also wanted it to be configurable. I am hoping he will respond
>> to this thread shortly, though he is in transit at the moment.
> 
> I believe the concern is with older devices. Increasing the PBKDF2
> iterations will create noticeable lag on devices with lower end
> processors. I agree that 100 iterations is probably overly conservative
> to be the default across the board.
> 
> Maybe we should solicit some test data from a range of devices?
> 

Indeed. This was the original concern. I adopted the 100 iteration value from TextSecure,
and tested the value on several very low end android phones bought in Turkey and found
that the lag was unbearable.

However, since then we've questioned whether its worth supporting such devices at all.


>>> Has there been any thought given to increasing the key derivation
>>> iterations? It would be great to see something equivalent to the
>>> SQLCipher default of 64K in the near future. That would make it easier
>>> to recommend CacheWord without caveats about weakening overall
>>> solution security.
>>
>> It seems quit easy to make the option configurable, and then the
>> developer could tune the user experience, as they wish. Any thoughts on
>> the performance impact that might have?
> 
> Long term I think the best bet is making it adaptive and set during the
> initial passphrase registration. Abel identified that as one of the
> project TODOs[0].
> 
> On first run the lib could perform measured PBKDF2 runs with the
> iterations increasing from the default. When the PBKDF2 wallclock
> runtime reaches a threshold that we think is an unacceptable delay (1s?
> 2s?) the iteration count would be fixed and used for user key
> derivation.

Exactly. Work on an adaptive iteration count has been started already, with a POC by
another dev [1]. But the code quality is poor and needs to be entirely rewritten for more
general application. This approach while ideal, is fraught with complications, namely that
there is a large variance in calculated values due to existing system load. Of course any
value is liable to be larger and better than 100.

An alternative to the live-adaptive algorithm would be to use one of those android cloud
mass-device testing services like appthwack.com or testdroid.com and include
per-calcualted values for various devices with either a hardcoded or adaptive fallback.

Anyways, to address this issue immediately I'll assume we're targeting a decently powerful
device, and bump the value to 64,000, while making the value configurable for the dev and
provide a migration route to rekey existing databases.

~abel


[1] https://github.com/abeluck/PBEKeyTester