[tahoe-lafs-trac-stream] [tahoe-lafs] #492: mutable files: add ciphertext hash tree to signature block

[tahoe-lafs]

#492: mutable files: add ciphertext hash tree to signature block
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:  zooko
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  eventually
    Component:  code-    |    Version:  1.1.0
  mutable                |   Keywords:  newcaps security integrity forward-
   Resolution:           |  compatibility backward-compatibility mutable
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by davidsarah):

 * keywords:  newcaps =>
     newcaps security integrity forward-compatibility backward-
     compatibility mutable
 * owner:   => zooko


Old description:

> The problem described in #491 is also applicable to mutable files, albeit
> with less severe consequences. Mutable files do not have a plaintext or
> ciphertext hash (instead they rely upon the share hash tree, and assume
> that decoding works correctly), which means that a malicious publisher
> could create some shares for file A and other shares for file B, publish
> both of them together, compute and sign the share hash tree over the
> combination, and give the resulting read-cap to their victim. The victim
> would download the indicated file, and sometimes they would get file A,
> other times they would get file B, depending upon which servers they
> happened to use for the download.
>
> This isn't as severe as #491 because the file is mutable anyways: the
> malicious publisher could just as easily publish a new version of the
> file in between the victim's download attempts (and of course, only the
> holder of a write-cap can perform this kind of attack). However, we would
> prefer that the seqnum+roothash "version info" field uniquely identify a
> single file, and we need a ciphertext hash of some sort to enforce this
> requirement.
>
> The most likely fix is to use the same ciphertext hash tree as immutable
> files have: add a merkle tree over the ciphertext segments, put the tree
> nodes in all shares, put the root of this tree in the signature block,
> verify it on download.
>
> This is not as easy to fix as #491 because the code for this ciphertext
> hash tree is not already in place, and the current SDMF format does not
> accomodate it. So current clients would not be able to download files
> that have the new hash added, causing a backwards compatibility break.
>
> Therefore we plan to address this when we move to DSA-based mutable files
> (#217), since that is a backwards-compatibility break anyways.

New description:

 The problem described in #491 is also applicable to mutable files, albeit
 with less severe consequences. Mutable files do not have a plaintext or
 ciphertext hash (instead they rely upon the share hash tree, and assume
 that decoding works correctly), which means that a malicious publisher
 could create some shares for file A and other shares for file B, publish
 both of them together, compute and sign the share hash tree over the
 combination, and give the resulting read-cap to their victim. The victim
 would download the indicated file, and sometimes they would get file A,
 other times they would get file B, depending upon which servers they
 happened to use for the download.

 This isn't as severe as #491 because the file is mutable anyways: the
 malicious publisher could just as easily publish a new version of the file
 in between the victim's download attempts (and of course, only the holder
 of a write-cap can perform this kind of attack). However, we would prefer
 that the seqnum+roothash "version info" field uniquely identify a single
 file, and we need a ciphertext hash of some sort to enforce this
 requirement.

 The most likely fix is to use the same ciphertext hash tree as immutable
 files have: add a merkle tree over the ciphertext segments, put the tree
 nodes in all shares, put the root of this tree in the signature block,
 verify it on download.

 This is not as easy to fix as #491 because the code for this ciphertext
 hash tree is not already in place, and the current SDMF format does not
 accomodate it. So current clients would not be able to download files that
 have the new hash added, causing a backwards compatibility break.

 Therefore we plan to address this when we move to DSA-based mutable files
 (#217), since that is a backwards-compatibility break anyways.

--

Comment:

 I'd completely forgotten about this bug. Is there anything we can do in
 terms of forward compatibility to better tolerate a format change? Does
 the MDMF format accomodate a ciphertext hash tree? I don't think fixing
 this should necessarily be tied to #217.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/492#comment:2>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage