[guardian-dev] CacheWord Key Derivation

[Hans-Christoph Steiner]

On 03/28/2014 01:27 PM, Abel Luck wrote:
> 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

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).

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 969 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20140328/46ba03b9/attachment.pgp>