[guardian-dev] CacheWord Key Derivation
hans at guardianproject.info
Fri Mar 28 13:54:22 EDT 2014
On 03/28/2014 01:27 PM, Abel Luck wrote:
> On Thursday 13 March 2014 22:46:49 Stephen Lombardo wrote:
>> CacheWord seems like a really useful service library, and I've noticed that
>> the Guardian Project is strongly advocating it's use, e.g. on the recent
>> NoteCipher post, WeChat announcement, and the SQLCipher Mailing list.
>> 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.
>> Since many developers don't really look at low-level security details, they
>> might choose to implement CacheWord with SQLCipher without understanding
>> that the current builds could reduce the key derivation complexity by a
>> factor of up to 640.
>> 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.
>> Stephen Lombardo, Zetetic LLC
> Quick update.
> This has been almost fixed in CacheWord with this commit:
> The new minimum has been set to 1000, but the default behavior is to run a 30
> second calibration (see previous email from Michael Rogers) to calculate a
> more secure value.
> As has been pointed out to me by CacheWord users already, this 30 second delay
> is not acceptable. At the moment the only recourse is to disable the auto
> calibration and set a hardcoded value, which defaults to 1000.
> The justification for this long delay is similar to the time it takes to gather
> enough entropy when generating a random key. In fact the situations are
> 1. number of iterations corresponds directly to key security,
> 2. entropy corresponds directly to key security
> So I'm of the opinion that a one time 30 second delay is prudent for a
> security-focused app.
> However, I'm also sensitive to other developer concerns such as existing
> looming deadlines, having a library suddenly take an order of magnitude longer
> to return from an existing method is not so good, as well as not-so stringent
> security requirements.
> So, I'm investigating techniques to perform faster calibration. One of which
> is to read /proc/cpuinfo and use some predefined values (see
> I'll make a new thread shortly with my research that I'd love comments on.
I think a measurement-based generation of the iteration count has too many
downsides to be worthwhile. Using just a mapping of /proc/cpuinfo info to
iteration counts along with a hard-coded min (1000?) and max (128,000?) is the
way to go. This is much less complicated system that can be run in a blocking
call because it will execute very quickly. It has a much lower complexity and
therefore less possible vulnerabilities (like a zero-permission malware that
checks the process table for cacheword running, and pegging the CPU to force
the iteration count down).
PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 969 bytes
Desc: OpenPGP digital signature
More information about the Guardian-dev