[tahoe-dev] Using a cipher cascade

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> David-Sarah Hopwood wrote:
>> The approach I would suggest is to derive the encryption key for a given
>> algorithm using a hash-based KDF (for example HKDF) with the following
>> inputs:
>> 
>>   tag:         separates this from other uses of the KDF,
>>                  and mutable from immutable
>>   algorithm:   separates AES, Salsa20, etc.
>>   fork_id:     can be used to separate forks of the file from each other,
>>                  e.g. for deep-verify caps or encrypted metadata
>>   version_id:  version of a mutable file
>>   block_num:   block number of a mutable file, to support random access
> 
> Actually it's unnecessary, when using modes without chaining (such as
> AES CTR and Salsa), to include the block number. Including the version
> number is sufficient to securely allow random access updates.

But then you would have to include information about which parts of
the file had been updated, and that information would be leaked to
an attacker who can observe the ciphertext before and after the update.
I'm not sure how to avoid that.

>> >   UEB:         the contents of the URL extension block
>> >   read_secret: the secret value (e.g. K1 in Elk Point)

David-Sarah Hopwood wrote:
> David-Sarah Hopwood wrote:
>> Note that with this approach, the extended nonce in XSalsa
>> (http://cr.yp.to/snuffle/xsalsa-20081128.pdf) isn't really necessary.
>> Using plain Salsa20/20 (even with a zero nonce, or by deriving the
>> nonce in the same way as the key), might reduce implementation complexity.
> 
> Deriving the nonce in the same way as the key (and similarly the IV for
> AES CTR mode) is better. This can only help against cryptanalytic attacks,

For Salsa, it's equivalent to using a 320-bit key.

> and is almost free in terms of performance and implementation complexity.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://allmydata.org/pipermail/tahoe-dev/attachments/20100105/9844a130/attachment-0001.pgp