[tahoe-dev] Using a cipher cascade

David-Sarah Hopwood david-sarah at jacaranda.org
Wed Jan 13 05:09:50 UTC 2010

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.
>>   UEB:         the contents of the URL extension block
>>   read_secret: the secret value (e.g. K1 in Elk Point)

Something else that should be included is the grid id. That limits any
multi-target preimage attack to a particular grid; without it, the attack
could find a preimage for any file among several grids.

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://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100113/a584fbd4/attachment.asc>

More information about the tahoe-dev mailing list