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) -- 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
