Opened at 2008-07-21T16:48:51Z
Last modified at 2012-12-06T21:55:36Z
#492 new defect
mutable files: add ciphertext hash tree to signature block
Reported by: | warner | Owned by: | zooko |
---|---|---|---|
Priority: | major | Milestone: | eventually |
Component: | code-mutable | Version: | 1.1.0 |
Keywords: | newcaps security integrity forward-compatibility backward-compatibility mutable | Cc: | |
Launchpad Bug: |
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.
Change History (2)
comment:1 Changed at 2010-02-11T03:57:07Z by davidsarah
- Keywords newcaps added
comment:2 Changed at 2012-12-06T21:55:36Z by davidsarah
- Keywords security integrity forward-compatibility backward-compatibility mutable added
- Owner set to zooko
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.