[guardian-dev] CacheWord Key Derivation

Abel Luck abel at guardianproject.info
Fri Mar 28 13:27:59 EDT 2014


On Thursday 13 March 2014 22:46:49 Stephen Lombardo wrote:
> Hello,
> 
> 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.
> 
> Cheers,
> Stephen
> 
> ==
> Stephen Lombardo, Zetetic LLC

Quick update.

This has been almost fixed in CacheWord with this commit:

https://github.com/guardianproject/cacheword/commit/3bee50dd2d916d2c2bd4c34006c7a5e9a502aec2

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 
equivelent: 

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 
https://dev.guardianproject.info/issues/3146)

I'll make a new thread shortly with my research that I'd love comments on.

~abel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20140328/19d591e4/attachment.pgp>


More information about the Guardian-dev mailing list