[guardian-dev] CacheWord Key Derivation
abel at guardianproject.info
Tue Mar 18 07:13:57 EDT 2014
> On 17/03/14 12:38, Abel Luck wrote:
>>> 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 . 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.
> We have some code for calibrating the PBKDF2 iteration count here:
> See chooseIterationCount() and sampleRunningTime() near the end of the
> This code is called the first time the app is run. We take 30 samples
> with 1 iteration and 30 with 2 iterations, alternating between 1 and 2
> so that any startup effects (JIT, memory caches, etc) are spread
> evenly across both groups. We take the median of each group, because
> the median is more robust to outliers than the mean. We use the
> medians to estimate the initialisation time and the execution time per
> iteration. Then, given a target execution time, we subtract the
> initialisation time and divide by the iteration time to give the
> iteration count.
This looks super Michael, thanks for sharing. We very well might adapt it for our needs.
Have you tested it across a spread of devices? Does it produce strong iteration counts?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the Guardian-dev