From: Brian Warner Date: Mon, 21 Jul 2008 16:49:36 +0000 (-0700) Subject: add note to mutable-DSA.txt about the need for a ciphertext hash, for #492 X-Git-Url: https://git.rkrishnan.org/pf/content/%22news.html/frontends/webapi.txt?a=commitdiff_plain;h=60ce491a7902822891a295e16e3643642cd4bddc;p=tahoe-lafs%2Ftahoe-lafs.git add note to mutable-DSA.txt about the need for a ciphertext hash, for #492 --- diff --git a/docs/proposed/mutable-DSA.txt b/docs/proposed/mutable-DSA.txt index 73f3eb78..5cfb30d6 100644 --- a/docs/proposed/mutable-DSA.txt +++ b/docs/proposed/mutable-DSA.txt @@ -344,3 +344,14 @@ figured out how to define a "grid id" yet, but I think the DSA parameters should be part of that identifier. In practical terms, this might mean that the Introducer tells each node what parameters to use, or perhaps the node could have a config file which specifies them instead. + +The shares MUST have a ciphertext hash of some sort (probably a merkle tree +over the blocks, and/or a flat hash of the ciphertext), just like immutable +files do. Without this, a malicious publisher could produce some shares that +result in file A, and other shares that result in file B, and upload both of +them (incorporating both into the share hash tree). The result would be a +read-cap that would sometimes resolve to file A, and sometimes to file B, +depending upon which servers were used for the download. By including a +ciphertext hash in the SDMF data structure, the publisher must commit to just +a single ciphertext, closing this hole. See ticket #492 for more details. +