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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
