[guardian-dev] cacheword and dynamic KDF iteration counts

[Hans of Guardian]

On Aug 26, 2013, at 1:20 AM, Abel Luck wrote:

> Hans of Guardian:
>> 
>> Hey Abel,
>> 
>> I just had a thought based on our discussions about setting the number of KDF iterations based on the speed of the CPU.  The hard part is making a usable backup.  Is the number of iterations used stored somewhere in the file?  That is needed for using the files on a different computer, or moving them to a new phone.
>> 
> 
> It will be stored along side the salt, IV, and ciphertext. All these
> values are required to decrypt the key, so the number of KDF iterations
> is no different.
> 
> Currently the data written to disk in a shared preference by CacheWord
> is a base64 encoded binary blog of the format: [0][1]
> 
> 
> bytes | field
>  4   |   version int
>  16  |   salt
>  12  |   iv
>  *   |   ciphertext
> 
> ciphertext is the output of GCM( PBKDF2(salt, password, iter_count=100),
> iv, raw_aes_key )
> 
> I'd simply add another 4 byte field for the KDF iterations.
> 
> ~abel
> 
> 
> 
> [0]:
> https://github.com/guardianproject/cacheword/blob/master/cachewordlib/src/info/guardianproject/cacheword/PassphraseSecrets.java#L196
> [1]:
> https://github.com/guardianproject/cacheword/blob/master/cachewordlib/src/info/guardianproject/cacheword/Constants.java#L32

I'm a little confused: does it already store the iteration count?  Or was your email a proposed way of adding it?

If this is a proposal, I think it makes sense.  The KDF iteration field should be explicitly defined as a "u_int32_t" aka "unsigned int" where int is 32-bit.

.hc