[tahoe-dev] Choice of tree-hash

Tony Arcieri tony.arcieri at gmail.com
Wed Sep 19 23:41:23 UTC 2012


On Wed, Sep 19, 2012 at 11:23 AM, Brian Warner <warner at lothar.com> wrote:

> Note that we currently only apply the tree-hash to ciphertext. We used
> to build a plaintext hash tree too, but removed it because it enabled
> partial-information-guessing attacks, just like revealing a flat hash of
> the plaintext, but worse. We hope to reintroduce it safely, by uploading
> encrypted(plaintext-hash-tree) in addition to
> not-encrypted(ciphertext-hash-tree). This would let us detect failures
> in the last decryption step.)


This sounds great! I was actually trying to avoid any kind of hash of the
plaintext in my system, but that said, an encrypted hash used to detect
bugs in the encryption protocol would definitely make sense.

I'd also like to say I'm extremely impressed with the Rainhill immutable
file protocol design described here:

https://tahoe-lafs.org/trac/tahoe-lafs/wiki/NewCaps/Rainhill

One of the things I encountered using Tahoe was that to set up e.g. a cron
job to do a deep check/repair of content, I would have to use the readcap.
Separating "deep verify" from the readcap makes a whole lot of sense to me
and I'm really glad to see work in this regard. I'd really like to have a
dedicated "repair node" that can do a deep verify / repair without exposing
the readcap.

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120919/cd20250f/attachment-0001.html>


More information about the tahoe-dev mailing list