[tahoe-dev] Using a cipher cascade

[David-Sarah Hopwood]

David-Sarah Hopwood wrote:
> 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.

... except that I replied to a post that was saying how to derive the
encryption key. The grid id should actually be an input to the hash that
derives the public key from the write cap, in the case of mutable files.
For immutable files, it should be an input to the hash that derives the
read secret.

I'll add all this to the NewMutableEncodingDesign wiki page so that I
don't forget it.

-- 
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/d11b1f9e/attachment.pgp