[guardian-dev] CacheWord Key Derivation

Daniel McCarney daniel at binaryparadox.net
Sun Mar 16 16:46:59 EDT 2014


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?

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

- Daniel|pd0x

[0] https://github.com/guardianproject/cacheword/blob/master/TODOs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 620 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20140316/6aba8353/attachment.pgp>


More information about the Guardian-dev mailing list