[tahoe-dev] Using a cipher cascade
David-Sarah Hopwood
david-sarah at jacaranda.org
Tue Jan 12 21:09:50 PST 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://allmydata.org/pipermail/tahoe-dev/attachments/20100113/a584fbd4/attachment.pgp
More information about the tahoe-dev
mailing list