mutable files: add ciphertext hash tree to signature block #492

New Issue

warner · 2008-07-21T16:48:51Z

warner commented

2008-07-21 16:48:51 +00:00

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.

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.

warner added the

labels 2008-07-21 16:48:51 +00:00

warner added this to the eventually milestone 2008-07-21 16:48:51 +00:00

davidsarah commented

2012-12-06 21:55:36 +00:00

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.

zooko was assigned by tahoe-lafs

2012-12-06 21:55:36 +00:00

Sign in to join this conversation.